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

Re: Spec question: Declaration of IceCandidate

From: Cullen Jennings <fluffy@iii.ca>
Date: Mon, 18 Jun 2012 13:00:23 -0600
Cc: public-webrtc@w3.org
Message-Id: <677A50B7-77DC-4630-B870-4BE92933BFD4@iii.ca>
To: Justin Uberti <juberti@google.com>

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. 
Received on Monday, 18 June 2012 19:00:49 UTC

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