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

> OK thanks for clarifying.
> 
> > 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.
> 
> Unless I am missing something, the remote endpoint is required to remember mappings between mid and index from previous offers, but that seems like a small feat for a virtual client that proclaims to speak SDP.
> 
> So assuming the virtual endpoint has a small amount of memory - here's my confusion: If the virtual endpoint is the one generating the SDP, then it already knows the m= lines, and if you want to see which transceiver got mapped to which m= line, you can correlate them by the mid. The transceiver knows the mid; the virtual endpoint knows the index. Voíla, it can generate the SDP correctly the next time as well, as long as it remembers which indices it used in the previous offers (which, if it understands SDP, it is required to do, otherwise it is not consistent with its own offers). Is there an issue here that I am missing?

It does in fact not have a small amount of memory - the reason here being that the virtual endpoint is in a library shared between web/mobile/native and is stateless in nature, stateless libraries are the best especially if they cross compiled to different clients :) The parts that parses the SDP is also separated from the part that generates the SDP (it is simply a different method).

I could still be stateless, but simply consume the full local SDP currently in the PC when it needs to generate the remote SDP. 
This is a fair option, but you'll then see how annoyingly close the transceiver listing API is to giving you exact information you want - only the index is missing - and thus I filed this issue to discuss that - and also to explore what the other options are.
 
Mind you this simple approach has been working very well with Plan B - so there is a more complexity in the UP world here (with Plan B it is enough to use PRANSWER for instance). 
I'm worried that our product call setup - which is incredibly latency sensitive - will show regressions when moving to UP if there is a lot of "extra dancing" to get the state correct which we didn't have in Plan B. 

If there are indeed regressions, it will be tough discussion to move to UP for the existing clients.


> 
> Predicting which indices will be used for transceivers that have not been mapped yet is a different story. I'll go over the two scenarios I see for this as well for the sake of completeness:
> 
> * Option A: The client PC is the one generating the offer. In this case, the RTCPeerConnection takes care of mapping them and making sure the offer is valid, so so-far we don't need the index. And the virtual endpoint, which does need to know indices for future O/As, will be able to tell which m= lines are new and on offer and which ones it has seen before. This might be a case where you have to parse the SDP, but if you are talking to a virtual endpoint that proclaims to understand SDP, this seems like a small thing to ask.
> * Option B: The remote virtual endpoint is the one generating the SDP. Again in this scenario, because the remote endpoint is the one generating the SDP, it is the one "offering to receive", and it is up to it whether it wants to reuse existing m= lines (which is pre-existing knowledge that it has) or it wants to add a new m= line for receiving (in which case it would add it at the end; also a known position).

We've solved this problem by doing an extra setLocalDescription at setup, this locks indices and mids in place in a nice predictable way. 

IMHO the ordering of mids requirements is a silly one - mid:s are already required to be 1:1 mapped local/remote so the ordering constraint seems odd - it is both an ordered list and a map at the same time?  I understand there is a historical reason for it though.

> 
> Based on this, are you able to pinpoint which step would be eased by having a mid ordering API?

FWIW I'm very curious if there are more SFU examples out there that use UP and that does not rely on munging - and how they approach this problem.

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

Received on Wednesday, 22 July 2020 08:16:48 UTC