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

> Forgive me if I'm still confused, I'm trying to reply based on my understanding.
> 
> Even if the SFU uses a custom protocol, the the client (browser endpoint) needs to perform setRemoteDescription, which means either the SFU or the client is constructing SDP. The entity that is constructing the SDP needs to know the index. And if it is powerful enough to generate SDP, it needs to know the m= line index in order to do its job anyway.
> 
> * Option A: If the SFU is constructing the SDP, it seems the m= line index is known by the SFU, and client and SFU can correlate transceivers by mid. So this would be a non issue, but also a case you want to avoid due to latency if I understand correctly?
> * Option B: If the client is constructing the SDP, it seems the m= line index is already known by the client, or else it couldn't have constructed the SDP in the first place.

Yes exactly this, Option B :) You'll find all kinds of issues with Option A - that single ssrc you could send instead becomes a full SDP for instance.

> 
> > 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?
> 
> You need valid remote SDP, and it sounds to me like the client is generating it. Because SDP needs to be consistent between offer/answer rounds, you would need a "virtual remote endpoint" that is generating SDP consistently between O/As. You could generate SDP to add an additional m= line for the new stream, or it could be more intelligent and reuse old m= lines that have become inactive, I think it is up to this "virtual endpoint" that understands and generates SDP. So I don't quite understand why on top of this, you would then also need to parse the SDP after setting it?

Here exactly is the problem when we think about Option B. There is no clean way of knowing how the virtual remote endpoint should build the remote SDP in regards to the order of the MIDs without parsing the local description of itself. Which is an OK solution, but pretty heavy weight for such a simple thing that could just be in some API that lists transceivers or something.

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

Received on Monday, 20 July 2020 14:18:46 UTC