[WebRTC] Can't set sdp offer from edge if connection already stable
Reported by
6071...@gmail.com,
Dec 27 2017
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38 Steps to reproduce the problem: 1. Make stable webrtc connection between Edge and Chrome. 2. On Edge side: a. Add new stream with video to connection. b. Create new sdp description. c. Send this description to Chrome. 3. Call setRemoteDescription at Chrome Error occurred: Failed to set remote offer sdp: The order of m-lines in subsequent offer doesn't match order from previous offer/answer. What is the expected behavior? What went wrong? I suppose something wrong with the second sdp offer from Edge. But this error doesn't tell much about a real problem. type: offer, sdp: v=0 o=thisisadapterortc 5057766247707951 1 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE cixdzvdtda uypr5s20cu a=ice-options:trickle m=audio 9 UDP/TLS/RTP/SAVPF 104 102 9 0 8 103 97 13 118 101 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0 a=rtpmap:104 SILK/16000 a=rtcp-fb:104 x-cinfo a=rtcp-fb:104 x-bwe a=rtcp-fb:104 x-message app send:dsh recv:dsh a=rtpmap:102 opus/48000/2 a=rtcp-fb:102 x-cinfo a=rtcp-fb:102 x-bwe a=rtcp-fb:102 x-message app send:dsh recv:dsh a=rtpmap:9 G722/8000 a=rtcp-fb:9 x-cinfo a=rtcp-fb:9 x-bwe a=rtcp-fb:9 x-message app send:dsh recv:dsh a=rtpmap:0 PCMU/8000 a=rtcp-fb:0 x-cinfo a=rtcp-fb:0 x-bwe a=rtcp-fb:0 x-message app send:dsh recv:dsh a=rtpmap:8 PCMA/8000 a=rtcp-fb:8 x-cinfo a=rtcp-fb:8 x-bwe a=rtcp-fb:8 x-message app send:dsh recv:dsh a=rtpmap:103 SILK/8000 a=rtcp-fb:103 x-cinfo a=rtcp-fb:103 x-bwe a=rtcp-fb:103 x-message app send:dsh recv:dsh a=rtpmap:97 RED/8000 a=rtpmap:13 CN/8000 a=rtpmap:118 CN/16000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 events=0-16 a=maxptime:100 a=rtcp-mux a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:3 http://skype.com/experiments/rtp-hdrext/fast_bandwidth_feedback#version_2 a=ice-ufrag:WQ/6 a=ice-pwd:/QG0WMKm5fAISol3SP3ppUxt a=setup:actpass a=fingerprint:sha-256 39:F7:66:48:26:65:87:90:CE:EE:49:DF:68:26:D2:B8:43:BD:E7:34:67:8E:16:4C:40:30:CA:A5:FD:96:94:97 a=mid:cixdzvdtda a=recvonly a=ssrc:2002 cname:26zm3848l8 a=rtcp-rsize a=candidate:1 1 UDP 2130706431 192.168.53.71 51502 typ host a=candidate:2 1 TCP 1684798975 192.168.53.71 51502 typ srflx raddr 192.168.53.71 rport 51502 tcptype active a=end-of-candidates m=video 9 UDP/TLS/RTP/SAVPF 122 107 100 99 96 123 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0 a=rtpmap:122 X-H264UC/90000 a=fmtp:122 packetization-mode=1;mst-mode=NI-TC a=rtcp-fb:122 x-cinfo a=rtcp-fb:122 x-bwe a=rtcp-fb:122 x-message app send:src,x-pli recv:src,x-pli a=rtpmap:107 H264/90000 a=fmtp:107 profile-level-id=42C02A;packetization-mode=1;level-asymmetry-allowed=1 a=rtcp-fb:107 x-cinfo a=rtcp-fb:107 x-bwe a=rtcp-fb:107 nack a=rtcp-fb:107 nack pli a=rtcp-fb:107 goog-remb a=rtpmap:100 VP8/90000 a=rtcp-fb:100 x-cinfo a=rtcp-fb:100 x-bwe a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=rtcp-fb:100 goog-remb a=rtpmap:99 rtx/90000 a=fmtp:99 apt=107;rtx-time=3000 a=rtpmap:96 rtx/90000 a=fmtp:96 apt=100;rtx-time=3000 a=rtpmap:123 x-ulpfecuc/90000 a=rtcp-mux a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:3 http://skype.com/experiments/rtp-hdrext/fast_bandwidth_feedback#version_2 a=ice-ufrag:WQ/6 a=ice-pwd:/QG0WMKm5fAISol3SP3ppUxt a=setup:actpass a=fingerprint:sha-256 39:F7:66:48:26:65:87:90:CE:EE:49:DF:68:26:D2:B8:43:BD:E7:34:67:8E:16:4C:40:30:CA:A5:FD:96:94:97 a=mid:uypr5s20cu a=sendrecv a=msid:D42AF990-0C6F-45BE-ABC9-FBCEC597DD1C 035C19A5-6220-4CAE-8268-15F19FF55E4F a=ssrc:4004 msid:D42AF990-0C6F-45BE-ABC9-FBCEC597DD1C 035C19A5-6220-4CAE-8268-15F19FF55E4F a=ssrc:4005 msid:D42AF990-0C6F-45BE-ABC9-FBCEC597DD1C 035C19A5-6220-4CAE-8268-15F19FF55E4F a=ssrc-group:FID 4004 4005 a=ssrc:4004 cname:26zm3848l8 a=ssrc:4005 cname:26zm3848l8 a=rtcp-rsize Dump attached. Did this work before? N/A Chrome version: <Copy from: 'about:version'> Channel: n/a OS Version: OS X 10.13 Flash Version: Occurs only with connection between Edge and Chrome.
,
Jan 4 2018
This looks like the offer from Edge gets the mid attributes wrong. Can you file an issue @ https://github.com/webrtc/adapter if this still happens with the most recent release (6.x)?
,
Jan 4 2018
This seems to be an adapter.js bug, given "o=thisisadapterortc". Please reopen if it's possible to reproduce without adapter.js.
,
Jan 8 2018
Yes, this is adapter.js bug. https://github.com/webrtc/adapter/issues/745 Thank you very much! |
||
►
Sign in to add a comment |
||
Comment 1 by bokan@chromium.org
, Dec 27 2017