- From: Cullen Jennings <fluffy@iii.ca>
- Date: Mon, 18 Jun 2012 13:00:23 -0600
- To: Justin Uberti <juberti@google.com>
- Cc: public-webrtc@w3.org
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