Re: Do we need two ways of identifying m-lines?

On 08/19/2012 05:46 PM, Eric Rescorla wrote:
> The current RTCIceCandidate type has two ways of identifying the m-line,
> an m-line index (sdpMLineIndex) and an sdpMid, corresponding
> to the RFC 3388 media stream identification value.
The reason for the index is that we can't guarantee that a remote offer 
will have unique labels on all its M-lines.

For offers produced by WebRTC, we can choose to make them all have mid 
values (and they have to, if we use BUNDLE).
>
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcicecandidate-type
>
> [Constructor (optional RTCIceCandidateInit candidateInitDict)]
> interface RTCIceCandidate {
>               attribute DOMString?      candidate;
>               attribute DOMString?      sdpMid;
>               attribute unsigned short? sdpMLineIndex;
>      stringifier DOMString ();
> };
> dictionary RTCIceCandidateInit {
>      DOMString      candidate;
>      DOMString      sdpMid;
>      unsigned short sdpMLineIndex;
> };
>
> Is there a reason why it makes sense to have two of these? Since the
> receiver of the candidate has no way of indicating which versions
> they support, that means you need to support both, and translating
> between them in the JS is going to be a pain in the ass. Also, it's
> just another way for there to be disagreement (what happens if they
> don't refer to the same m-line.)
>
> ISTM to me that it would make more sense to pick just one
> of these (probably sdpMLineIndex) and stick with it.
>
> -Ekr
>

Received on Sunday, 19 August 2012 19:29:32 UTC