Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.]

[Emil Ivov <[e-mail]>]

Hey Flemming,

We did have an intense discussion about parts of this message and in
preparation for Tuesday, I thought it would be good to address the
others. Sorry this took so long!

Answers inline:

On 07.02.13, 10:00, Flemming Andreasen wrote:
> Hi
> 
> I took a look the trickle-ice draft and have a couple of questions/comments:
> 
> 1) Section 1 says
> <quote>
>    This specification does not define usage of trickle ICE with any
>    specific signalling protocol, contrary to [RFC5245] which contains a
>    usage for ICE wht SIP.  Such usages would have to be specified in
>    separate documents.
> </quote>
> however you do define it specifically using SDP and Offer/Answer (I
> believe). It would be worthwhile calling that out.

Well, the sentence immediately following your quotation does say:

   Trickle ICE does however reuse and build upon the SDP syntax defined
   by vanilla ICE.

Doesn't this address your concern?

> 2) Section 5.1 says
> <quote>
>    As mentioned earlier in this section, Offers and Answers can contain
>    any set of candidates, which means that a trickle ICE session
>    description MAY contain no candidates at all.  In such cases the
>    agent would still need to place an address in the "c=" line(s).  If
>    the use of a host address there is undesirable (e.g. for privacy
>    reasons), the agent MAY set the connection address to 0.0.0.0.  In
>    this case it MUST also set the port number to 1.  There is no need to
>    include a fictitious 0.0.0.0 candidate when doing so.
> <quote>
> I had to read this several times before I (think) I understood that when
> you say "the agent MAY set the connection address to 0.0.0.0", you are
> referring to the connection address in the "a=candidate" attribute, not
> the "c=" line. Can you clarify and rephrase accordingly.

But we are indeed talking about the c= line. Could you please be a bit
more explicit about the part you find confusing?

> 3) Section 9.1
> I'm confused about this whole section and it's premise that
> "a=candidate" attributes and media descriptions are not clearly linked.
> The "a=candidate" attribute is defined as a media-level attribute only
> and describes as such in RFC 5245, so I must be missing something here.

This is about trickled candidates. We say that when sending them they
should be encoded with the usual syntax:

a=candidate:2 1 UDP 1658497328 198.51.100.33 5000 typ host

Yet, this syntax does not provide a relation to an m-line. The draft
says that this relation should happen through an MID (we agreed to ditch
reliance on m-lines during the interim) but the exact syntax is left to
the usages.

> 4) Section 9.2. Rather than talking about sending "end of candidates"
> via "the signalling channel" (which is not defined), could we change
> this to say and "end of candidates" need to be sent to the peer, and the
> only mechanism defined to do so in this document is through an O/A
> exchange (new exchange or answer to an offer) ?

To me this sounds confusing. As if we were saying: you can only send
end-of-candidates in an offer or an answer, which is clearly not the
case. In the general case end-of-candidates will be send through some
non-O/A mechanism specific to the various signalling protocols.

> 5) Section 14 (Example)
> The exchange of the "additional candidates" does not use an O/A
> exchange.

Correct, it does not.

> As for comment 4), this assumes some other un-defined
> mechanism somewhere 

Right. Just as the entire transport of the trickled candidates.

>- would it be useful to show it as an O/A exchange
> as well, but note that other mechanisms may be defined ?

Well the only way you could put end-of-candidates in an Offer or an
Answer is if you are not planning on trickling any candidates after it.
Using this for the example would kind of defeat its purpose.

> 6) Section A.1 (MID/Stream Indicates in SDP)
> I'm still unclear on this (per comment 3).

Hopefully my comment made it clearer. Let me know if not.

Cheers,
Emil
> 
> 
> Thanks
> 
> -- Flemming (as Individual)
> 
> 
> 
> On 1/30/13 11:38 AM, Emil Ivov wrote:
>> Hey all,
>>
>> Justin, Eric and I have just submitted an update to the trickle ICE
>> draft, accommodating comments from Atlanta:
>>
>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00
>>
>> More details about the changes here:
>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00#appendix-B
>>
>> Diff2:
>> http://www.ietf.org/rfcdiff?url1=draft-rescorla-mmusic-ice-trickle-01&difftype=--html&submit=Go!&url2=draft-ivov-mmusic-trickle-ice-00
>>
>> During the MMUSIC presentation and the mailing list discussions it was
>> also pointed out that it is important for this work to happen in
>> parallel with a SIP usage for trickle ICE. Enrico, Christer and I have
>> therefore submitted the following document:
>>
>> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00
>>
>> As always, comments are welcome!
>>
>> Cheers,
>> Emil
>>
>> -------- Original Message --------
>> Subject: New Version Notification for draft-ivov-mmusic-trickle-ice-00.txt
>> Date: Mon, 28 Jan 2013 11:39:21 -0800
>> From: [e-mail]
>> To: [e-mail]
>> CC: [e-mail], [e-mail]
>>
>>
>> A new version of I-D, draft-ivov-mmusic-trickle-ice-00.txt
>> has been successfully submitted by Emil Ivov and posted to the
>> IETF repository.
>>
>> Filename:	 draft-ivov-mmusic-trickle-ice
>> Revision:	 00
>> Title:		 Trickle ICE: Incremental Provisioning of Candidates for the
>> Interactive Connectivity Establishment (ICE) Protocol
>> Creation date:	 2013-01-28
>> WG ID:		 Individual Submission
>> Number of pages: 20
>> URL:
>> http://www.ietf.org/internet-drafts/draft-ivov-mmusic-trickle-ice-00.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-ivov-mmusic-trickle-ice
>> Htmlized:        http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-00
>>
>>
>> Abstract:
>>    This document describes an extension to the Interactive Connectivity
>>    Establishment (ICE) protocol that allows ICE agents to send and
>>    receive candidates incrementally rather than exchanging complete
>>    lists.  With such incremental provisioning, ICE agents can begin
>>    connectivity checks while they are still gathering candidates and
>>    considerably shorten the time necessary for ICE processing to
>>    complete.
>>
>>    The above mechanism is also referred to as "trickle ICE".
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> .
>>
> 

-- 
https://jitsi.org