Re: Spec question: Declaration of IceCandidate

On Jun 18, 2012, at 13:20 , Justin Uberti wrote:

> 
> 
> On Mon, Jun 18, 2012 at 3:00 PM, Cullen Jennings <fluffy@iii.ca> wrote:
> 
> 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.
> 
> 
> Are you suggesting we add another field, e.g.
> 
> attribute int mediaIndex;
> 
> to give the index of the m-line?
> 
> I think that would be fine too. 
> 

yes - exactly that (and of course the oblatory 300 message email debate on if the index starts at 0 or 1)

Received on Tuesday, 19 June 2012 17:29:08 UTC