Hi Alexander, That indeed looks like a bug in Firefox. I’m pretty sure the DTLS server is not suppose to send anything while waiting for the initial Hello. I opened this bug report for your problem https://bugzilla.mozilla.org/show_bug.cgi?id=1299952 I was not able to reproduce the problem by simply letting the client not send the initial Hello. So something must be different in your setup. If you could get the signaling log file like described here https://wiki.mozilla.org/Media/WebRTC/Logging#Signaling_.28SDP_offer.2Fanswer_handling.29 and attach it to the bug report that would be really helpful.
Thank you Nils Ohlmeier > On Sep 1, 2016, at 12:28, Alexander Abagian <[email protected]> wrote: > > Here's it. The line right after Alert is server Client Hello. > > 9 16:10:02.130349 192.168.125.138 9001 192.168.125.39 154 > STUN Binding Request user: 9affe06b0002USER 50423 > 12 16:10:02.132106 192.168.125.39 50423 192.168.125.138 82 > STUN Binding Error Response error-code: 401 (Unauthorized) Unauthorized > 9001 > 16 16:10:02.256364 192.168.125.138 9001 192.168.125.39 158 > STUN Binding Request user: 9affe06b:0002USER 50423 > 22 16:10:02.259959 192.168.125.39 50423 192.168.125.138 142 > STUN Binding Request user: 0002USER:9affe06b 9001 > 23 16:10:02.260247 192.168.125.39 50423 192.168.125.138 106 > STUN Binding Success Response XOR-MAPPED-ADDRESS: 192.168.125.138:9001 > 9001 > 24 16:10:02.260766 192.168.125.138 9001 192.168.125.39 130 > STUN Binding Success Response user: 0002USER:9affe06b XOR-MAPPED-ADDRESS: > 192.168.125.39:50423 50423 > 28 16:10:02.812030 192.168.125.138 9001 192.168.125.39 158 > STUN Binding Request user: 9affe06b:0002USER 50423 > 32 16:10:02.815013 192.168.125.39 50423 192.168.125.138 106 > STUN Binding Success Response XOR-MAPPED-ADDRESS: 192.168.125.138:9001 > 9001 > 33 16:10:02.859969 192.168.125.39 50423 192.168.125.138 57 > DTLSv1.2 Alert (Level: Fatal, Description: Illegal Parameter) 9001 > 34 16:10:03.060687 192.168.125.138 9001 192.168.125.39 263 > DTLSv1.0 Client Hello 50423 > 46 16:10:03.774995 192.168.125.138 9001 192.168.125.39 158 > STUN Binding Request user: 9affe06b:0002USER 50423 > 49 16:10:03.776711 192.168.125.39 50423 192.168.125.138 106 > STUN Binding Success Response XOR-MAPPED-ADDRESS: 192.168.125.138:9001 > 9001 > 50 16:10:05.002177 192.168.125.138 9001 192.168.125.39 263 > DTLSv1.0 Client Hello 50423 > 51 16:10:09.001930 192.168.125.138 9001 192.168.125.39 263 > DTLSv1.0 Client Hello 50423 > 52 16:10:16.992382 192.168.125.138 9001 192.168.125.39 263 > DTLSv1.0 Client Hello 50423 > 53 16:10:32.971012 192.168.125.138 9001 192.168.125.39 263 > DTLSv1.0 Client Hello 50423 > > > On Thursday, September 1, 2016 at 9:01:11 PM UTC+3, Nils Ohlmeier wrote: >>> On Sep 1, 2016, at 04:51, Alexander Abagian wrote: >>> >>> Here's webrtc-internals. The pcap is almost the same, the only difference >>> is some 5-digit ports. Firefox ip is 192.168.125.39. Media server >>> (192.168.125.138) is offerer, and acts as a DTLS client. >> >> Well in case of your media server being the DTLS client my next question is: >> can you add the ICE packets for the video port to your Wireshark trace? >> And did your media server actually send any DTLS client hello to Firefox? >> >> It is possible that this is some kind of bug in Firefox as we don’t have >> that many implementations which use on purpose two bundle sets. >> >> Best regards >> Nils Ohlmeier > > _______________________________________________ > dev-media mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-media
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
