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

[Ari Keränen <[e-mail]>]

Hi,

This clearly needs to be clarified in ICE-bis.

Regarding which way ("just support" or "support and will use") it should 
be clarified, we have one precedent. RTP+ECN RFC says 
(http://tools.ietf.org/html/rfc6679#section-6.4):

>    The answering party includes this same attribute at the session level
>    in the SDP answer if it also has the capability and removes the
>    attribute if it does not wish to use ECN or doesn't have the
>    capability to use ECN.

This seems to imply that it should be "support and will use" to be 
consistent with current registration(s). And this would be consistent 
with the current Trickle ICE too.

Then, should we have also "ice-supported" attribute, or SIP option-tag, 
or nothing? I wonder in what case would one use only the "supported"? 
Would the semantics be "I support but will not use unless you indicate 
that you want to use", or something else?


Cheers,
Ari
(as individual)

On 2/12/13 2:04 PM, Christer Holmberg wrote:
> Hi,
>
> When a SIP dialog is established, entities normally don't indicate
> support for features that they don't want to use within that dialog.
>
> However, if the semantics of ice-options is unclear, another
> alternative is to define a SIP option-tag, which provides more
> freedom to specify the semantics for individual option-tags.
>
> Regards,
>
> Christer
>
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Flemming Andreasen
> Sent: 12. helmikuuta 2013 3:33 To: Emil Ivov Cc: Ari Keränen; MMUSIC
> IETF WG Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE
> update and a new SIP usage draft.]
>
> 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#appendi
>>>>>
>>>>>
x-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-0
>>>>>
>>>>>
0.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
>
> _______________________________________________ mmusic mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/mmusic
>