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

[Emil Ivov <[e-mail]>]

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
> 

-- 
https://jitsi.org