Return-Path: 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 493CC21E80C4 for ; Tue, 18 Sep 2012 05:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 sy-F8gkV6pUP for ; Tue, 18 Sep 2012 05:07:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A980221E80C1 for ; Tue, 18 Sep 2012 05:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30196; q=dns/txt; s=iport; t=1347970040; x=1349179640; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H59QoniL6qZSAdXG2vWiUalg2WS09lAe4bBHDUjK2nA=; b=eIsshGz8A7jv03GuVPTbceXYqIL429MVXXkYQgVl5r9i968+J56LEsQo N7gvjHirOV3H3D/Kd6ftOVC/Ga1p/UN0OyAkj9WjAJtLqPFlD1Wo7kcu/ Pxab7y3MeWNwb/3RYEpllzmd2eqCjUDP+Xb/1NgouaI+3Q5acU/80xMXV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPliWFCtJXG9/2dsb2JhbABFgku5aIEHgiABAQEDAQEBAQ8BBxM/AgQFAgUHAgICAQgOAwQBAQEKFgcHGwwLFAkIAgQOBQgBGYdYBguZf6AzBIsdhghgA5IxhEWNJIFpgmaCFw X-IronPort-AV: E=Sophos; i="4.80,442,1344211200"; d="scan'208,217"; a="122694013" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 18 Sep 2012 12:07:19 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8IC7Jdf016470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 12:07:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 07:07:19 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Emil Ivov Thread-Topic: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt Thread-Index: AQHNY6F+/LEFvCvLC0CLcDi4fxclSZcx8gqQgAAM1pCAVrIoAP//1knQgAbzf4D//8gbsIABTTgA//+uX4A= Date: Tue, 18 Sep 2012 12:07:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147AB976@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A052D666F@xmb-rcd-x10.cisco.com> <5051A76A.7090606@jitsi.org> <913383AAA69FF945B8F946018B75898A147AA88C@xmb-rcd-x10.cisco.com> <5057592B.9070904@jitsi.org> <913383AAA69FF945B8F946018B75898A147AB415@xmb-rcd-x10.cisco.com> <505841CE.30602@jitsi.org> In-Reply-To: <505841CE.30602@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.29.82] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004 x-tm-as-result: No--26.863400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A147AB976xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "Prashanth Patil \(praspati\)" , "mmusic@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 12:07:23 -0000 --_000_913383AAA69FF945B8F946018B75898A147AB976xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: Tuesday, September 18, 2012 3:12 PM > To: Tirumaleswar Reddy (tireddy) > Cc: mmusic@ietf.org; Dan Wing (dwing); Prashanth Patil (praspati); Pal > Martinsen (palmarti) > Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice- > mobility-01.txt > > Hey Tiru, > > On 18.09.12, 04:56, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- From: Emil Ivov > >> [mailto:emcho@jitsi.org] Sent: Monday, September 17, 2012 10:39 PM > >> To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org; Dan Wing > >> (dwing); Prashanth Patil (praspati); Pal Martinsen (palmarti) > >> Subject: Re: [MMUSIC] New Version Notification for > >> draft-wing-mmusic-ice- mobility-01.txt > >> > >> Hey Tiru, > >> > >> On 17.09.12, 18:47, Tirumaleswar Reddy (tireddy) wrote: > >>> Hi Emil - > >>> > >>> Thanks for the comments. we are in the process of updating the > >>> draft - > >>> > >>> We are planning to add the high-lighted sentence in Introduction, > >>> please let us know if you have any further comments. > >>> > >>> Although ICE does allow an "ICE restart", this is done by sending > >>> a re-INVITE which goes over the SIP signaling path. The SIP > >>> signaling path is often slower than the media path (which needs > >>> to be recovered as quickly as possible), consumes an extra half > >>> round trip, and incurs an additional delay if the mobility event > >>> forces the endpoint to re-connect with its SIP proxy. *When a > >>> device changes its IP address, it is necessary for it to > >>> re-establish connectivity with its SIP proxy, which can be > >>> performed in parallel with the steps described in this > >>> document.* This document describes how mobility is performed > >>> entirely in the media path, without the additional delay of > >>> re-establishing SIP connectivity, issuing a new offer/answer, or > >>> the complications of multiple SIP offers. This document considers > >>> re-establishing bi-directional media the most critical aspect of > >>> a successful mobility event, and its efforts are towards meeting > >>> that goal. > >>> > >>> We will also added the following text at the end of section 3.1 > >>> > >>> *The Mobile device would also in parallel re-establish connection > >>> with the SIP proxy and if the ICE connectivity checks in the > >>> previous steps are not successful then issues new offer/answer > >>> and restarts ICE.* > >> > >> The above statement implies that the mobile node would need to > >> first declare failure of ICE mobility and only then would it try an > >> ICE restart. Yet, declaring failure would take many seconds with > >> the default STUN timers so as a result handover latency is probably > >> going to worsen more often than not. > > > > The only reason I can think why ICE Mobility would fail and ICE > > restart succeed is because of Simultaneous Mobility > > Well ... I might be missing something but it seems to me that the only > time it would succeed would be when there's a direct reachability > between the mobile node's new address and their correspondent. > > This would be the case when the mobile node has moved into the same > NATed network as the correspondent, or when the correspondent has a > public address with no one to perform endpoint dependent filtering in > front of them. > > In all other situations (which would likely represent the majority of > the cases) ICE mobility would fail and one would need to perform an ICE > restart. > > Emil Hi Emil, Thanks for the review. I have assumed that the other Mobile Device (Correspondent Node in this cas= e) would include MOBILITY-SUPPORT only in the following cases : IPv6 Global Address, Correspondent Node is behind Endpoint-Independent Mapp= ing/Filtering NAT as recommended in RFC 4787. But to make it work in other scenarios where Correspondent Node(CN) is behi= nd Address-Dependent Filtering/Mapping, CN can detect the NAT behavior usin= g simple tests suggested in RFC 5780 and so not include MOBILITY-SUPPORT at= tribute. [Even without ICE Mobility, if both Mobile devices are behind non-BEHAVE co= mpliant NAT then ICE connectivity checks using host/server-reflexive candid= ates will fail and end up using UDP relay] =3D=3D=3D Section 3 Endpoints that support ICE Mobility perform ICE normally, and MUST also inc= lude the MOBILITY-SUPPORT attribute in all of their STUN requests and their= STUN responses. The inclusion of this attribute allows the ICE peer to det= ermine if it can achieve mobility using ICE or needs to use TURN (or needs = to use some other mechanism, such as Mobile IP). To force the use of TURN t= o achieve ICE mobility, the ICE endpoint SHOULD NOT respond to ICE connecti= vity checks that have an IP address and port different from the TURN server= , unless those connectivity checks contain the MOBILITY-SUPPORT attribute. = In this way, the remote peer will think those other candidates are invalid = (because its connectivity checks did not succeed). =3D=3D=3D --Tiru. > > > we are trying to > > solve the problem in a different way (This text is yet to be > > published in the next version of the draft) > > > > 3.3 Simultaneous Mobility > > > > Mobile device SHOULD include MOBILTY-ROAM attribute in all of its > > STUN requests and STUN responses. If the ICE peer also includes > > MOBILTY-ROAM attribute in all its STUN requests and STUN responses > > then it means both the endpoints are mobile and can roam at the same > > time between networks. In order to support simultaneously mobility > > without breaking media sessions between them, both ICE agents MUST > > perform the following steps : > > > > 1. The ICE agent will keep the relayed candidates alive using > > Refresh transaction, as described in [RFC5766]. > > > > 2. When gaining an interface, the ICE agent will refresh it's > > allocation with TURN server using Section 4.2. > > > > 3. The ICE agent will perform the steps described in Section 3.1. > > > > 4. If the ICE connectivity check succeeds only with local and > > remote relayed candidates, it suggests that even the other peer is > > roaming at the same time. The ICE agent creates a new pair using the > > relayed candidates, adds the pair to the valid list and marks it as > > selected. The ICE agent can now send media using the newly selected > > relayed candidate pair. The Mobile device in parallel re-establishes > > connection with SIP proxy, issues new offer/answer and restarts ICE. > > Hence media will only be sent briefly on TURN relays. > >> > >> Besides, even in cases where ICE mobility succeeds, an ICE restart > >> could still allow the use of higher priority candidates. > > > > ICE Mobility will pick the candidates on the new interface based on > > priority (RFC 3484 or latest RFC 6724). Is there any specific case > > you have in mind that ICE restart would pick higher priority > > candidates and not ICE Mobility other than Simultaneous Mobility > > problem ? > > > > --Tiru. > > > >> > >> Wouldn't it make more sense to always perform an ICE restart in > >> parallel and basically consider ICE mobility a best effort attempt > >> to shorten handover latency? > >> > >> Emil -- https://jitsi.org > >>> > >>> --Tiru. > >>> > >>>> -----Original Message----- From: Emil Ivov > >>>> [mailto:emcho@jitsi.org] Sent: Thursday, September 13, 2012 > >>>> 2:59 PM To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org > >>>> Subject: Re: [MMUSIC] New Version Notification for > >>>> draft-wing-mmusic-ice- mobility-01.txt > >>>> > >>>> Hey Tiru, > >>>> > >>>> One thing that I think this document is not very clear about is > >>>> its relationship to standard mobility handling (i.e. through > >>>> ICE restart). > >>>> > >>>> As far as I can see, ICE restart is only mentioned when > >>>> describing its inefficiency. > >>>> > >>>> You did confirm in Vancouver that ICE Mobility is only meant as > >>>> an optimisation that would only take place until the ICE > >>>> restart completes but I don't see it anywhere in the text. Or > >>>> am I missing something? > >>>> > >>>> Cheers, Emil > >>>> > >>>> On 20.07.12, 13:36, Tirumaleswar Reddy (tireddy) wrote: > >>>>> Hi all, > >>>>> > >>>>> Dan, Prashanth and I have submitted a draft that explains > >>>>> how endpoint mobility can be achieved using ICE. Two > >>>>> mechanisms are shown, one where both endpoints support ICE > >>>>> and another where only one endpoint supports ICE. When only > >>>>> one endpoint supports ICE, a TURN server provides mobility. > >>>>> > >>>>> _http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility= - > >> > >>>>> > 01.txt_ > >>>>> > >>>>> Please let know your comments. If time permits we'd present > >>>>> the draft in Vancouver. > >>>>> > >>>>> Regards, Tiru. > >>>>> > >>>>>> -----Original Message----- From: Tirumaleswar Reddy > >>>>>> (tireddy) Sent: Friday, July 20, 2012 3:18 PM To: > >>>>>> _mmusic@ietf.org_ > >> Subject: FW: New > >>>>>> Version Notification for draft-wing-mmusic-ice- > >>>>>> mobility-01.txt > >>>>>> > >>>>>> -----Original Message----- From: > >>>>>> _internet-drafts@ietf.org_ > >> > >>>>>> _[mailto:internet-drafts@ietf.org]_ > >>> Sent: Tuesday, July > >>> 17, 2012 3:52 > >>>>>> AM To: Dan Wing (dwing) Cc: Prashanth Patil (praspati); > >>>>>> Tirumaleswar Reddy (tireddy) Subject: New Version > >>>>>> Notification for draft-wing-mmusic-ice-mobility- 01.txt > >>>>>> > >>>>>> > >>>>>> A new version of I-D, draft-wing-mmusic-ice-mobility-01.txt > >>>>>> has been successfully submitted by Dan Wing and posted to > >>>>>> the IETF repository. > >>>>>> > >>>>>> Filename: draft-wing-mmusic-ice-mobility Revision: > >>>>>> 01 Title: Mobility with ICE (MICE) Creation date: > >>>>>> 2012-07-16 WG ID: Individual Submission Number of pages: 12 > >>>>>> URL: > >>>>>> _http://www.ietf.org/internet-drafts/draft-wing-mmusic-_ > >>>>>> ice-mobility-01.txt Status: > >>>>>> _http://datatracker.ietf.org/doc/draft-wing-mmusic-ice-_ > >>>>>> mobility Htmlized: > >>>>>> _http://tools.ietf.org/html/draft-wing-mmusic-ice-_ > >>>>>> mobility-01 Diff: > >>>>>> _http://tools.ietf.org/rfcdiff?url2=3Ddraft-wing-mmusic-_ > >>>>>> ice-mobility-01 > >>>>>> > >>>>>> Abstract: This specification describes how endpoint > >>>>>> mobility can be achieved using ICE. Two mechanisms are > >>>>>> shown, one where both endpoints support ICE and another > >>>>>> where only one endpoint supports ICE. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> The IETF Secretariat > >>>>> _______________________________________________ mmusic > >>>>> mailing list _mmusic@ietf.org_ > >>> _https://www.ietf.org/mailman/listinfo/mmusic_ > >>>>> > > > > -- > Emil Ivov, Ph.D. 67000 Strasbourg, > Project Lead France > Jitsi > emcho@jitsi.org PHONE: +33.1.77.62.43.30 > https://jitsi.org FAX: +33.1.77.62.47.31 --_000_913383AAA69FF945B8F946018B75898A147AB976xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
> -----Original Message-----
> From: Emil Ivov [mailto:emcho@= jitsi.org]
> Sent: Tuesday, September 18, 2012 3:12 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: mmusic@ietf.org; Dan Wing (dwing); Prashanth Patil (praspati)= ; Pal
> Martinsen (palmarti)
> Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmu= sic-ice-
> mobility-01.txt
>
> Hey Tiru,
>
> On 18.09.12, 04:56, Tirumaleswar Reddy (tireddy) wrote:
> >> -----Original Message----- From: Emil Ivov
> >> [mailto:emcho@jitsi.o= rg] Sent: Monday, September 17, 2012 10:39 PM
> >> To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org; Da= n Wing
> >> (dwing); Prashanth Patil (praspati); Pal Martinsen (palm= arti)
> >> Subject: Re: [MMUSIC] New Version Notification for
> >> draft-wing-mmusic-ice- mobility-01.txt
> >>
> >> Hey Tiru,
> >>
> >> On 17.09.12, 18:47, Tirumaleswar Reddy (tireddy) wrote:<= /div>
> >>> Hi Emil -
> >>>
> >>> Thanks for the comments. we are in the process of up= dating the
> >>> draft -
> >>>
> >>> We are planning to add the high-lighted sentence in = Introduction,
> >>> please let us know if you have any further comments.=
> >>>
> >>> Although ICE does allow an "ICE restart", = this is done by sending
> >>> a re-INVITE which goes over the SIP signaling path. = The SIP
> >>> signaling path is often slower than the media path (= which needs
> >>> to be recovered as quickly as possible), consumes an= extra half
> >>> round trip, and incurs an additional delay if the mo= bility event
> >>> forces the endpoint to re-connect with its SIP proxy= . *When a
> >>> device changes its IP address, it is necessary for i= t to
> >>> re-establish connectivity with its SIP proxy, which = can be
> >>> performed in parallel with the steps described in th= is
> >>> document.* This document describes how mobility is p= erformed
> >>> entirely in the media path, without the additional d= elay of
> >>> re-establishing SIP connectivity, issuing a new offe= r/answer, or
> >>> the complications of multiple SIP offers. This docum= ent considers
> >>> re-establishing bi-directional media the most critic= al aspect of
> >>> a successful mobility event, and its efforts are tow= ards meeting
> >>> that goal.
> >>>
> >>> We will also added the following text at the end of = section 3.1
> >>>
> >>> *The Mobile device would also in parallel re-establi= sh connection
> >>> with the SIP proxy and if the ICE connectivity check= s in the
> >>> previous steps are not successful then issues new of= fer/answer
> >>> and restarts ICE.*
> >>
> >> The above statement implies that the mobile node would n= eed to
> >> first declare failure of ICE mobility and only then woul= d it try an
> >> ICE restart. Yet, declaring failure would take many seco= nds with
> >> the default STUN timers so as a result handover latency = is probably
> >> going to worsen more often than not.
> >
> > The only reason I can think why ICE Mobility would fail and = ICE
> > restart succeed is because of Simultaneous Mobility
>
> Well ... I might be missing something but it seems to me that the= only
> time it would succeed would be when there's a direct reachability=
> between the mobile node's new address and their correspondent.
>
> This would be the case when the mobile node has moved into the sa= me
> NATed network as the correspondent, or when the correspondent has= a
> public address with no one to perform endpoint dependent filterin= g in
> front of them.
>
> In all other situations (which would likely represent the majorit= y of
> the cases) ICE mobility would fail and one would need to perform = an ICE
> restart.
>
> Emil
 
