Adding Video With No BUNDLE Lines in SDP

[Maxime Marchand]

Hi All,

I am hoping that one of you WebRTC experts can point me in the right direction or tell me if what I am trying to do is feasible/supported in the current Chrome browser or even if Chrome will be supporting this use case in the future.

I have searched for an answer and tried many things in my code, but I can't get the following to work:

I am trying to do a call upgrade (adding video to existing audio only call), but without the Bundle lines in the SDP. My network does not support port bundling, so I need an SDP where the audio and video ports are different. I want to point out right away that I can successfully do this use case if I do NOT remove the Bundle lines (keep default SDP).

USE CASE:

1. Setup an initial audio only call between user A and user B
   
2. User A does a call upgrade (add video to audio only call with new getUserMedia)
   
3. User B accepts the call upgrade
   
4. Any user does call downgrade (remove video by setting the video port to 0)
5. Any user does call upgrade (add video again with new getUserMedia)
6. Repeat step 4-5 without the browser failing

NOTE: before doing any _pc.setLocalDescription, I remove the bundle lines from the SDP this way:

   sessionDescription.sdp = sessionDescription.sdp.replace(/a=group:BUNDLE audio\r\n/g, "");

   sessionDescription.sdp = sessionDescription.sdp.replace(/a=group:BUNDLE audio video\r\n/g, "");

This does work because I get different ports on "m=audio" and "m=video", which is the intended behavior.

RESULT:

I can only perform one upgrade, Steps 5-6 fail !!!

Basically, the browser can only perform successfully an upgrade multiple times in a row if the call uses the same port for both  "m=audio" and "m=video" lines. If the ports are different, passing from a downgraded call to once again a video call is not working.

These are the detailed steps I use to perform an upgrade:

