When I do call between two browsers, I get the following offer from other browser:
{"sdp":"v=0\r\n
o=- 7536355095180056736 2 IN IP4 127.0.0.1\r\n
s=-\r\n
t=0 0\r\n
a=group:BUNDLE audio video\r\n
a=msid-semantic: WMS kZEpfQv0bZYsCa56HHy2eMo3E4A71KXCApdD\r\n
m=audio 9 RTP/SAVPF 111 103 104 9 0 8 106 105 13 126\r\n
c=IN IP4 0.0.0.0\r\n
a=rtcp:9 IN IP4 0.0.0.0\r\n
a=ice-ufrag:xA0sdUZO/vAhvhQG\r\n
a=ice-pwd:Re8aNMs38GOfZ581+F6CKl8t\r\n
a=ice-options:google-ice\r\n
a=fingerprint:sha-256 2C:E2:54:76:12:24:36:4D:10:66:24:24:0D:18:63:DB:51:7E:AD:B5:BE:96:C5:43:C7:6D:3C:95:4D:4F:7B:FD\r\n
a=setup:actpass\r\n
a=mid:audio\r\n
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\n
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\n
a=sendrecv\r\n
a=rtcp-mux\r\n
a=rtpmap:111 opus/48000/2\r\n
a=fmtp:111 minptime=10\r\n
a=rtpmap:103 ISAC/16000\r\n
a=rtpmap:104 ISAC/32000\r\n
a=rtpmap:9 G722/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:106 CN/32000\r\n
a=rtpmap:105 CN/16000\r\n
a=rtpmap:13 CN/8000\r\n
a=rtpmap:126 telephone-event/8000\r\n
a=maxptime:60\r\n
a=ssrc:1065921633 cname:Gvk84VJyPRAri/jA\r\n
a=ssrc:1065921633 msid:kZEpfQv0bZYsCa56HHy2eMo3E4A71KXCApdD c0116fd8-aef9-4eba-8297-98b9069973c0\r\n
a=ssrc:1065921633 mslabel:kZEpfQv0bZYsCa56HHy2eMo3E4A71KXCApdD\r\n
a=ssrc:1065921633 label:c0116fd8-aef9-4eba-8297-98b9069973c0\r\n
m=video 9 RTP/SAVPF 100 116 117 96\r\n
c=IN IP4 0.0.0.0\r\n
a=rtcp:9 IN IP4 0.0.0.0\r\n
a=ice-ufrag:xA0sdUZO/vAhvhQG\r\n
a=ice-pwd:Re8aNMs38GOfZ581+F6CKl8t\r\n
a=ice-options:google-ice\r\na=fingerprint:sha-256 2C:E2:54:76:12:24:36:4D:10:66:24:24:0D:18:63:DB:51:7E:AD:B5:BE:96:C5:43:C7:6D:3C:95:4D:4F:7B:FD\r\n
a=setup:actpass\r\n
a=mid:video\r\n
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset\r\n
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\n
a=sendrecv\r\n
a=rtcp-mux\r\n
a=rtpmap:100 VP8/90000\r\n
a=rtcp-fb:100 ccm fir\r\n
a=rtcp-fb:100 nack\r\n
a=rtcp-fb:100 nack pli\r\n
a=rtcp-fb:100 goog-remb\r\n
a=rtpmap:116 red/90000\r\n
a=rtpmap:117 ulpfec/90000\r\n
a=rtpmap:96 rtx/90000\r\n
a=fmtp:96 apt=100\r\n
a=ssrc-group:FID 1938891203 2482888767\r\n
a=ssrc:1938891203 cname:Gvk84VJyPRAri/jA\r\n
a=ssrc:1938891203 msid:kZEpfQv0bZYsCa56HHy2eMo3E4A71KXCApdD 4bd70627-5383-4da1-9dd9-1c6d8a8f21b2\r\n
a=ssrc:1938891203 mslabel:kZEpfQv0bZYsCa56HHy2eMo3E4A71KXCApdD\r\n
a=ssrc:1938891203 label:4bd70627-5383-4da1-9dd9-1c6d8a8f21b2\r\n
a=ssrc:2482888767 cname:Gvk84VJyPRAri/jA\r\n
a=ssrc:2482888767 msid:kZEpfQv0bZYsCa56HHy2eMo3E4A71KXCApdD 4bd70627-5383-4da1-9dd9-1c6d8a8f21b2\r\n
a=ssrc:2482888767 mslabel:kZEpfQv0bZYsCa56HHy2eMo3E4A71KXCApdD\r\n
a=ssrc:2482888767 label:4bd70627-5383-4da1-9dd9-1c6d8a8f21b2\r\n
","type":"offer",
"from":"-tMt8kJad6P8AfSnLjyh"}
And following is the stream object which I get inside 'event' when onaddstream() of PeerConnection object is called:
{"onremovetrack":null,
"onaddtrack":null,
"onended":null,
"ended":false,
"id":"kZEpfQv0bZYsCa56HHy2eMo3E4A71KXCApdD",
"label":"kZEpfQv0bZYsCa56HHy2eMo3E4A71KXCApdD"}
It works fine. Video stream gets attached to the source element. However, When I try to call from mobile to browser... (mobile becomes the one to send the offer) I get following offer object on browser from mobile:
{"type":"offer",
"sdp":"v=0\r\n
o=- 8571015662826724969 2 IN IP4 127.0.0.1\r\n
s=-\r\n
t=0 0\r\n
a=group:BUNDLE audio video\r\n
a=msid-semantic: WMS ARDAMS\r\n
m=audio 9 RTP/SAVPF 103 111 9 102 0 8 106 105 13 127 126 \r\n
c=IN IP4 0.0.0.0\r\n
a=rtcp:9 IN IP4 0.0.0.0\r\n
a=ice-ufrag:JKMUpFQiL+ZHZr/V\r\n
a=ice-pwd:rLL5A3k9pBwxCsM2IzNAu2xM\r\n
a=ice-options:google-ice\r\n
a=fingerprint:sha-1 B0:E7:56:DF:C6:D9:E4:08:10:DB:A1:7B:9B:C6:65:2C:29:64:38:E1\r\n
a=setup:actpass\r\n
a=mid:audio\r\n
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\n
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\n
a=sendrecv\r\n
a=rtcp-mux\r\n
a=rtpmap:111 opus/48000/2\r\n
a=fmtp:111 minptime=10; useinbandfec=1\r\n
a=rtpmap:103 ISAC/16000\r\n
a=rtpmap:9 G722/8000\r\n
a=rtpmap:102 ILBC/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:106 CN/32000\r\n
a=rtpmap:105 CN/16000\r\n
a=rtpmap:13 CN/8000\r\n
a=rtpmap:127 red/8000\r\n
a=rtpmap:126 telephone-event/8000\r\n
a=maxptime:60\r\n
a=ssrc:2978495626 cname:MJvVwIPq7NgXaDF6\r\n
a=ssrc:2978495626 msid:ARDAMS ARDAMSa0\r\n
a=ssrc:2978495626 mslabel:ARDAMS\r\n
a=ssrc:2978495626 label:ARDAMSa0\r\n
m=video 9 RTP/SAVPF 100 116 117 96\r\n
c=IN IP4 0.0.0.0\r\n
a=rtcp:9 IN IP4 0.0.0.0\r\n
a=ice-ufrag:JKMUpFQiL+ZHZr/V\r\n
a=ice-pwd:rLL5A3k9pBwxCsM2IzNAu2xM\r\n
a=ice-options:google-ice\r\n
a=fingerprint:sha-1 B0:E7:56:DF:C6:D9:E4:08:10:DB:A1:7B:9B:C6:65:2C:29:64:38:E1\r\n
a=setup:actpass\r\n
a=mid:video\r\n
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset\r\n
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\n
a=sendrecv\r\n
a=rtcp-mux\r\n
a=rtpmap:100 VP8/90000\r\n
a=rtcp-fb:100 ccm fir\r\n
a=rtcp-fb:100 nack\r\n
a=rtcp-fb:100 nack pli\r\n
a=rtcp-fb:100 goog-remb\r\n
a=rtpmap:116 red/90000\r\n
a=rtpmap:117 ulpfec/90000\r\n
a=rtpmap:96 rtx/90000\r\n
a=fmtp:96 apt=100\r\n
a=ssrc-group:FID 899049567 490613521\r\n
a=ssrc:899049567 cname:MJvVwIPq7NgXaDF6\r\n
a=ssrc:899049567 msid:ARDAMS ARDAMSv0\r\n
a=ssrc:899049567 mslabel:ARDAMS\r\n
a=ssrc:899049567 label:ARDAMSv0\r\n
a=ssrc:490613521 cname:MJvVwIPq7NgXaDF6\r\n
a=ssrc:490613521 msid:ARDAMS ARDAMSv0\r\n
a=ssrc:490613521 mslabel:ARDAMS\r\n
a=ssrc:490613521 label:ARDAMSv0\r\n"}
And following is the stream object which I get inside 'event' when onaddstream() of PeerConnection object is called:
{"onremovetrack":null,
"onaddtrack":null,
"onended":null,
"ended":false,
"id":"ARDAMS",
"label":"ARDAMS"}
When I attach this to video element of HTML page. It shows nothing but 'half black half white' square.
Both peers are able to send ICE candidates too. They are able to send offer and answer to each other. They attach their local stream to the peer connection object.
What could possibly be wrong with this? Can anyone guide me in this?
Thanks.
Related
While trying to test a newly installed TURN server, a strange thing is happening. The turn server is working with a mediasoup based application but it is not working for a simple p2p call between 2 browsers! First browser is firefox with relay only candidate generation setting and other is a regular chrome browser. The p2p call works perfectly fine with srflx candidates without the relay only setting in firefox but it never works with relay only candidates where as candidates are being generated as I can see from the logs. It seems that somehow the relay candidates are not useful to the peer connection when it should be. May be I am missing something here?
The testing method:
I am using latest firefox(102) to test the turn server by switching on the media.peerconnection.ice.relay_only flag to true. This is available in the about:config configuration options in firefox. With this flag switched on, a mediasoup application works fine by using relay-tcp candidate but a simple p2p WebRTC app fails connects. In the about:webrtc section of firefox, it shows a successful candidate negotiation along with the selected candidate pair while using a mediasoup application. While using a simple p2p call, there are no selected candidates being displayed in the about:webrtc section of firefox. It seems that the candidated handshake process is not happening in the simple p2p call.
I tested the turnserver using tricleICE as well in both the modes i.e. generating all possible candidates and generating relay only candidates. The trickleICE test page generates the candidates as expected in both the modes.
In the below mentioned sdps, only the real turn server ip has been masked with xx.xxx.xx.xxx. Nothing else has been changed other than ip masking.
In case you need some more information from my side to understand the problem better, please let me know.
Below are the generated local and remote sdp for your reference.
Local SDP (Offer)
v=0
o=mozilla...THIS_IS_SDPARTA-99.0 464200334888033493 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 53:36:D8:C7:BE:4A:18:8B:66:13:E0:F5:2A:CA:3E:12:D5:C2:5C:3D:49:52:37:69:E3:C5:DE:AB:EB:97:A6:FE
a=group:BUNDLE 0 1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 15203 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 xx.xxx.xx.xxx
a=candidate:2 1 UDP 8265727 xx.xxx.xx.xxx 11212 typ relay raddr xx.xxx.xx.xxx rport 11212
a=candidate:2 2 UDP 8265726 xx.xxx.xx.xxx 13559 typ relay raddr xx.xxx.xx.xxx rport 13559
a=candidate:0 1 UDP 92151807 xx.xxx.xx.xxx 15203 typ relay raddr xx.xxx.xx.xxx rport 15203
a=candidate:0 2 UDP 92151806 xx.xxx.xx.xxx 12659 typ relay raddr xx.xxx.xx.xxx rport 12659
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:543612c020ecbfa091075987638de7de
a=ice-ufrag:19fb9389
a=mid:0
a=msid:{df27f0b0-7ad1-4821-9d5c-100d8b7f46a1} {de00dd52-3713-4828-bf7c-eb6b0fc02830}
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:actpass
a=ssrc:3389249034 cname:{6f1432d9-6700-41e7-8d4e-12b2a58d142b}
m=video 15203 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 xx.xxx.xx.xxx
a=sendrecv
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:124 apt=120
a=fmtp:121 max-fs=12288;max-fr=60
a=fmtp:125 apt=121
a=fmtp:127 apt=126
a=fmtp:98 apt=97
a=ice-pwd:543612c020ecbfa091075987638de7de
a=ice-ufrag:19fb9389
a=mid:1
a=msid:{df27f0b0-7ad1-4821-9d5c-100d8b7f46a1} {6e402539-71af-4d4d-952f-14c89b1122a4}
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:121 transport-cc
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-fb:97 transport-cc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:121 VP9/90000
a=rtpmap:125 rtx/90000
a=rtpmap:126 H264/90000
a=rtpmap:127 rtx/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 rtx/90000
a=setup:actpass
a=ssrc:2840162245 cname:{6f1432d9-6700-41e7-8d4e-12b2a58d142b}
a=ssrc:1181264584 cname:{6f1432d9-6700-41e7-8d4e-12b2a58d142b}
a=ssrc-group:FID 2840162245 1181264584
Remote SDP (Answer)
v=0
o=- 5898391754541643877 2 IN IP4 127.0.0.1
s=-
t=0 0
a=sendrecv
a=group:BUNDLE 0 1
a=msid-semantic:WMS izy342Js2ivoQo0m43FgE2Q3Y87sZ0NCQlYy
m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 0.0.0.0
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fingerprint:sha-256 79:83:6F:1A:5B:E4:BD:C7:5D:D3:BD:FA:29:5E:FB:04:88:9D:29:4D:CB:1E:4A:66:C2:52:9A:33:FB:86:E5:B1
a=fmtp:109 maxplaybackrate=0;stereo=0;useinbandfec=1
a=ice-options:trickle
a=ice-pwd:S8EqJvFxFsROgTTfy2c1p+fO
a=ice-ufrag:dylB
a=mid:0
a=msid:izy342Js2ivoQo0m43FgE2Q3Y87sZ0NCQlYy 70e6f101-9697-4f7f-8d35-e10bbfa74958
a=rtcp:9 IN IP4 0.0.0.0
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=setup:active
a=ssrc:723086318 cname:NSNYU4Lgz+Cpndvm
m=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 0.0.0.0
a=sendrecv
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fingerprint:sha-256 79:83:6F:1A:5B:E4:BD:C7:5D:D3:BD:FA:29:5E:FB:04:88:9D:29:4D:CB:1E:4A:66:C2:52:9A:33:FB:86:E5:B1
a=fmtp:124 apt=120
a=fmtp:125 apt=121
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:127 apt=126
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:98 apt=97
a=ice-options:trickle
a=ice-pwd:S8EqJvFxFsROgTTfy2c1p+fO
a=ice-ufrag:dylB
a=mid:1
a=msid:izy342Js2ivoQo0m43FgE2Q3Y87sZ0NCQlYy c481d53b-2e22-4ade-b9c9-a8740c96f309
a=rtcp:9 IN IP4 0.0.0.0
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:121 goog-remb
a=rtcp-fb:121 transport-cc
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:97 goog-remb
a=rtcp-fb:97 transport-cc
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:121 VP9/90000
a=rtpmap:125 rtx/90000
a=rtpmap:126 H264/90000
a=rtpmap:127 rtx/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 rtx/90000
a=setup:active
a=ssrc:3533905249 cname:NSNYU4Lgz+Cpndvm
a=ssrc:3012959319 cname:NSNYU4Lgz+Cpndvm
a=ssrc-group:FID 3533905249 3012959319
There are some obvious mistakes and this mistake was something like that. I was not listening to the onicecandidate event on the callee side / remote side. Therefore, there was no icecandidates were being sent from the callee to the caller side and it was failing with ICE failure. As soon as I added the onicecandidate listener on the callee side and sent those candidates to the caller as well using my signalling channel, my p2p app started working with TURN. The only strange thing to me is that how it was working with STUN candidates without the onicecandidate listener on the callee side!!
For the future readers, Don't forget to add onicecandidate listener on both caller and callee side!
I have a web based WebRTC client and I am having the following functionality:
Step 1. CreateOffer with both audio and video tracks set to sendrecv.
Step 2. Receive and Answer with both audio and video tracks set to
sendrecv. Peer to Peer A/V calls get established here.
Step 3.
Receive a Re-Invite with "a=group:BUNDLE 0 1 video_1". Here I am
getting second video track (video_1)with a=sendonly.
The Re-invite SDP is :
c=IN IP4 xxx.xx.xx.xx
b=AS:4044
t=0 0
a=ice-lite
a=ice-options:trickle
a=group:BUNDLE 0 1 video_1
a=msid-semantic:WMS 43e6158b973b4ca08c2bc5174f58b434
m=audio 49162 UDP/TLS/RTP/SAVP 111 110
b=AS:44
a=tcap:1 RTP/SAVPF
a=pcfg:1 t=1
a=rtpmap:111 opus/48000/2
a=fmtp:111 maxaveragebitrate=6000; maxplaybackrate=16000; sprop-maxcapturerate=16000; sprop-stereo=0; stereo=0; useinbandfec=1
a=rtpmap:110 telephone-event/48000
a=fmtp:110 0-15
a=ptime:20
a=maxptime:120
a=sendrecv
a=rtcp:49163
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=candidate:1 1 UDP 2130706175 xxx.xx.xx.xx 49162 typ host
a=end-of-candidates
a=ice-ufrag:zurp
a=ice-pwd:Zrz0Y1wK3WbD0HSKqgx88C
a=setup:actpass
a=fingerprint:sha-256 5B:A6:08:68:7C:5B:39:BB:C1:EC:C5:72:35:C7:62:3B:A2:BE:BE:0C:29:83:11:CC:51:FE:0C:93:A5:8D:AA:E8
a=rtcp-mux
a=msid:43e6158b973b4ca08c2bc5174f58b434 09c78ac11b0347aa8b6a1a9fdba841c1
a=ssrc:1095164922 cname:K8o0hMe5bXvm
a=mid:0
m=video 57354 UDP/TLS/RTP/SAVPF 96
b=AS:2000
a=rtpmap:96 VP8/90000
a=fmtp:96 max-fr=30; max-fs=3600
a=sendrecv
a=framerate:30
a=extmap:13 urn:3gpp:video-orientation
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtcp:57355
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* goog-remb
a=rtcp-fb:* ccm tmmbr
a=candidate:1 1 UDP 2130706175 xxx.xx.xx.xx 57354 typ host
a=end-of-candidates
a=ice-ufrag:X9Z+
a=ice-pwd:hcvRaKtCJLdHDRs7MP4KXq
a=setup:actpass
a=fingerprint:sha-256 5B:A6:08:68:7C:5B:39:BB:C1:EC:C5:72:35:C7:62:3B:A2:BE:BE:0C:29:83:11:CC:51:FE:0C:93:A5:8D:AA:E8
a=rtcp-mux
a=msid:43e6158b973b4ca08c2bc5174f58b434 track-1
a=ssrc:2066381390 cname:K8o0hMe5bXvm
a=mid:1
m=video 0 UDP/TLS/RTP/SAVPF 96
b=AS:2000
a=rtpmap:96 VP8/90000
a=fmtp:96 max-fr=30; max-fs=3600
a=sendonly
a=framerate:30
a=extmap:13 urn:3gpp:video-orientation
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtcp:57355
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* goog-remb
a=rtcp-fb:* ccm tmmbr
a=ice-ufrag:X9Z+
a=ice-pwd:hcvRaKtCJLdHDRs7MP4KXq
a=setup:actpass
a=fingerprint:sha-256 5B:A6:08:68:7C:5B:39:BB:C1:EC:C5:72:35:C7:62:3B:A2:BE:BE:0C:29:83:11:CC:51:FE:0C:93:A5:8D:AA:E8
a=rtcp-mux
a=msid:43e6158b973b4ca08c2bc5174f58b434 track-2
a=ssrc:2776644557 cname:K8o0hMe5bXvm
a=mid:video_1
a=bundle-only
Step 4. In response to the above Re-invite my WebRTC client is creating a SDP with both the Video tracks set as a=recvonly.
Below is the SDP generated as an Answer to the above Re-Invite request:
a=group:BUNDLE 0 1 video_1
a=msid-semantic: WMS 03b098fc-d19f-4604-8698-a164f1064222
m=audio 54067 UDP/TLS/RTP/SAVP 111 110
c=IN IP4 192.168.1.107
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:779251937 1 udp 2122260223 192.168.1.107 54067 typ host generation 0 network-id 1 network-cost 10
a=candidate:1626442769 1 tcp 1518280447 192.168.1.107 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=ice-ufrag:bSuf
a=ice-pwd:gEbxh/ZGJqewM+cb6mLj9vX1
a=ice-options:trickle
a=fingerprint:sha-256 CC:89:23:8E:49:D2:F3:20:70:FB:B6:3B:BB:D9:76:B6:E3:E2:6D:C4:CB:51:0D:55:AB:D7:93:D8:91:63:15:4E
a=setup:active
a=mid:0
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:03b098fc-d19f-4604-8698-a164f1064222 bf7a9e2d-c258-419b-9460-6e0c492599eb
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 maxaveragebitrate=6000;minptime=10;useinbandfec=1
a=rtpmap:110 telephone-event/48000
a=ssrc:2871826634 cname:NdgoEAIRngdC542j
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:bSuf
a=ice-pwd:gEbxh/ZGJqewM+cb6mLj9vX1
a=ice-options:trickle
a=fingerprint:sha-256 CC:89:23:8E:49:D2:F3:20:70:FB:B6:3B:BB:D9:76:B6:E3:E2:6D:C4:CB:51:0D:55:AB:D7:93:D8:91:63:15:4E
a=setup:active
a=mid:1
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=recvonly
a=msid:03b098fc-d19f-4604-8698-a164f1064222 20213716-40ab-4f1c-9b69-9d859de05ca6
a=rtcp-mux
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=ssrc:3663801913 cname:NdgoEAIRngdC542j
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:bSuf
a=ice-pwd:gEbxh/ZGJqewM+cb6mLj9vX1
a=ice-options:trickle
a=fingerprint:sha-256 CC:89:23:8E:49:D2:F3:20:70:FB:B6:3B:BB:D9:76:B6:E3:E2:6D:C4:CB:51:0D:55:AB:D7:93:D8:91:63:15:4E
a=setup:active
a=mid:video_1
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=recvonly
a=rtcp-mux
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
I am creating a new peer connection on getting the Re-Invite, but using the same localstreams object which I fetched during the time of creating the offer in Step 1.
Clearing the existing local tracks from the old peer connection before creating a new peerconnection.
localStream.getTracks().forEach(function(track) {
var sender = call.peerConnection.getSenders().find ? call.peerConnection.getSenders().find(function(s) {
return s.track === track;
}) : null;
if (sender) {
call.peerConnection.removeTrack(sender);
On creating a new peerConnection adding the local tracks like:
newStream.getTracks().forEach(function(track) {
wsclogger.debug("addLocalStream, calling addTrack() --> "+ track.kind);
peerConnection.addTrack(track, newStream);
});
Here I have confirmed from the log above that both Audio and Video tracks are getting added to the newly created peerConnection object.
Please guide me whats going wrong here.
PS: Same logic works well with Android, where the Re-invite Response sdp contains a=sendrecv for the track-1 and a=recvonly for the track-2.
Thanks in Advance.
I've written an Android app to stream video from my nest cameras and doorbell. I have a valid access token and can retrieve a list of all my nest devices. However, when I send a GenerateWebRtcStream to any device, it returns the same 400 error.
I have verified that my offer:
Has a=recvonly, and that it also has H264 as an available video codec. As indicated in documentation
Has a data channel (as suggested by another solution to this problem).
Has the audio stream data before the video stream data (as suggested by a second solution to this problem).
[Updated] Have created the offer with a PeerConnection initialized with SdpSemantics.UNIFIED_PLAN
Additional information:
My Android app is based (almost entirely) off this very helpful blog. The app works when connecting to a non-nest camera (i.e. instance of itself on another device), so the offer and logic is valid on some level.
There appears to be very little information on what offer the Nest Camera's will accept, so I'm posting the generated offer and command I'm posting to the API in the hopes that someone has an idea on what I might need to change.
Many thanks in advance.
sdpOffer:
v=0
o=- 5150109222623794114 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1 2
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 102 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:KQKv
a=ice-pwd:QvV7coYbshMtmKmkqpBno0xz
a=ice-options:trickle renomination
a=fingerprint:sha-256 C2:16:13:A3:80:1A:8E:96:21:98:4B:8C:03:26:93:DE:FA:88:C5:8B:DB:06:62:87:FF:BA:D4:0C:98:2A:3E:C9
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=recvonly
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:102 ILBC/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
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 125 100 101 127
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:KQKv
a=ice-pwd:QvV7coYbshMtmKmkqpBno0xz
a=ice-options:trickle renomination
a=fingerprint:sha-256 C2:16:13:A3:80:1A:8E:96:21:98:4B:8C:03:26:93:DE:FA:88:C5:8B:DB:06:62:87:FF:BA:D4:0C:98:2A:3E:C9
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
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=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:100 red/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:127 ulpfec/90000
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:KQKv
a=ice-pwd:QvV7coYbshMtmKmkqpBno0xz
a=ice-options:trickle renomination
a=fingerprint:sha-256 C2:16:13:A3:80:1A:8E:96:21:98:4B:8C:03:26:93:DE:FA:88:C5:8B:DB:06:62:87:FF:BA:D4:0C:98:2A:3E:C9
a=setup:actpass
a=mid:2
a=sctp-port:5000
a=max-message-size:262144
POST Body:
{
{
"command":"sdm.devices.commands.CameraLiveStream.GenerateWebRtcStream",
"params":{
"sdpOffer":"v=0\r\no=- 5150109222623794114 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0 1 2\r\na=msid-semantic: WMS\r\nm=audio 9 UDP\/TLS\/RTP\/SAVPF 111 103 104 9 102 0 8 106 105 13 110 112 113 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:KQKv\r\na=ice-pwd:QvV7coYbshMtmKmkqpBno0xz\r\na=ice-options:trickle renomination\r\na=fingerprint:sha-256 C2:16:13:A3:80:1A:8E:96:21:98:4B:8C:03:26:93:DE:FA:88:C5:8B:DB:06:62:87:FF:BA:D4:0C:98:2A:3E:C9\r\na=setup:actpass\r\na=mid:0\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:2 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/abs-send-time\r\na=extmap:3 http:\/\/www.ietf.org\/id\/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id\r\na=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id\r\na=recvonly\r\na=rtcp-mux\r\na=rtpmap:111 opus\/48000\/2\r\na=rtcp-fb:111 transport-cc\r\na=fmtp:111 minptime=10;useinbandfec=1\r\na=rtpmap:103 ISAC\/16000\r\na=rtpmap:104 ISAC\/32000\r\na=rtpmap:9 G722\/8000\r\na=rtpmap:102 ILBC\/8000\r\na=rtpmap:0 PCMU\/8000\r\na=rtpmap:8 PCMA\/8000\r\na=rtpmap:106 CN\/32000\r\na=rtpmap:105 CN\/16000\r\na=rtpmap:13 CN\/8000\r\na=rtpmap:110 telephone-event\/48000\r\na=rtpmap:112 telephone-event\/32000\r\na=rtpmap:113 telephone-event\/16000\r\na=rtpmap:126 telephone-event\/8000\r\nm=video 9 UDP\/TLS\/RTP\/SAVPF 96 97 98 99 125 100 101 127\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:KQKv\r\na=ice-pwd:QvV7coYbshMtmKmkqpBno0xz\r\na=ice-options:trickle renomination\r\na=fingerprint:sha-256 C2:16:13:A3:80:1A:8E:96:21:98:4B:8C:03:26:93:DE:FA:88:C5:8B:DB:06:62:87:FF:BA:D4:0C:98:2A:3E:C9\r\na=setup:actpass\r\na=mid:1\r\na=extmap:14 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:2 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/abs-send-time\r\na=extmap:13 urn:3gpp:video-orientation\r\na=extmap:3 http:\/\/www.ietf.org\/id\/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=extmap:12 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/playout-delay\r\na=extmap:11 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/video-content-type\r\na=extmap:7 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/video-timing\r\na=extmap:8 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/color-space\r\na=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id\r\na=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id\r\na=recvonly\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:96 VP8\/90000\r\na=rtcp-fb:96 goog-remb\r\na=rtcp-fb:96 transport-cc\r\na=rtcp-fb:96 ccm fir\r\na=rtcp-fb:96 nack\r\na=rtcp-fb:96 nack pli\r\na=rtpmap:97 rtx\/90000\r\na=fmtp:97 apt=96\r\na=rtpmap:98 VP9\/90000\r\na=rtcp-fb:98 goog-remb\r\na=rtcp-fb:98 transport-cc\r\na=rtcp-fb:98 ccm fir\r\na=rtcp-fb:98 nack\r\na=rtcp-fb:98 nack pli\r\na=rtpmap:99 rtx\/90000\r\na=fmtp:99 apt=98\r\na=rtpmap:125 H264\/90000\r\na=rtcp-fb:125 goog-remb\r\na=rtcp-fb:125 transport-cc\r\na=rtcp-fb:125 ccm fir\r\na=rtcp-fb:125 nack\r\na=rtcp-fb:125 nack pli\r\na=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f\r\na=rtpmap:100 red\/90000\r\na=rtpmap:101 rtx\/90000\r\na=fmtp:101 apt=100\r\na=rtpmap:127 ulpfec\/90000\r\nm=application 9 UDP\/DTLS\/SCTP webrtc-datachannel\r\nc=IN IP4 0.0.0.0\r\na=ice-ufrag:KQKv\r\na=ice-pwd:QvV7coYbshMtmKmkqpBno0xz\r\na=ice-options:trickle renomination\r\na=fingerprint:sha-256 C2:16:13:A3:80:1A:8E:96:21:98:4B:8C:03:26:93:DE:FA:88:C5:8B:DB:06:62:87:FF:BA:D4:0C:98:2A:3E:C9\r\na=setup:actpass\r\na=mid:2\r\na=sctp-port:5000\r\na=max-message-size:262144\r\n"
}
}
Error Response:
{
"error":{
"code":400,
"message":"sdp_offer contains an invalid value.",
"status":"INVALID_ARGUMENT"
}
}
Got the sample app at github.com/google/device-access-sample-web-app running as suggested by #BTGunner (thanks again!!!), and got to see what a successful request looks like.
The offer that I'm generating is accepted. The problem was that the documentation and implementation have deviated for GenerateWebRtcStream. The current documentation indicates that the offer description should be named offerSdp (which fails). The sample app instead uses offer_sdp and this returns a valid answer.
I am using Kurento for audio-only Webrtc. We have two browser apps from where users can connect and listen. But for one of the app, there is no audio in Chrome. And in other browsers it is working fine. Also, the other app works perfectly fine in Chrome. For the app, for which there is no audio, I checked chrome://webrtc-internals/, I found audioLevel, totalAudioEnergy and [Audio_Level_in_RMS as 0. Which seems like the issue. But I am not able to find the reason why it is 0 as same stream is being audible with non-zero audio attributes.
SDP Offer generated from chrome:
v=0
o=- 5216768741743449485 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:RqhJ
a=ice-pwd:nzZ+GB+RAJ6H80ToE7uxpaZk
a=ice-options:trickle
a=fingerprint:sha-256 49:17:98:CC:EE:53:46:B4:A0:86:3B:29:B8:E4:E5:E8:E1:CD:49:B0:B5:AA:D8:3A:68:EF:2D:96:31:FF:F9:AE
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=recvonly
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
SDP Answer from Kurento:
v=0
o=- 3788596538 3788596538 IN IP4 0.0.0.0
s=Kurento Media Server
c=IN IP4 0.0.0.0
t=0 0
a=msid-semantic: WMS
a=group:BUNDLE 0
m=audio 1 UDP/TLS/RTP/SAVPF 111 0
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendonly
a=mid:0
a=rtcp:9 IN IP4 0.0.0.0
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=setup:active
a=rtcp-mux
a=fmtp:111 minptime=10;useinbandfec=1
a=ssrc:4159551798 cname:user3791831093#host-88916abf
a=ice-ufrag:dfqB
a=ice-pwd:nvfOteYfAIimzPMmD1E1Gx
a=fingerprint:sha-256 E5:D2:D9:1E:82:DD:21:E4:1B:8F:FC:62:F6:2C:FF:5B:C3:C4:17:75:97:DB:F0:BC:B5:F2:2C:6A:EB:35:83:4E
Any thoughts/suggestions/debug steps? Please share. Thanks in advance.
I'm working on integration of WebRTC into a project and using "implementation 'org.webrtc:google-webrtc:1.0.30039'". When I just use the example project from Google source https://webrtc.googlesource.com/src/, it works fine without any issue. However when converted all the Java files to Kotlin and run, it always throw the below error (Invalid SDP line). I did verify that the SDP is similar between Java and Kotlin project. Also I tried adding new line at the end of SDP as recommended in some forum, didn't help either.
Below is the error that I see in the Logcat when tried creating offer:
E/webrtc_sdp.cc: (line 402): Failed to parse: "". Reason: Invalid SDP line.
E/PCRTCClient: Peerconnection error: setSDP error: SessionDescription is NULL.
Following is the SDP:
v=0
o=- 3703865506153758141 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS ARDAMS
m=video 9 RTP/SAVPF 96 97 98 99 100 101 127 124 125
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:WMCz
a=ice-pwd:7U8pMIKV8KizMp6zeYgpnD6X
a=ice-options:trickle renomination
a=mid:0
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
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:ARDAMS ARDAMSv0
a=rtcp-mux
a=rtcp-rsize
a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:xpIiJ7ZL8lDPOZbcBrMV8Q0kH/7K2bwborNljNEq
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 H264/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:127 red/90000
a=rtpmap:124 rtx/90000
a=fmtp:124 apt=127
a=rtpmap:125 ulpfec/90000
a=ssrc-group:FID 3892029952 1800496854
a=ssrc:3892029952 cname:1P/brKdD8UOBMgTV
a=ssrc:3892029952 msid:ARDAMS ARDAMSv0
a=ssrc:3892029952 mslabel:ARDAMS
a=ssrc:3892029952 label:ARDAMSv0
a=ssrc:1800496854 cname:1P/brKdD8UOBMgTV
a=ssrc:1800496854 msid:ARDAMS ARDAMSv0
a=ssrc:1800496854 mslabel:ARDAMS
a=ssrc:1800496854 label:ARDAMSv0
m=audio 9 RTP/SAVPF 111 103 104 9 102 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:WMCz
a=ice-pwd:7U8pMIKV8KizMp6zeYgpnD6X
a=ice-options:trickle renomination
a=mid:1
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:ARDAMS ARDAMSa0
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:xpIiJ7ZL8lDPOZbcBrMV8Q0kH/7K2bwborNljNEq
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:102 ILBC/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:167068800 cname:1P/brKdD8UOBMgTV
a=ssrc:167068800 msid:ARDAMS ARDAMSa0
a=ssrc:167068800 mslabel:ARDAMS
a=ssrc:167068800 label:ARDAMSa0
Anyone seen similar issue when using WebRTC lib in Kotlin based android app ?
I just ran into the same issue. The problem is, according to this discuss-webrtc mailing list thread, \r\n is required at the end of the session description.
You can fix this by simply appending \r\n at the end of the description string when constructing your SessionDescription object, eg.:
val sdp = SessionDescription(origSdp.type, "${sdpDescription.trim()}\r\n")
There is also a bug tracking this cryptic error message.