Problem setting remote SDP

469 views
Skip to first unread message

Ed Robbins

unread,
Mar 7, 2021, 8:03:16 AM3/7/21
to discuss-webrtc
I'm at a a loss as to why I'm getting the following error messages from chrome in setRemoteDescription:

Failed to set remote answer sdp: Failed to apply the description for m= section with mid='0': Failed to set SSL role for the transport.

Session error code: ERROR_CONTENT. Session error description: Failed to apply the description for m= section with mid='0': Failed to set SSL role for the transport..

The SDP in the INVITE from the webrtc client is as follows:

v=0
o=- 8317640840212907769 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic: WMS 2EfGfwOhOiG35hmmSMORh0XE82YHiqboqt4h
m=audio 62825 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 192.168.0.3
a=rtcp:49881 IN IP4 192.168.0.3
a=candidate:976448962 1 udp 2122262783 2600:8802:4300:26a0:f0d6:1fb3:fbea:3d31 61411 typ host generation 0 network-id 2 network-cost 10
a=candidate:3802297132 1 udp 2122194687 192.168.0.3 62825 typ host generation 0 network-id 1 network-cost 10
a=candidate:3195986061 1 udp 2122129151 10.101.95.151 50461 typ host generation 0 network-id 3 network-cost 50
a=candidate:976448962 2 udp 2122262782 2600:8802:4300:26a0:f0d6:1fb3:fbea:3d31 50462 typ host generation 0 network-id 2 network-cost 10
a=candidate:3802297132 2 udp 2122194686 192.168.0.3 49881 typ host generation 0 network-id 1 network-cost 10
a=candidate:3195986061 2 udp 2122129150 10.101.95.151 54190 typ host generation 0 network-id 3 network-cost 50
a=candidate:1957728562 1 tcp 1518283007 2600:8802:4300:26a0:f0d6:1fb3:fbea:3d31 9 typ host tcptype active generation 0 network-id 2 network-cost 10
a=candidate:2887880668 1 tcp 1518214911 192.168.0.3 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=candidate:4043119741 1 tcp 1518149375 10.101.95.151 9 typ host tcptype active generation 0 network-id 3 network-cost 50
a=candidate:1957728562 2 tcp 1518283006 2600:8802:4300:26a0:f0d6:1fb3:fbea:3d31 9 typ host tcptype active generation 0 network-id 2 network-cost 10
a=candidate:2887880668 2 tcp 1518214910 192.168.0.3 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=candidate:4043119741 2 tcp 1518149374 10.101.95.151 9 typ host tcptype active generation 0 network-id 3 network-cost 50
a=ice-ufrag:rO4G
a=ice-pwd:fyG7lDMFFKqCxXRESvBvwt2C
a=ice-options:trickle
a=fingerprint:sha-256 7A:C4:C1:A2:BF:14:EB:3E:B6:38:35:6F:18:16:71:B2:A3:77:20:78:16:37:DF:8D:84:F4:3E:8B:F8:D4:96:2C
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:2EfGfwOhOiG35hmmSMORh0XE82YHiqboqt4h 87b9523f-8e46-48bf-9f5f-6bfd6dcbb0bf
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
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:2594177427 cname:qXM9rhaPpOXsNM4c
a=ssrc:2594177427 msid:2EfGfwOhOiG35hmmSMORh0XE82YHiqboqt4h 87b9523f-8e46-48bf-9f5f-6bfd6dcbb0bf
a=ssrc:2594177427 mslabel:2EfGfwOhOiG35hmmSMORh0XE82YHiqboqt4h
a=ssrc:2594177427 label:87b9523f-8e46-48bf-9f5f-6bfd6dcbb0bf
4:29
183, where we first see the "failed to set remote answer sdp" error:
4:29
v=0
o=BroadWorks 183142 1 IN IP4 208.73.144.98
s=-
c=IN IP4 208.89.108.145
t=0 0
m=audio 20944 UDP/TLS/RTP/SAVPF 0 126
a=maxptime:20
a=mid:0
a=rtpmap:0 PCMU/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-15
a=sendrecv
a=rtcp:20944
a=rtcp-mux
a=setup:passive
a=fingerprint:sha-256 DA:B8:27:99:AB:B2:05:28:DD:85:04:41:55:9A:3C:C5:C4:3D:DD:7F:7B:1E:E3:5E:E3:EB:F1:84:55:B7:8C:C6
a=ice-ufrag:nqSViQIi
a=ice-pwd:vyZvA2NKnt8JIrR3mT6e5KFYwp
a=ice-options:trickle
a=candidate:2X885VeKHtXsQzvJ 1 UDP 2130706431 208.89.108.145 20944 typ host
a=end-of-candidates


The UAS then sends the following SDP in the 200 Ok, which triggers the error.


v=0
o=BroadWorks 183142 1 IN IP4 208.73.144.98
s=-
c=IN IP4 208.89.108.145
t=0 0
m=audio 20944 UDP/TLS/RTP/SAVPF 0 126
a=maxptime:20
a=mid:0
a=rtpmap:0 PCMU/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-15
a=sendrecv
a=rtcp:20944
a=rtcp-mux
a=setup:passive
a=fingerprint:sha-256 DA:B8:27:99:AB:B2:05:28:DD:85:04:41:55:9A:3C:C5:C4:3D:DD:7F:7B:1E:E3:5E:E3:EB:F1:84:55:B7:8C:C6
a=ice-ufrag:nqSViQIi
a=ice-pwd:vyZvA2NKnt8JIrR3mT6e5KFYwp
a=ice-options:trickle
a=candidate:2X885VeKHtXsQzvJ 1 UDP 2130706431 208.89.108.145 20944 typ host
a=end-of-candidates

Filip Bajaník

unread,
Mar 7, 2021, 8:12:05 AM3/7/21
to discuss-webrtc
I also had this problem, but then I read that sending offers only from one side would solve the problem and it did. I've implemented polite and unpolite peer logic around and only one side generates offers - other side just send empty message if it wants to negotiate again - so the unpolite side could generate proper offer.

Dátum: nedeľa 7. marca 2021, čas: 14:03:16 UTC+1, odosielateľ: Ed Robbins

Philipp Hancke

unread,
Mar 7, 2021, 8:56:34 AM3/7/21
to discuss...@googlegroups.com
the only reason this might happen is trying to reverse the roles after setup, see
so you might want to compare the a=setup lines in previous answers.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/45e59f99-06cd-4169-b937-bf973aca0193n%40googlegroups.com.

Ed Robbins

unread,
Mar 7, 2021, 9:42:16 AM3/7/21
to discuss-webrtc
That's one of the problems here, this isn't a re-INVITE, it's the initial OFFER/ANSWER to establish the session. After running Chrome from the command line with debug flags set for webrtc, what I found is that Chrome complains that SSL roles can not be reversed.  To me, that implies that Chome is taking the passive role, even though it sends a=setup:actpass.  I had to explicitly return a=setup:active in the 200 Ok in order to resolve this issue.

Ed
Reply all
Reply to author
Forward
0 new messages