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.
Related
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'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.
I am trying to connect two clients Remotely in different networks and i am getting IceCandidateConnection status as failed. I am using a coturn server as a turn which accepts only UDP and stun server. Below is the log i am getting in about:webrtc of firefox:
Candidate log :
PeerConnection ID: 1523297273518693 (id=2147483737 url=https://eskns.com/virtualchat)
ICE stats
ICE restarts: 0
ICE rollbacks: 0
All Raw Candidates
SDP
Local SDP(Offer)
v=0
o=mozilla...THIS_IS_SDPARTA-59.0.2 7830508841574298961 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 E2:AD:A2:2B:69:FC:62:C8:7E:2B:8E:A9:BE:72:8E:6F:65:9D:9E:75:47:3C:6E:8B:C5:8D:36:96:89:45:63:0F
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 27078 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 131.95.1.135
a=candidate:0 1 UDP 2122252543 10.16.24.19 51599 typ host
a=candidate:4 1 UDP 2122187007 10.8.0.26 44981 typ host
a=candidate:8 1 TCP 2105524479 10.16.24.19 9 typ host tcptype active
a=candidate:9 1 TCP 2105458943 10.8.0.26 9 typ host tcptype active
a=candidate:0 2 UDP 2122252542 10.16.24.19 60111 typ host
a=candidate:4 2 UDP 2122187006 10.8.0.26 43187 typ host
a=candidate:8 2 TCP 2105524478 10.16.24.19 9 typ host tcptype active
a=candidate:9 2 TCP 2105458942 10.8.0.26 9 typ host tcptype active
a=candidate:1 1 UDP 1686052863 131.95.1.135 27078 typ srflx raddr 10.16.24.19 rport 51599
a=candidate:1 2 UDP 1686052862 131.95.1.135 65529 typ srflx raddr 10.16.24.19 rport 60111
a=sendrecv
a=end-of-candidates
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:b8213a6bb9067addde51fcbe6062b810
a=ice-ufrag:406caa0f
a=mid:sdparta_0
a=msid:{6e3aae13-8330-40f2-bb64-8340b96e7bff} {270b0330-ad95-47c5-8358-df76c55d07b8}
a=rtcp:65529 IN IP4 131.95.1.135
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:2797382455 cname:{5a3d45da-59c4-45f7-848a-70253293396f}
m=video 27078 UDP/TLS/RTP/SAVPF 120 121 126 97
c=IN IP4 131.95.1.135
a=candidate:0 1 UDP 2122252543 10.16.24.19 35785 typ host
a=candidate:4 1 UDP 2122187007 10.8.0.26 60461 typ host
a=candidate:8 1 TCP 2105524479 10.16.24.19 9 typ host tcptype active
a=candidate:9 1 TCP 2105458943 10.8.0.26 9 typ host tcptype active
a=candidate:0 2 UDP 2122252542 10.16.24.19 57521 typ host
a=candidate:4 2 UDP 2122187006 10.8.0.26 54431 typ host
a=candidate:8 2 TCP 2105524478 10.16.24.19 9 typ host tcptype active
a=candidate:9 2 TCP 2105458942 10.8.0.26 9 typ host tcptype active
a=candidate:1 1 UDP 1686052863 131.95.1.135 25133 typ srflx raddr 10.16.24.19 rport 35785
a=candidate:1 2 UDP 1686052862 131.95.1.135 2479 typ srflx raddr 10.16.24.19 rport 57521
a=sendrecv
a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
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:121 max-fs=12288;max-fr=60
a=ice-pwd:b8213a6bb9067addde51fcbe6062b810
a=ice-ufrag:406caa0f
a=mid:sdparta_1
a=msid:{6e3aae13-8330-40f2-bb64-8340b96e7bff} {af0a6de2-d397-44a2-96d9-35892b910b96}
a=rtcp:2479 IN IP4 131.95.1.135
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:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
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:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=rtpmap:121 VP9/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=setup:actpass
a=ssrc:3732981129 cname:{5a3d45da-59c4-45f7-848a-70253293396f}
Remote SDP (Answer)
v=0
o=mozilla...THIS_IS_SDPARTA-59.0.1 281040868006921328 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 41:33:78:18:DD:1F:D4:B6:57:53:51:AC:33:A1:D9:9A:2C:4E:CD:BB:B1:4E:2A:C2:46:50:4F:3C:12:1B:97:D3
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 9 UDP/TLS/RTP/SAVPF 109 101
c=IN IP4 0.0.0.0
a=candidate:0 1 UDP 2122121471 172.20.10.2 36494 typ host
a=candidate:4 1 UDP 2122187007 2607:fb90:25db:782e:5d87:2875:6a4c:3825 38435 typ host
a=candidate:8 1 UDP 2122252543 2607:fb90:25db:782e:5271:9af0:dc72:8551 45831 typ host
a=candidate:12 1 TCP 2105393407 172.20.10.2 9 typ host tcptype active
a=candidate:13 1 TCP 2105458943 2607:fb90:25db:782e:5d87:2875:6a4c:3825 9 typ host tcptype active
a=candidate:14 1 TCP 2105524479 2607:fb90:25db:782e:5271:9af0:dc72:8551 9 typ host tcptype active
a=candidate:1 1 UDP 1685921791 208.54.85.179 31566 typ srflx raddr 172.20.10.2 rport 36494
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:a2d690bfd141de1c3bfe0cad8a75b956
a=ice-ufrag:7219417e
a=mid:sdparta_0
a=msid:{b4292e14-ea0a-4ef4-bc14-5402cf2c4897} {a033f58f-6174-4950-ab43-17e841a288ea}
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=setup:active
a=ssrc:1881908549 cname:{b4fa8c04-a207-4092-b554-95a5f71e8ad3}
m=video 9 UDP/TLS/RTP/SAVPF 120
c=IN IP4 0.0.0.0
a=sendrecv
a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=fmtp:120 max-fs=12288;max-fr=60
a=ice-pwd:a2d690bfd141de1c3bfe0cad8a75b956
a=ice-ufrag:7219417e
a=mid:sdparta_1
a=msid:{b4292e14-ea0a-4ef4-bc14-5402cf2c4897} {17b818a8-855c-4e06-a36c-8c9dd10f33d8}
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-mux
a=rtpmap:120 VP8/90000
a=setup:active
a=ssrc:553664470 cname:{b4fa8c04-a207-4092-b554-95a5f71e8ad3}
RTP Stats
outbound_rtcp_video_1
Local: 10:26:31 GMT-0600 (CST) inbound-rtp SSRC: 3732981129
inbound_rtp_audio_2
Local: 13:08:37 GMT-0500 (CDT) inbound-rtp SSRC: 0
inbound_rtp_video_3
Local: 13:08:37 GMT-0500 (CDT) inbound-rtp SSRC: 553664470
outbound_rtp_audio_0
Local: 13:08:37 GMT-0500 (CDT) outbound-rtp SSRC: 2797382455
outbound_rtp_video_1
Local: 13:08:37 GMT-0500 (CDT) outbound-rtp SSRC: 3732981129
Remote: 10:26:31 GMT-0600 (CST) inbound-rtp SSRC: 3732981129
you are either not using a TURN server or not using the correct credentials -- otherwise you would get candidates with type=relay.
There are some types of networks that require a TURN server.
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.