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

[Flemming Andreasen <[e-mail]>]

Hi Emil

As noted at the Interim meeting, I think it's cleaner to have 
ice-options used to strictly indicate features supported, and then have 
a separate way of indicating their use.

However, in taking another look at RFC 5245, it's somewhat unclear what 
semantics were intended. Section 15.5 for example suggests "supported" 
semantics, however Section 21.1.7 suggests "used" semantics. There are a 
few more examples of each throughout the doc so I agree with you that 
5245bis should clarify this (and depending on that clarification, we 
should use it the same way here).

Thanks

-- Flemming


On 2/7/13 1:00 PM, Emil Ivov wrote:
> Hey Flemming, Ted, all,
>
> On 07.02.13, 10:10, Flemming Andreasen wrote:
>> 7) It seems the inclusion of the "trickle" ice-options is what will
>> trigger the use of tricke-ICE. I think this is a slight overloading of
>> the ice-options semantics inasmuch as it is intended to indicate support
>> for a given extension, which does not necessarily imply you actually
>> want to use that extension. I think it would be useful to have a
>> separate way of indicating you also want to use trickle-ICE.
> The intention of the current trickle ICE text is to say the following:
>
> 1. When your (the offerer's) intention is to do half trickle you include
> the "trickle" ice-options token and you are prepared to have the
> answerer trickling. You are also prepared to have them do vanilla ICE.
> In either case you can either include end-of-candidates in your offer or
> you can choose to not include it depending on how you intend to behave
> if the answerer turns out to support trickle.
>
> 1.1. If the answer does indicate support trickle ICE by the answerer,
> then you are both abiding by the trickle-ice spec. You can both still
> choose to behave like vanilla ICE agents and send complete sets of
> candidates from the start but you know that you have to handle trickle
> semantics and you know that you have to send end-of-candidates when you
> are done.
>
> 1.2 If the answerer does not support trickle, then there's no "trickle"
> ice-options token in the answer and the offerer knows that trickling is
> no longer possible (regardless of whether or not there was
> end-of-candidates in the offer).
>
> 2. If the offerer's intention is to generate a vanilla ICE offer then it
> does not include the "trickle" ice-options token and everyone just uses
> vanilla ICE semantics.
>
> I believe that this is the part in 5245 that you had a problem with and
> I think that this is the text you are referring to:
>
>      First, ICE provides the a=ice-options SDP attribute.  Each extension
>      or change to ICE is associated with a token.  When an agent
>      supporting such an extension or change generates an offer or an
>      answer, it MUST include the token for that extension in this
>      attribute.  *This allows each side to know what the other side is
>      doing*.  This attribute MUST NOT be present if the agent doesn't
>      support any ICE extensions or changes.
>
> I am not sure exactly what the intention of this text was (maybe we
> could clarify this in 5245bis) but that highlighted part makes me think
> the point was to make sure everyone knows what behaviour to expect
> rather than what features they have in their ICE stack even if they are
> not planning on using them.
>
> In that sense, if I send what I intend to be a vanilla offer then you
> can count on me not to use any trickle semantics and you would make me
> really unhappy if you did it yourself (because I might be gateway-ing
> your stuff to a vanilla agent). In that sense I'd really like you to
> behave as if I were a vanilla ICE agent.
>
> In other words, I believe it would be legitimate for me not to include
> the "trickle" token in ice-options.
>
> Does this make sense?
>
> Emil
>
>> Thanks
>>
>> -- Flemming
>>
>>
>>> 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
>>>> .
>>>>
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic