Re: Spec question: Declaration of IceCandidate

On Mon, Jun 18, 2012 at 7:56 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Fri, Jun 15, 2012 at 11:21 AM, Justin Uberti <juberti@google.com>
> wrote:
> > [TL;DR - see proposed IceCandidate declaration at end of this email]
> >
> > An IceCandidate needs to contain an a=candidate line and an indication of
> > which m= line it should be associated with. The m= indication is needed
> when
> > using trickle candidates, so that senders or candidate messages can
> > construct the proper protocol representation, and receivers of candidate
> > messages can know which ICE session the ICE candidate should be used in.
> >
> > For example,
> > see http://xmpp.org/extensions/xep-0176.html#protocol-renegotiate,
> where the
> > following candidate XML stanza is used; it must be possible to generate
> this
> > stanza from an IceCandidate.
> >
> > <content creator='initiator' name='this-is-the-audio-content'>
> >
> >
> >       <transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
> >
> >
> >                  pwd='asd88fgpdd777uzjYhagZg'
> >
> >
> >                  ufrag='8hhy'>
> >
> >
> >         <candidate component='1'
> >
> >
> >                    foundation='1'
> >
> >
> >                    generation='0'
> >
> >
> >                    id='m3110wc4nd'
> >
> >
> >                    ip='2001:db8::9:1'
> >
> >
> >                    network='0'
> >
> >
> >                    port='9001'
> >
> >
> >                    priority='21149780477'
> >
> >
> >                    protocol='udp'
> >
> >
> >                    type='host'/>
> >
> >
> >       </transport>
> >     </content>
> >
> > The info in <candidate> will come from the IceCandidate.candidate line,
> but
> > content.name and transport.pwd/transport.ufrag will need to come from
> > elsewhere. If IceCandidate has the 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).
>
> Note that RFC 5245 also permits a session-level ufrag/passwd. I assume
> that would still be OK?
>

Good point. The app would have to look up the credentials from the session
level if they weren't present at the media level.

>
>
> > 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
> > };
>
> This looks generally fine.
>
> -Ekr
>