Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory
"Stach, Thomas" <thomas.stach@siemens-enterprise.com> Wed, 10 April 2013 07:18 UTC
Return-Path: <thomas.stach@siemens-enterprise.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 9B2C321F8FC6 for <mmusic@ietfa.amsl.com>; Wed, 10 Apr 2013 00:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tnm7EY2M0BZm for <mmusic@ietfa.amsl.com>; Wed, 10 Apr 2013 00:18:47 -0700 (PDT)
Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 51BF521F8FA5 for <mmusic@ietf.org>; Wed, 10 Apr 2013 00:18:47 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 976CF23F0491; Wed, 10 Apr 2013 09:18:46 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.169]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Wed, 10 Apr 2013 09:18:46 +0200
From: "Stach, Thomas" <thomas.stach@siemens-enterprise.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Emil Ivov <emcho@jitsi.org>
Thread-Topic: AW: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory
Thread-Index: AQHONSYruecfKNfWd0Owxkajp9hYoJjPC6zA
Date: Wed, 10 Apr 2013 07:18:45 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE120E575BEF@MCHP04MSX.global-ad.net>
References: <515AFCFE.7030608@acm.org> <515CB4F2.3010404@jitsi.org> <F81CEE99482EFE438DAE2A652361EE120E5725E2@MCHP04MSX.global-ad.net> <515F1D24.8040703@jitsi.org> <515F21AA.2080003@alum.mit.edu> <515FBA77.1030007@jitsi.org> <F81CEE99482EFE438DAE2A652361EE120E573FA4@MCHP04MSX.global-ad.net> <51633ED7.4080407@jitsi.org> <51641792.2050100@alum.mit.edu>
In-Reply-To: <51641792.2050100@alum.mit.edu>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory
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: Wed, 10 Apr 2013 07:18:48 -0000
inline > -----Ursprüngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Gesendet: Dienstag, 09. April 2013 15:29 > An: Emil Ivov > Cc: Stach, Thomas; mmusic@ietf.org > Betreff: Re: AW: [MMUSIC] > draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle- > ice - PRACK not mandatory > > On 4/9/13 6:04 AM, Emil Ivov wrote: > > Hey Thomas, > > > > On 08.04.13, 14:15, Stach, Thomas wrote: > >> I agree, that Paul has a good point. > >> However, I still do not see a requirement for PRACK. > >> I would still like to avoid it due to the big debate > during development of ICE that occurred back in IETF64. > > > > For those of us who weren't around back then, it would help > if you could > > remind exactly what the reasons were. This way we can decide if they > > also apply to the trickle ICE case. > > My argument was that without a reliable provisional the UAS can't be > certain that the UAC has established an early dialog, and > without that > the UAC can't trickle using INFO. > > Thinking further, *if* the UAS keeps retransmitting the unreliable > provisional until it receives some ICE messages then things may work. > But in the case of trickle ICE this might effectively mean > that it must > keep retransmitting until it receives an INFO with additional > candidates, ... or if the UAS receives a 200 OK (instead of 481) for an INFO request. That would also indicate that the 18X was received and the early dialog was established. Regards Thomas > because none of the initial candidates may be usable. > > Thanks, > Paul > > >> Once the UAS has sent the 183 there is an early dialog. > >> Of course the 183 can be lost, such that UAS and UAC are > out of sync with respect to the dialog state. > >> > >> Now, RFC5245 specifies (in case PRACK is not used) that > the provisional response is retransmitted > >> with the exponential backoff timers. I want to keep this > behaviour also for trickle ICE because now > >> the UAC will eventually receive one of the retransmissions > and could also send trickled candidates. > > > > Not necessarily. The UAC may be performing half trickle in > which case it > > won't be sending anything else. > > > >> Interesting is of course what happens with the INFO if the > UAC has not yet received a provisional response. > >> I would expect receipt of a 481 response to the INFO > request since the UAC does not yet know about the dialog. > >> This 481 could trigger at the UAS the immediate > retransmission of the provisional response > >> in order to establish the early dialog. Then, the INFO > could also be retransmitted. > > > > This could indeed work and it could potentially help gain > almost up to > > an RTT. Anyone has a problem with it? > > > >> Of course you are right. > >> However, since the INFO can carry arbitrary SDP fragments, > you can also include ufrag and password > >> and any of the other ICE attributes. > > > > I didn't mean to imply you couldn't, however Paul's > comment, discussed > > above, killed this approach anyway. > > > > Cheers, > > Emil > > > >> > >> > >> Regards > >> Thomas > >> > >> Emil Ivov wrote: > >>> On 05.04.13, 21:10, Paul Kyzivat wrote: > >>>> Note that until at least one provisional response makes > it back to > >>>> the UAC it won't be possible for the UAC to send INFOs. > (It can't do > >>>> so until there is an early dialog.) > >>>> > >>>> So its possible that if you only send unreliable > provisionals then > >>>> the trickling from UAC to UAS may not be happen until the call is > >>>> established. > >>> > >>> Great point! So it seems like we are back to mandating PRACK. > >>> > >>> What would be the issue with this anyway? > >>> > >>> Emil > >>> > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 4/6/13 2:51 AM, Emil Ivov wrote: > >>>>> Hey Thomas, > >>>>> > >>>>> On 05.04.13, 12:04, Stach, Thomas wrote: > >>>>>> inline > >>>>>> > >>>>>> Emil Ivov wrote: > >>>>>>> Hey Marc and thanks for your comments! > >>>>>>> > >>>>>>> Replies inline. > >>>>>>> > >>>>>>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote: > >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>>>> Hash: SHA256 > >>>>>>>> > >>>>>>>> I read draft-ivov-dispatch-trickle-ice-sip and > >>>>>>>> draft-ivov-mmusic-trickle-ice during the preparation of the > >>>>>>>> rfc5245bis draft and I have some suggestions that I will be > >>>>>>>> presenting step by step below: > >>>>>>>> > >>>>>>>> 1. The 180 needs to be reliable > >>>>>>> > >>>>>>> Agreed. We'll make the change in the next revision. > >>>>>>> > >>>>>> The answer with any initial candidates needs to be in > a 183 not a > >>>>>> 180. > >>>>> > >>>>> Well 5245 actually talks about 18x but I agree that > using 183 rather > >>>>> than 180 would help manage post pick-up latency better. > >>>>> > >>>>>> In addition, I don't think that the 183 needs to be reliable. > >>>>>> This was not necessary for RFC5245 and could also be > >>> avoided for trickle ICE, since the > >>>>>> INFO with the new candidates is already reliably sent. > >>>>> > >>>>> Well, it's not only about the candidates (the 183 could actually > >>>>> contain none of those). However, we'd also need to make > sure that > >>>>> things like the ufrag and password are also received. > >>>>> > >>>>>> If the INFO contains always the complete list of > >>> candidates (instead of just a delta), the ICE agents will > >>>>>> eventually have all candidates even if the 183 with the > >>> initial candidates got lost with the initial candidates. > >>>>>> As an optimisation if you don't want to always send > the complete > >>>>>> list, you could just include it in the first INFO and > use deltas > >>>>>> afterwards. > >>>>> > >>>>> I like this suggestion and I agree we could add something along > >>>>> those lines in case PRACK is not user or supported. > >>>>> > >>>>> Thanks for the tip! > >>>>> Emil > >>>>>> > >>>>>> > >>>>>> Regards > >>>>>> Thomas > >>>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> mmusic mailing list > >>>> mmusic@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mmusic > > > >
- [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draf… Marc Petit-Huguenin
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Stach, Thomas
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Marc Petit-Huguenin
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Paul Kyzivat
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Paul Kyzivat
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Marc Petit-Huguenin
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Emil Ivov
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Paul Kyzivat
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Marc Petit-Huguenin
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Emil Ivov
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Emil Ivov
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Alan Johnston
- [MMUSIC] Using connectivity check to carry additi… Marc Petit-Huguenin
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Stach, Thomas
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Emil Ivov
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Paul Kyzivat
- Re: [MMUSIC] Using connectivity check to carry ad… Martin Thomson
- Re: [MMUSIC] Using connectivity check to carry ad… Marc Petit-Huguenin
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Emil Ivov
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Stach, Thomas
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Stach, Thomas
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Emil Ivov
- [MMUSIC] Trickle ICE Dale R. Worley
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Stach, Thomas
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Paul Kyzivat
- Re: [MMUSIC] Trickle ICE Stach, Thomas
- Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/… Stach, Thomas