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

What exactly should the spec require?  Must  the constructor throw an
error if both are present?  Or should it ignore one if both are present
(so one value takes precedence)?  Or do we say that a well-formed app
_should_ specify only one?  

- Jim

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: Monday, August 20, 2012 12:39 PM
To: Justin Uberti
Cc: Harald Alvestrand; public-webrtc@w3.org
Subject: Re: Do we need two ways of identifying m-lines?

On Mon, Aug 20, 2012 at 8:21 AM, Justin Uberti <juberti@google.com>
wrote:
> Jingle doesn't have the same index-based m= line concept, it does 
> everything by <content/> name, which is mappable to "mid".

Fair enough.


> I also think the m= index strategy has several shortcomings, so using
"mid"
> when available allows us to avoid chaining ourselves to m= index.

In that case, I propose that the spec at minimum require that only
either mid or index be present. That way there's no room for
disagreement about the semantics.

Thoughts?

-Ekr

> On Sun, Aug 19, 2012 at 5:06 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> On Sun, Aug 19, 2012 at 12:29 PM, Harald Alvestrand 
>> <harald@alvestrand.no> wrote:
>> > 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).
>>
>> Hmm...
>>
>> It sounds to me like index will always work but that label won't, so 
>> why not just always use index? What am I missing?
>>
>> -Ekr
>>
>

Received on Tuesday, 21 August 2012 13:23:40 UTC