Upgrade a call without SDP re-negotiation

437 views
Skip to first unread message

Shazzzzzzzz

unread,
Dec 12, 2017, 3:27:57 AM12/12/17
to discuss-webrtc
Hello experts,

Is it possible to upgrade an audio call to audio+video call without renegotiation? I want to avoid renegotiation to upgrade the calls quicker. I wouldnt want the user to wait 3 seconds to start seeing the video. (FYI, my application does not support Trickle ICE and BUNDLE SDP for now)

To do this, I plan to send out both audio and video tracks in SDP even if the user selected just audio call. However I disable the video track to begin with -
stream.getVideoTracks()[0].enabled = false;
The receiver sees a black screen. When the caller upgrades the call to audio+video, I enable the video track and the reciever is able to see the video instantly.

However, this approach isn't desirable for 2 reasons. Firstly, webcam light is on even if video track is disabled. Second, this is inefficient since there will be a minimal flow of RTP packets even when the video track is disabled.

I got curious as to how commercial players such as 'Slack' do the same. From chrome webrtc-internals, I found that Slack does not renegotiate as well, instead adopts the same technique of sending both audio and video tracks in SDP for just audio call. However, I see no RTP packets being sent for video during audio call even though SDP has video tracks. When user enables video, I see change in local description regarding only 'ssrc msid' being replaced and the RTP packets starts flowing without renegotiation.

Something like this -
  •     Old value -
a=ssrc:23712514 msid:355b7517-fa05-4d9a-a1a7-e213f7ab4e7b fake-label-9OfhfeSOYQwCD1EE
  •     New Value(video enabled) -
 a=ssrc:23712514 msid:355b7517-fa05-4d9a-a1a7-e213f7ab4e7b 306d58a2-f3db-4634-a70c-0682493208c0

The above change does not trigger re-negotiation and the web cam light turns on only after user enables video.

How can I achieve something similar in my application. Basically having video tracks in SDP(sendrecv), but not send any video RTP data for audio only calls and later enable video without renegotiation.

Philipp Hancke

unread,
Dec 12, 2017, 8:19:25 AM12/12/17
to WebRTC-discuss
this is probably done by stopping the video track attached to the peerconnection and then renegotiating locally using the same ssrc but a different msid. However it is complicated enough that you should rather wait for replaceTrack which makes this a lot easier.

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/86d5d2d1-d46e-4374-af0c-380233d37e0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Eric Davies

unread,
Dec 12, 2017, 10:51:53 PM12/12/17
to discuss-webrtc
What you want is a level of indirection between the camera and the mediastream.
If you are developing native, there are tricks you can pull with a custom video capturer.
If you are developing web, then you could try a two media stream approach - draw the camera based one onto a canvas, and then send a canvas based one to the other peer. You may be able to do it more efficiently with a video object than a canvas (haven't tried getting a mediastream from a video object yet).

Shazzzzzzzz

unread,
Dec 20, 2017, 11:35:03 AM12/20/17
to discuss-webrtc
Thank you both for the pointers regarding canvas and 'replaceTrack' api. I also referred to a mozilla blog about the same and I tried adding a black/dummy video track from a canvas to the peer connection for an audio only call to begin with. When the user enables video at some point later, 'replaceTrack' api replaces the black video track with a track from web cam and the callee instantly sees the video without re-negotiation. This is almost what I want with obvious firefox only limitation.

However, for the initial audio call with black/dummy video track, the callee responds back with video as well, even though from caller perspective it was an audio call request.

Is there a tried and tested way to differentiate on the callee side
  •  if the incoming call is audio call with dummy video track and the callee must respond with audio with dummy video track
OR
  • if the incoming call is audio+video call and the callee must respond with audio+video
Reply all
Reply to author
Forward
0 new messages