Offer/Answer exchange fails when Unified SDP Plan is used
Reported by
manjuks1...@gmail.com,
Oct 5
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Steps to reproduce the problem: 1. Make an audio call from PeerA to PeerB by passing 'sdpSemantics':'unified-plan' in the RTCPeerConnection config 2. During Offer/Answer, originator side observed the below error message - Uncaught (in promise) DOMException: Failed to set remote answer sdp: The order of m-lines in answer doesn't match order in offer. Rejecting answer. What is the expected behavior? Offer/Answer should be successful with Unified-Plan SDP as the same scenario works fine when plan-B SDP is used. What went wrong? ------------------------------------------- Offer SDP "v=0 o=- 1074097161605665046 2 IN IP4 182.74.59.186 s=- t=0 0 a=group:BUNDLE 0 a=msid-semantic: WMS 3f739cd8-e61e-4e58-9ad6-eeeca6a4e104 m=audio 59597 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126 c=IN IP4 182.74.59.186 a=rtcp:9 IN IP4 182.74.59.186 a=ice-ufrag:w0vt a=ice-pwd:Pmj5Z3c+uNTqrXNNAWXW8Ba6 a=ice-lite a=fingerprint:sha-256 AB:4D:F3:8A:48:12:08:03:DD:A3:B5:CB:55:24:E8:3B:B1:7C:13:32:FB:2F:AF:85:F0:6B:26:2B:62:A5:23:C4 a=setup:actpass a=mid:0 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid a=sendrecv a=msid:3f739cd8-e61e-4e58-9ad6-eeeca6a4e104 f23e8d87-70af-44d0-b79d-c9278b367f93 a=rtcp-mux a=rtpmap:111 opus/48000/2 a=rtcp-fb:111 transport-cc a=fmtp:111 minptime=10;useinbandfec=1;cbr=0;maxaveragebitrate=77824 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:110 telephone-event/48000 a=rtpmap:112 telephone-event/32000 a=rtpmap:113 telephone-event/16000 a=rtpmap:126 telephone-event/8000 a=ssrc:1449574788 cname:1aJQot/fACg5DhTL a=ssrc:1449574788 msid:3f739cd8-e61e-4e58-9ad6-eeeca6a4e104 f23e8d87-70af-44d0-b79d-c9278b367f93 a=ssrc:1449574788 mslabel:3f739cd8-e61e-4e58-9ad6-eeeca6a4e104 a=ssrc:1449574788 label:f23e8d87-70af-44d0-b79d-c9278b367f93 a=candidate:1145357613 1 udp 2122129151 10.10.64.79 59597 typ host generation 0 ufrag w0vt network-id 1 a=candidate:3977988856 1 udp 1685921535 182.74.59.186 59597 typ srflx raddr 10.10.64.79 rport 59597 generation 0 ufrag w0vt network-id 1 " ------------------------------------------ Answer SDP ---------------------------------------- "v=0 o=- 2685524817880610585 2 IN IP4 182.74.59.186 s=- t=0 0 a=msid-semantic: WMS f2eb0a0f-faf5-45f4-b558-a101aab03519 m=audio 49628 RTP/SAVPF 111 c=IN IP4 182.74.59.186 a=rtcp:9 IN IP4 182.74.59.186 a=ice-ufrag:Z7a4 a=ice-pwd:YXt/80a2rCeoUDv5iZHsP8yM a=ice-lite a=fingerprint:sha-256 1E:F9:EB:70:D8:4A:C2:42:A0:1B:30:5F:07:02:5B:A5:21:30:0E:67:1E:3F:2C:C4:72:2D:55:62:EA:CA:BD:AC a=setup:active a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid a=sendrecv a=msid:f2eb0a0f-faf5-45f4-b558-a101aab03519 e6a92767-719f-4389-9c7a-19deb6e6927c a=rtcp-mux a=rtpmap:111 opus/48000/2 a=rtcp-fb:111 transport-cc a=fmtp:111 minptime=10;useinbandfec=1;cbr=0;maxaveragebitrate=77824 a=ssrc:666547743 cname:pp34Ol/SF0bcCsRW a=candidate:696130316 1 udp 2122260223 10.10.64.166 49628 typ host generation 0 ufrag Z7a4 network-id 1 a=candidate:3748553432 1 udp 1686052607 182.74.59.186 49628 typ srflx raddr 10.10.64.166 rport 49628 generation 0 ufrag Z7a4 network-id 1 " Did this work before? N/A Does this work in other browsers? N/A Chrome version: 69.0.3497.100 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
Oct 8
,
Oct 8
Thanks for testing Unified Plan! From https://tools.ietf.org/html/rfc5888#section-9.1 The "mid" attribute is an identifier for a particular media stream. Therefore, the "mid" value in the offer MUST be the same as the "mid" value in the answer. Besides, subsequent offers (e.g., in a re-INVITE) SHOULD use the same "mid" value for the already existing media streams. manjuks1991@ are you munging the SDP? I wonder if this issue is a WontFix.
,
Oct 30
|
||||
►
Sign in to add a comment |
||||
Comment 1 by philipp....@googlemail.com
, Oct 6