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

Re: Spec question: Declaration of IceCandidate

From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 18 Jun 2012 16:56:59 -0700
Message-ID: <CABcZeBNsc=-du=Wq_pOXKq7dMOTJyHNEWU+AdEsVk1Sjp7LGgg@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: public-webrtc@w3.org
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?


> 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
Received on Monday, 18 June 2012 23:58:07 UTC

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