- From: Eric Rescorla <ekr@rtfm.com>
- Date: Mon, 18 Jun 2012 16:56:59 -0700
- 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