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?

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).

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

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

Received on Tuesday, 21 July 2020 11:24:23 UTC