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 Monday, 20 August 2012 16:40:20 UTC