W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2012

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Sun, 19 Aug 2012 21:29:15 +0200
Message-ID: <50313E8B.60309@alvestrand.no>
To: public-webrtc@w3.org
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:32 UTC