Hi Emil,
 
Thanks for the review.
 
I have assumed that the other Mobile Device (Correspondent Node in thi= s case) would include MOBILITY-SUPPORT only in the following cases :
IPv6 Global Address, Correspondent Node is behind Endpoint-Independent= Mapping/Filtering NAT as recommended in RFC 4787.
 
But to make it work in other scenarios where Correspondent Node(CN) is= behind Address-Dependent Filtering/Mapping, CN can detect the NAT behavior= using simple tests suggested in RFC 5780 and so not include MOBILITY-SUPPO= RT attribute.
 
[Even without ICE Mobility, if both Mobile devices are behind non-BEHA= VE compliant NAT then ICE connectivity checks using host/server-reflexive c= andidates will fail and end up using UDP relay]
 
=3D=3D=3D
Section 3
 
Endpoints that support ICE Mobility perform ICE normally, and MUST als= o include the MOBILITY-SUPPORT attribute in all of their STUN requests and = their STUN responses. The inclusion of this attribute allows the ICE peer t= o determine if it can achieve mobility using ICE or needs to use TURN (or needs to use some other mechanism, such = as Mobile IP). To force the use of TURN to achieve ICE mobility, the ICE= endpoint SHOULD NOT respond to ICE connectivity checks that have an IP add= ress and port different from the TURN server, unless those connectivity checks contain the MOBILITY-SUPPORT = attribute. In this way, the remote peer will think those other candidates a= re invalid (because its connectivity checks did not succeed).
=3D=3D=3D
 