1. New webkitGetUserMedia({audio: true, video: true}, function(stream)...
   
2. remove existing stream _pc.removeStream(localStream)
   
3. add new stream _pc.addStream(stream)
   
4. create new offer _pc.createOffer
   
5. remove bundle lines
   
6. setLocalSDP _pc.setLocalDescription
   
7. get ice candidates
   
8. send offer to remote peer
   

These are the detailed steps I use to perform a downgrade:

1. create new offer _pc.createOffer with constraints "OfferToReceiveVideo" set to false
   
2. remove bundle lines
   
3. set the video port to 0 (also, make sure we are in "sendrecv" mode)
   
4. setLocalSDP _pc.setLocalDescription
5. send offer to remote peer

In the LOGS, I can see that the SDP for step 5 of my use case is missing ice-ufrag and ice-pwd and that the video port is set to 1...

see OFFER of second upgrade:

v=0

o=- 4834140171951113916 5 IN IP4 127.0.0.1

s=-

t=0 0

a=msid-semantic: WMS z4nWgYpFsPw6UThtfe5tJOwKwfD3WTEl39Dt

m=audio 52158 RTP/SAVPF 111 103 104 0 8 126

c=IN IP4 125.113.122.55

a=rtcp:52159 IN IP4 142.133.123.33

a=candidate:437151159 1 udp 2122260223 142.133.123.33 52158 typ host generation 0

a=candidate:437151159 2 udp 2122260222 142.133.123.33 52159 typ host generation 0

a=candidate:1418565959 1 tcp 1518280447 142.133.123.33 0 typ host tcptype active generation 0

a=candidate:1418565959 2 tcp 1518280446 142.133.123.33 0 typ host tcptype active generation 0

a=ice-ufrag:yTCE4QuOaRby5yJd

a=ice-pwd:KKHBT1dd/0NoScpt8Iiix8ub

a=ice-options:google-ice

a=fingerprint:sha-256 F3:E1:6D:88:FD:B7:DA:55:BB:C8:10:DC:9C:12:C2:9E:C4:E7:49:03:88:C4:7A:10:D1:EA:DA:62:30:85:83:45

a=setup:actpass

a=mid:audio

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

a=sendrecv

a=rtcp-mux

a=rtpmap:111 opus/48000/2

a=fmtp:111 minptime=10

a=rtpmap:103 ISAC/16000

a=rtpmap:104 ISAC/32000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:126 telephone-event/8000

a=maxptime:60

a=ssrc:2250182501 cname:GVPQmpDpIZXlFcBr

a=ssrc:2250182501 msid:z4nWgYpFsPw6UThtfe5tJOwKwfD3WTEl39Dt 4ef7d31c-eae4-4314-9732-6a100b53e42e

a=ssrc:2250182501 mslabel:z4nWgYpFsPw6UThtfe5tJOwKwfD3WTEl39Dt

a=ssrc:2250182501 label:4ef7d31c-eae4-4314-9732-6a100b53e42e

m=video 52169 RTP/SAVPF 100 116 117 96

c=IN IP4 125.113.122.55

a=rtcp:52170 IN IP4 142.133.123.33

a=candidate:437151159 1 udp 2122260223 142.133.123.33 52169 typ host generation 0

a=candidate:437151159 2 udp 2122260222 142.133.123.33 52170 typ host generation 0

a=candidate:1418565959 1 tcp 1518280447 142.133.123.33 0 typ host tcptype active generation 0

a=candidate:1418565959 2 tcp 1518280446 142.133.123.33 0 typ host tcptype active generation 0

a=candidate:437151159 1 udp 2122260223 142.133.123.33 61801 typ host generation 0

a=candidate:437151159 2 udp 2122260222 142.133.123.33 61802 typ host generation 0

a=candidate:1418565959 1 tcp 1518280447 142.133.123.33 0 typ host tcptype active generation 0

a=candidate:1418565959 2 tcp 1518280446 142.133.123.33 0 typ host tcptype active generation 0

a=ice-ufrag:yTCE4QuOaRby5yJd

a=ice-pwd:KKHBT1dd/0NoScpt8Iiix8ub

a=ice-options:google-ice

a=fingerprint:sha-256 F3:E1:6D:88:FD:B7:DA:55:BB:C8:10:DC:9C:12:C2:9E:C4:E7:49:03:88:C4:7A:10:D1:EA:DA:62:30:85:83:45

a=setup:actpass

a=mid:video

a=extmap:2 urn:ietf:params:rtp-hdrext:toffset

a=extmap:14 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

a=sendrecv

a=rtcp-mux

a=rtpmap:100 VP8/90000

a=rtcp-fb:100 ccm fir

a=rtcp-fb:100 nack

a=rtcp-fb:100 nack pli

a=rtcp-fb:100 goog-remb

a=rtpmap:116 red/90000

a=rtpmap:117 ulpfec/90000

a=rtpmap:96 rtx/90000

a=fmtp:96 apt=100

a=ssrc-group:FID 454679926 4043911517

a=ssrc:454679926 cname:GVPQmpDpIZXlFcBr

a=ssrc:454679926 msid:z4nWgYpFsPw6UThtfe5tJOwKwfD3WTEl39Dt 09c6faeb-b226-49b0-9ce4-40378af9558e

a=ssrc:454679926 mslabel:z4nWgYpFsPw6UThtfe5tJOwKwfD3WTEl39Dt

a=ssrc:454679926 label:09c6faeb-b226-49b0-9ce4-40378af9558e

a=ssrc:4043911517 cname:GVPQmpDpIZXlFcBr

a=ssrc:4043911517 msid:z4nWgYpFsPw6UThtfe5tJOwKwfD3WTEl39Dt 09c6faeb-b226-49b0-9ce4-40378af9558e

a=ssrc:4043911517 mslabel:z4nWgYpFsPw6UThtfe5tJOwKwfD3WTEl39Dt

a=ssrc:4043911517 label:09c6faeb-b226-49b0-9ce4-40378af9558e

see browser ANSWER:

v=0

o=- 6057878882910049263 5 IN IP4 127.0.0.1

s=-

t=0 0

a=msid-semantic: WMS z5IdhGE6udWLNtZ5j1De4o0cKSTc2H4wo3U1

m=audio 52163 RTP/SAVPF 111 103 104 0 8 126

c=IN IP4 125.113.122.55

a=rtcp:1 IN IP4 0.0.0.0

a=candidate:437151159 1 udp 2122260223 142.133.123.33 52163 typ host generation 0

a=candidate:1418565959 1 tcp 1518280447 142.133.123.33 0 typ host tcptype active generation 0

a=ice-ufrag:FjQgNw/qg0UA36ZH

a=ice-pwd:kHYooqwEWmTn7Pco1mh4Af+E

a=fingerprint:sha-256 F3:E1:6D:88:FD:B7:DA:55:BB:C8:10:DC:9C:12:C2:9E:C4:E7:49:03:88:C4:7A:10:D1:EA:DA:62:30:85:83:45

a=setup:active

a=mid:audio

a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level

a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

a=sendrecv

a=rtcp-mux

a=rtpmap:111 opus/48000/2

a=fmtp:111 minptime=10

a=rtpmap:103 ISAC/16000

a=rtpmap:104 ISAC/32000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:126 telephone-event/8000

a=maxptime:60

a=ssrc:2432452571 cname:jbVMZw57KYOje031

a=ssrc:2432452571 msid:z5IdhGE6udWLNtZ5j1De4o0cKSTc2H4wo3U1 147c3eaf-87cc-457f-bf9c-1610deff30b4

a=ssrc:2432452571 mslabel:z5IdhGE6udWLNtZ5j1De4o0cKSTc2H4wo3U1

a=ssrc:2432452571 label:147c3eaf-87cc-457f-bf9c-1610deff30b4

m=video 1 RTP/SAVPF 100 116 117 96

c=IN IP4 0.0.0.0

a=rtcp:1 IN IP4 0.0.0.0

a=ice-ufrag:

a=ice-pwd:

a=fingerprint:sha-256 F3:E1:6D:88:FD:B7:DA:55:BB:C8:10:DC:9C:12:C2:9E:C4:E7:49:03:88:C4:7A:10:D1:EA:DA:62:30:85:83:45

a=setup:active

a=mid:video

a=extmap:2 urn:ietf:params:rtp-hdrext:toffset

a=extmap:14 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

a=sendrecv

a=rtcp-mux

a=rtpmap:100 VP8/90000

a=rtcp-fb:100 ccm fir

a=rtcp-fb:100 nack

a=rtcp-fb:100 nack pli

a=rtcp-fb:100 goog-remb

a=rtpmap:116 red/90000

a=rtpmap:117 ulpfec/90000

a=rtpmap:96 rtx/90000

a=fmtp:96 apt=100

a=ssrc-group:FID 3620434458 3089122764

a=ssrc:3620434458 cname:jbVMZw57KYOje031

a=ssrc:3620434458 msid:z5IdhGE6udWLNtZ5j1De4o0cKSTc2H4wo3U1 acb064af-1bc3-4d0e-80fe-9ed251bbc8ca

a=ssrc:3620434458 mslabel:z5IdhGE6udWLNtZ5j1De4o0cKSTc2H4wo3U1

a=ssrc:3620434458 label:acb064af-1bc3-4d0e-80fe-9ed251bbc8ca

a=ssrc:3089122764 cname:jbVMZw57KYOje031

a=ssrc:3089122764 msid:z5IdhGE6udWLNtZ5j1De4o0cKSTc2H4wo3U1 acb064af-1bc3-4d0e-80fe-9ed251bbc8ca

a=ssrc:3089122764 mslabel:z5IdhGE6udWLNtZ5j1De4o0cKSTc2H4wo3U1

a=ssrc:3089122764 label:acb064af-1bc3-4d0e-80fe-9ed251bbc8ca

WebRTC -> Failed to set session description: Failed to set local answer sdp: Called with SDP without ice-ufrag and ice-pwd.

Any help would be greatly appreciated!!!

Thanks in advance!

[Vikas]

Hi,

Is it possible for you to recreate the problem with sdp munge demo here?

/Vikas

[Maxime Marchand]

Hi Vikas,

I created a small client based on the Munge Demo. You can follow the order of buttons to reach the failing behavior in the Browser. You can see that if you remove Bundle lines, the Browser generates the error I describe in my original post, but if you include them, the functionality is perfect. You can toggle this with the checkbox.

http://webrtc.utopicum.com/

I want to note that I am doing a call downgrade by setting the video port to 0. This is to be compliant with legacy, like webRTC to SIP phone....

[Vikas]

Thanks can recreate it, will look into the logs.

/Vikas

[Maxime Marchand]

Thanks Vikas!

I'm still trying to see how to resolve this issue as it may affect any client out there with networks not supporting bundled media ports. Perhaps we could play with the "a=setup" line to set it to passive or active, but I do not think these will be understood by existing SIP clients.

The browser seem to handle passing from an SDP with only 1 "m=audio" line (audio only) to the SDP with the" m=video" added (video upgrade) when bundle is removed. However, passing from the existing "m=video 0" to another m line with a port, even if failing, should not return this type of error. I tried reading on this use case in any RFC I could find, but really nothing. Session modification is still not well described for webRTC....

Cheers

[Justin Uberti]

I think this is https://code.google.com/p/webrtc/issues/detail?id=2136, and not related to BUNDLE.

[Maxime Marchand]

Hi Justin,

I already saw that issue and I do not believe they are related. I was quite surprised to see this 2136 issue because for me, I do not experience it.

You can try this client http://webrtc.utopicum.com/ once with bundle removed and once with bundle included (checkbox).

 The use case is described by:

1. Audio and Video Call
   
2. Downgrade Call (Video port 0)
   
3. Upgrade Call (new getUserMedia)
   
4. Accepts upgrade

I do not encounter issues with this use case when the bundle lines are kept in the SDP (default behavior). 

Because of this, and the type of error I get in the SDP (no ice-pwd and ice-ufrag), I believe the issue I found is different and needs to be addressed individually.

Should I raise a new TR in https://code.google.com/p/webrtc/issues/list ?

Thank you,

Maxime

[Vikas Marwaha]

Hi,

Thanks you can file a new issue and we can investigate it further.

/Vikas

--

---
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.
For more options, visit https://groups.google.com/d/optout.

[Justin Uberti]

OK. Will take a closer look.

[Maxime Marchand]

I create a new issue: 

https://code.google.com/p/webrtc/issues/detail?id=4260

Let me know if I should add more details or logs.

I noted that this was an important issue for interoperability with IMS Networks.