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

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

From: Justin Uberti <juberti@google.com>
Date: Mon, 3 Sep 2012 23:23:38 -0700
Message-ID: <CAOJ7v-0NA7V8zo2W7Kp6PSqcw5Y5mfrTd3aUMg1Ryp2mZm-V7Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Sounds reasonable to me.

FWIW, Chrome uses the mid if it's present (in which case the index is
ignored).


On Mon, Sep 3, 2012 at 8:08 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Mon, Sep 3, 2012 at 8:02 AM, Cullen Jennings (fluffy)
> <fluffy@cisco.com> wrote:
> >
> > On Aug 20, 2012, at 10:39 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >>> 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?
> >
> > Hmm, given that browser does not know when creating a candidate if the
> candidate is being used by Jingle, SIP or something else, that seems a bit
> problematic.
> >
> > Perhaps we should say when a candidate is generated by the browser, it
> will have both mid and index. When the browser consumes a candidate, if
> both are present and they do not indicate the same thing, then an error is
> reported since clearly something is borked in this case. The browser needs
> to be able to receive candidates that only have only mid or only index.
>
> I can live with that.
>
> At minimum the spec must require that they match... I could live with
> it being undefined
> to have them not match.
>
> -Ekr
>
Received on Tuesday, 4 September 2012 06:24:29 UTC

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