--Tiru.
 
>
> > we are trying to
> > solve the problem in a different way (This text is yet to be=
> > published in the next version of the draft)
> >
> > 3.3 Simultaneous Mobility
> >
> > Mobile device SHOULD include MOBILTY-ROAM attribute in all o= f its
> > STUN requests and STUN responses.  If the ICE peer also= includes
> > MOBILTY-ROAM attribute in all its STUN requests and STUN res= ponses
> > then it means both the endpoints are mobile and can roam at = the same
> > time between networks.  In order to support simultaneou= sly mobility
> > without breaking media sessions between them, both ICE agent= s MUST
> > perform the following steps :
> >
> > 1.  The ICE agent will keep the relayed candidates aliv= e using
> > Refresh transaction, as described in [RFC5766].
> >
> > 2.  When gaining an interface, the ICE agent will refre= sh it's
> > allocation with TURN server using Section 4.2.
> >
> > 3.  The ICE agent will perform the steps described in S= ection 3.1.
> >
> > 4.  If the ICE connectivity check succeeds only with lo= cal and
> > remote relayed candidates, it suggests that even the other p= eer is
> > roaming at the same time.  The ICE agent creates a new = pair using the
> > relayed candidates, adds the pair to the valid list and mark= s it as
> > selected.  The ICE agent can now send media using the n= ewly selected
> > relayed candidate pair.  The Mobile device in parallel = re-establishes
> > connection with SIP proxy, issues new offer/answer and resta= rts ICE.
> > Hence media will only be sent briefly on TURN relays.
> >>
> >> Besides, even in cases where ICE mobility succeeds, an I= CE restart
> >> could still allow the use of higher priority candidates.=
> >
> > ICE Mobility will pick the candidates on the new interface b= ased on
> > priority (RFC 3484 or latest RFC 6724). Is there any specifi= c case
> > you have in mind that ICE restart would pick higher priority=
> > candidates and not ICE Mobility other than Simultaneous Mobi= lity
> > problem ?
> >
> > --Tiru.
> >
> >>
> >> Wouldn't it make more sense to always perform an ICE res= tart in
> >> parallel and basically consider ICE mobility a best effo= rt attempt
> >> to shorten handover latency?
> >>
> >>>
> >>> --Tiru.
> >>>
> >>>> -----Original Message----- From: Emil Ivov
> >>>> [mailto:emcho= @jitsi.org] Sent: Thursday, September 13, 2012
> >>>> 2:59 PM To: Tirumaleswar Reddy (tireddy) Cc: mmu= sic@ietf.org
> >>>> Subject: Re: [MMUSIC] New Version Notification f= or
> >>>> draft-wing-mmusic-ice- mobility-01.txt
> >>>>
> >>>> Hey Tiru,
> >>>>
> >>>> One thing that I think this document is not very= clear about is
> >>>> its relationship to standard mobility handling (= i.e. through
> >>>> ICE restart).
> >>>>
> >>>> As far as I can see, ICE restart is only mention= ed when
> >>>> describing its inefficiency.
> >>>>
> >>>> You did confirm in Vancouver that ICE Mobility i= s only meant as
> >>>> an optimisation that would only take place until= the ICE
> >>>> restart completes but I don't see it anywhere in= the text. Or
> >>>> am I missing something?
> >>>>
> >>>> Cheers, Emil
> >>>>
> >>>> On 20.07.12, 13:36, Tirumaleswar Reddy (tireddy)= wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Dan, Prashanth and I have submitted a draft = that explains
> >>>>> how endpoint mobility can be achieved using = ICE.  Two
> >>>>> mechanisms are shown, one where both endpoin= ts support ICE
> >>>>> and another where only one endpoint supports= ICE. When only
> >>>>> one endpoint supports ICE, a TURN server pro= vides mobility.
> >>>>>
> >>>>> _http://www.ietf.org/internet-drafts/draft-w= ing-mmusic-ice-mobility-
> >>
> >>>>>
> 01.txt_
> >>>>>
> >>>>> Please let know your comments. If time permi= ts we'd present
> >>>>> the draft in Vancouver.
> >>>>>
> >>>>> Regards, Tiru.
> >>>>>
> >>>>>> -----Original Message----- From: Tirumal= eswar Reddy
> >>>>>> (tireddy) Sent: Friday, July 20, 2012 3:= 18 PM To:
> >>>>>> _mmusic@ietf.org_
> >> <mailto:mmusic@iet= f.org> Subject: FW: New
> >>>>>> Version Notification for draft-wing-mmus= ic-ice-
> >>>>>> mobility-01.txt
> >>>>>>
> >>>>>> -----Original Message----- From:
> >>>>>> _internet-drafts@ietf.org_
> >>> <mailto:[mailto:internet-drafts@ietf.org]> Sent: Tuesday, July
> >>> 17, 2012 3:52
> >>>>>> AM To: Dan Wing (dwing) Cc: Prashanth Pa= til (praspati);
> >>>>>> Tirumaleswar Reddy (tireddy) Subject: Ne= w Version
> >>>>>> Notification for draft-wing-mmusic-ice-m= obility- 01.txt
> >>>>>>
> >>>>>>
> >>>>>> A new version of I-D, draft-wing-mmusic-= ice-mobility-01.txt
> >>>>>> has been successfully submitted by Dan W= ing and posted to
> >>>>>> the IETF repository.
> >>>>>>
> >>>>>> Filename:   draft-wing-mmusic-= ice-mobility Revision:
> >>>>>> 01 Title: Mobility with ICE (MICE) Creat= ion date:
> >>>>>> 2012-07-16 WG ID: Individual Submission = Number of pages: 12
> >>>>>> URL:
> >>>>>> _http://www.ietf.org/internet-drafts/dra= ft-wing-mmusic-_
> >>>>>> ice-mobility-01.txt Status:
> >>>>>> _http://datatracker.ietf.org/doc/draft-w= ing-mmusic-ice-_
> >>>>>> mobility Htmlized:
> >>>>>> _http://tools.ietf.org/html/draft-wing-m= music-ice-_
> >>>>>> mobility-01 Diff:
> >>>>>> _http://tools.ietf.org/rfcdiff?url2=3Ddr= aft-wing-mmusic-_
> >>>>>> ice-mobility-01
> >>>>>>
> >>>>>> Abstract: This specification describes h= ow endpoint
> >>>>>> mobility can be achieved using ICE. = ; Two mechanisms are
> >>>>>> shown, one where both endpoints support = ICE and another
> >>>>>> where only one endpoint supports ICE.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> The IETF Secretariat
> >>>>> ____________________________________________= ___ mmusic
> >>>>> mailing list _mmusic@ietf.org_ <mailto:mmusic@ietf.org>
> >>> _https://www.ietf.org/mailman/listinfo/mmusic_
> >>>>>
> >
>
> --
> Emil Ivov, Ph.D.        &= nbsp;           &nbs= p;  67000 Strasbourg,
> Project Lead         = ;            &n= bsp;     France
> Jitsi
> emcho@jitsi.org        &n= bsp;            = ;   PHONE: +33.1.77.62.43.30
> https://jitsi.org  &n= bsp;            = ;       FAX:   +33.1.77.62.47.3= 1
 
 --_000_913383AAA69FF945B8F946018B75898A147AB976xmbrcdx10ciscoc_--