Do we need two ways of identifying m-lines?

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.

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 15:47:25 UTC