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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 12 February 2013 12:04 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCF921F8D2C for <mmusic@ietfa.amsl.com>; Tue, 12 Feb 2013 04:04:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.132
X-Spam-Level:
X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUxCHKDozVhY for <mmusic@ietfa.amsl.com>; Tue, 12 Feb 2013 04:04:34 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 67DFB21F8D2B for <mmusic@ietf.org>; Tue, 12 Feb 2013 04:04:33 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-73-511a2fd0c6cd
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 71.9B.32353.0DF2A115; Tue, 12 Feb 2013 13:04:32 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.004; Tue, 12 Feb 2013 13:04:32 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Flemming Andreasen <fandreas@cisco.com>, Emil Ivov <emcho@jitsi.org>
Thread-Topic: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.]
Thread-Index: AQHOBUPYqb7YkJNSREmcN/UBfO3xbphub1aAgAAveICABse7AIAAvyvA
Date: Tue, 12 Feb 2013 12:04:31 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B0D7481@ESESSMB209.ericsson.se>
References: <20130128193921.20420.53308.idtracker@ietfa.amsl.com> <51094C89.7020302@jitsi.org> <5113C177.3000507@cisco.com> <5113C3FB.3000600@cisco.com> <5113EBCD.7050901@jitsi.org> <51199BD6.8070606@cisco.com>
In-Reply-To: <51199BD6.8070606@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+Jvje4FfalAg7OdihZrdk5gsXh/Qddi 6vLHLA7MHlN+b2T1WLLkJ5PH/zeBAcxRXDYpqTmZZalF+nYJXBkrj2xnLphsV9G6+xdLA+NB oy5GTg4JAROJ24v2M0PYYhIX7q1n62Lk4hASOMQocf7GekYIZwmjxJbDa4EcDg42AQuJ7n/a IA0iAh4St698ZgOxmQUSJRralrODlAgLJEh8OsAHYooAhQ/2ykJUu0k07lrDBGKzCKhKNLw7 yw5i8wp4S5xbtZQVxBYSuMEoceqeKojNKaApca79O1g9I9Bp309B9DILiEvcejKfCeJkAYkl e85DnS8q8fLxP1YIW1Fi59l2Zoh6PYkbU6dAXaktsWzha2aIvYISJ2c+YZnAKDYLydhZSFpm IWmZhaRlASPLKkb23MTMnPRy802MwHg5uOW3wQ7GTffFDjFKc7AoifOGu14IEBJITyxJzU5N LUgtii8qzUktPsTIxMEp1cCoxfJwgUXXJ3aNng3rF2vfM9xvs+vzVcM0rdmzY70ei8e4LOA/ lLGtzGJzUELG6nl7ePqXm2dxxTR9TvCMLkgylpbsnpWzYo36vfLCk18/6zo5XBXnEmK+vJzd aOHUa0Wn3P7orgvcIXds/hLRhrUFSa7qhzRqP1asvaN90lv52nmF0/f39KgpsRRnJBpqMRcV JwIABVGZPmUCAAA=
Cc: Ari Keränen <ari.keranen@ericsson.com>, MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE comments [Re: Trickle ICE update and a new SIP usage draft.]
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Feb 2013 12:04:35 -0000

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: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] 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: internet-drafts@ietf.org
>>>> To: emcho@jitsi.org
>>>> CC: justin@uberti.name, ekr@rtfm.com
>>>>
>>>>
>>>> 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
>>>> mmusic@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> .
>>>>
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic