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

Re: Spec question: Declaration of IceCandidate

From: Justin Uberti <juberti@google.com>
Date: Wed, 20 Jun 2012 11:00:43 -0400
Message-ID: <CAOJ7v-2OHqQKgZXc8CxOtJH+GZ1iMB626SbXo44XUcB3iZrP3A@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Cc: public-webrtc@w3.org
On Tue, Jun 19, 2012 at 11:03 AM, Cullen Jennings <fluffy@iii.ca> wrote:

>
> On Jun 18, 2012, at 13:20 , Justin Uberti wrote:
>
> >
> >
> > On Mon, Jun 18, 2012 at 3:00 PM, Cullen Jennings <fluffy@iii.ca> wrote:
> >
> > On Jun 15, 2012, at 12:21 PM, Justin Uberti wrote:
> >
> >> a=mid: value that identifies a media block, this a=mid: value can be
> used as the content.name, and transport.pwd/transport.ufrag can be looked
> up from the a=ice-ufrag, and a=ice-pwd fields present in the corresponding
> SessionDescription media block. (A SessionDescription.mediaBlock(id) method
> would be very helpful here).
> >>
> >> Not all SessionDescriptions will have a=mid: lines, but those that
> don't will not be doing trickle candidates, so we don't need to worry about
> them (other than ensuring that implementations require a=mid: in
> setLocalDescription).
> >>
> >> Therefore, I suggest the following declaration of IceCandidate. I think
> it is useful for this to be an object as opposed to a dictionary, since in
> the future we could add accessors to get at all the various candidate
> fields (component, foundation, etc).
> >>
> >> [Constructor (DOMString mediaId, DOMString candidate)]
> >> // e.g. ("audio", <a=candidate>)
> >> [Constructor (DOMString json)]
> >> // e.g. ("{ "mediaId": "audio", "candidate": <a=candidate> }")
> >>
> >>
> >> interface IceCandidate {
> >>
> >>    attribute DOMString mediaId; // corresponds to a=mid:
> >>
> >>
> >>    attribute DOMString
> >> candidate; // corresponds to a=candidate:
> >>
> >>
> >>    stringifier
> >> DOMString (); // to JSON
> >>
> >>
> >> };
> >>
> >>
> >
> >
> > I could live with this, and I get your argument that things that do
> trickle can be required to do mid, but my preference would be to also allow
> the m line to be specified with a integer index where the value n indicated
> it referred to the n'th m-line in the SDP.
> >
> >
> > Are you suggesting we add another field, e.g.
> >
> > attribute int mediaIndex;
> >
> > to give the index of the m-line?
> >
> > I think that would be fine too.
> >
>
> yes - exactly that (and of course the oblatory 300 message email debate on
> if the index starts at 0 or 1)
>
>
>
OK, sounds good. In JS indexes start at 0 :-).
Received on Wednesday, 20 June 2012 15:01:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC