Re: [webrtc-extensions] Feature request: API to explicit MID ordering (#44)

FWIW we've built and successfully launched the SFU product with Unified Plan now, and this remains the only hack where we had to add code to manually parse the SDP in the application because we can't get the MID ordering figured out otherwise.

Let me try and clarify this more, and maybe we can make progress in the right direction for the future regardless of what that means :)

The SFU isn't a traditional WebRTC endpoint, it is much more lightweight, very few fields from the SDP are actually used in practice in such scenarios.
Let's reason about this from a simple user story: Someone joins a video conference, providing one more remote video stream for you to receive. 

Your SFU now gives you an updated list of n ssrcs representing video streams (or a delta with the new video stream if you have that in your protocol - but the scenario is you now have one additional video stream) 

Now you need to configure you WebRTC endpoint to receive the new video stream. If your solution to that is to have the SFU send an updated SDP over the network you will be very inefficient - but also then your SFU needs to know about the existing MIDs and ordering of to construct a valid SDP for you - which will give you a lot of extra latency.

So the real problem is, someone joins the conference and provides one additional video stream  to the conference - no other changes - how do you configure the client to start receiving that stream?

My naive proposal to address this is the subject line of this issue - give the client only the extra ssrc and have it update transceivers and build a remote SDP to match the local SDP - not doing this dance of the network with the SFU as those round trips would be too slow.

-- 
GitHub Notification of comment by ovelius
Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/44#issuecomment-660998437 using your GitHub account

Received on Monday, 20 July 2020 12:30:40 UTC