Re: Spec question: Declaration of IceCandidate

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 :-).