WebRTC data channel responds with old sctp draft on new sctp offer format
Reported by
nohlme...@mozilla.com,
Jan 27 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0 Steps to reproduce the problem: 1. Clone https://github.com/nils-ohlmeier/jsep-tester and open the index.html 2. Open the developer console 3. Paste the following into the text field of the page: v=0 o=- 1 1 IN IP4 0.0.0.0 s=- t=0 0 a=ice-options:trickle a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 a=group:BUNDLE a1 m=application 9 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=sendrecv a=ice-ufrag:ETEn a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl a=mid:a1 a=max-message-size:65536 a=sctp-port:5000 4. Press the "Test!" button What is the expected behavior? Since the SDP offer contains data channel format per https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-21 the SDP answer created by Chrome should ideally also follow that draft. What went wrong? The SDP answer which gets logged in the console shows 'UDP/DTLS/SCTP' per more recent sctp draft versions. But format parameter of the m-line still shows a port number as from the old drafts, instead of the expected 'webrtc-datachannel'. The answer also contains sctpmap, but no sctp-port. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 58.0.2994.0 (Official Build) canary (64-bit) Channel: canary OS Version: OS X 10.12 Flash Version: Firefox is about to get support for parsing and emitting sctp SDP per draft 21 in this bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1160558 It would be helpful if Chrome could either: - respond with a valid draft 21 answer - or at least respond with an old draft answer with just 'DTLS/SCTP' as the transport in the application m-line but not mix both draft versions.
,
Feb 17 2017
,
Feb 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/webrtc.git/+/4b2e0829caf40dd3e1bd28107b6f54002d73c2c8 commit 4b2e0829caf40dd3e1bd28107b6f54002d73c2c8 Author: zstein <zstein@webrtc.org> Date: Sat Feb 18 03:48:38 2017 Use the same draft version in SDP data channel answers as used in the offer. This change adds a flag, use_sctpmap, to DataContentDescription. The deserialization code sets the flag based on the format of the m= line. There were already unit tests using SDP in the new format, so I just updated them to check use_sctpmap was set as expected. The change to mediasession copies use_sctpmap from the offered DataContentDescription to the answer. I haven't figured out how to test this change yet, but wanted to get feedback before continuing. BUG= chromium:686212 Review-Url: https://codereview.webrtc.org/2690943011 Cr-Commit-Position: refs/heads/master@{#16686} [modify] https://crrev.com/4b2e0829caf40dd3e1bd28107b6f54002d73c2c8/webrtc/pc/mediasession.cc [modify] https://crrev.com/4b2e0829caf40dd3e1bd28107b6f54002d73c2c8/webrtc/pc/mediasession.h [modify] https://crrev.com/4b2e0829caf40dd3e1bd28107b6f54002d73c2c8/webrtc/pc/mediasession_unittest.cc [modify] https://crrev.com/4b2e0829caf40dd3e1bd28107b6f54002d73c2c8/webrtc/pc/webrtcsdp.cc [modify] https://crrev.com/4b2e0829caf40dd3e1bd28107b6f54002d73c2c8/webrtc/pc/webrtcsdp_unittest.cc
,
Feb 18 2017
,
May 24 2017
when offer proto values:'UDP/DTLS/SCTP' which is correct format according to https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-21 . In answer we receive Offer: v=0 o=- 8669542549863514933 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE data a=msid-semantic: WMS m=application 9 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=ice-ufrag:mhgJ a=ice-pwd:Ae2CIifBoXLITxOcicRiPZgx a=fingerprint:sha-256 24:EA:41:80:92:F3:9A:06:F8:FC:E6:FE:63:37:6B:99:9F:BC:5D:AF:19:C0:D9:22:44:C2:36:25:ED:83:A5:59 a=setup:actpass a=mid:data a=sctp-port:5000 localPeerConnection ICE candidate: candidate:2999745851 1 udp 2122260223 192.168.56.1 59558 typ host generation 0 ufrag mhgJ network-id 2 localPeerConnection ICE candidate: candidate:3494966876 1 udp 2122194687 10.10.192.131 59559 typ host generation 0 ufrag mhgJ network-id 1 localPeerConnection ICE candidate: candidate:4233069003 1 tcp 1518280447 192.168.56.1 9 typ host tcptype active generation 0 ufrag mhgJ network-id 2 localPeerConnection ICE candidate: candidate:2664630956 1 tcp 1518214911 10.10.192.131 9 typ host tcptype active generation 0 ufrag mhgJ network-id 1 ----------------------------------- answer: v=0 o=- 76647901151048540 2 IN IP4 127.0.0.1 s=- t=0 0 a=msid-semantic: WMS m=application 0 UDP/DTLS/SCTP webrtc-datachannel c=IN IP4 0.0.0.0 a=mid:data a=sctp-port:5000 Media port value is 0 suggesting a mute and thereby no candidate is generated which is wrong since UDP/DTLS/SCTP is valid proto value according to draft and should generate valid answer SDP with candidate generation
,
May 24 2017
Thanks for pointing that out; I'm about to fix it. Created a new bug, https://bugs.chromium.org/p/webrtc/issues/detail?id=7706, to track that issue specifically.
,
May 25 2017
Fixed. |
||||
►
Sign in to add a comment |
||||
Comment 1 by deadbeef@chromium.org
, Jan 28 2017Labels: -Pri-2 -OS-Mac WebRTCTriaged M-58 OS-All Pri-1
Owner: deadbeef@chromium.org
Status: Available (was: Unconfirmed)