> -----Original Message-----
> Sent: Tuesday, September 18, 2012 3:12 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: mmusic <at> 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
> >> To: Tirumaleswar Reddy (tireddy) Cc: mmusic <at> 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 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-SUPPORT attribute.
[Even without ICE Mobility, if both Mobile devices are behind non-BEHAVE compliant NAT then ICE connectivity checks using host/server-reflexive candidates will fail and end up using UDP relay]
===
Section 3
Endpoints that support ICE Mobility perform ICE normally, and MUST also include the MOBILITY-SUPPORT attribute in all of their STUN requests and their STUN responses. The inclusion of this attribute allows the ICE peer to 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 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).
===
--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?
> >>
> >>>
> >>> --Tiru.
> >>>
> >>>> -----Original Message----- From: Emil Ivov
> >>>> 2:59 PM To: Tirumaleswar Reddy (tireddy) Cc: mmusic <at> 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 <at> ietf.org_
> >>>>>> Version Notification for draft-wing-mmusic-ice-
> >>>>>> mobility-01.txt
> >>>>>>
> >>>>>> -----Original Message----- From:
> >>>>>> _internet-drafts <at> ietf.org_
> >>> 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=draft-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
> >>> _https://www.ietf.org/mailman/listinfo/mmusic_
> >>>>>
> >
>
> --
> Emil Ivov, Ph.D. 67000 Strasbourg,
> Project Lead France
> Jitsi
> emcho <at> jitsi.org PHONE: +33.1.77.62.43.30
RSS Feed