Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Thu, 5 Oct 2000 08:29:27 -0400

Hi, Arnoud:

Yes, you are right that if the lower makes the changes transparent to the
upper lower layer, the upper layer will not do anything. This is a kind of
implementation issues and people may choose to use those kinds of solutions
if they like. But it should not be mandatory for everyone. 

(A whole industry is working for the mobility-aware middleware because the
services provided by the lower is not sufficient. The classical thinking is
going away and new services are emerging because of the new areas that are
being opening up with the intelligence moving in the upper layer.)

The fact of the matter still remains true that the address information in
the register needs to be updated and one may still like to use the re-INVITE
messages to the new addresses. If this solution is acceptable to anyone, let
us allow them to use it.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Arnoud van Wijk (ELN) [mailto:[email-masked]]
Sent: Thursday, October 05, 2000 5:40 AM
To: 'hammer michael'; Brian Stucker; Rohan Mahy; Roy, Radhika R, ALCOO
Cc: [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

It is indeed a good idea to look at the problem.
First is the question of "what" we are talking about.
And if the problem is indeed happening.
 
When logged in via a mobile terminal on an IP network, the outside world
should always see the same IP address for the mobile terminal. For the user
it can be a mobile IP or an IP address asigned when the mobile terminal
logged on.
If the endpoint changes, the mobile network will change the routing and
whatever that is needed for the handover. The user should still remain an IP
address that does not change. So SIP should still see the same end point.
And for SIP there are no changes at all.
 
So, a requirement for the SIP proxy of the IP-operator should then be that
the server has to be able to change the IP-address to the IP-address that
the outside world sees the mobile terminal using. (if the IP-address changes
during hand-over).
 
I do not know everything about mobile internet. I am also not sure what the
current solutions are. I could look it up etc, but I have more things to do.
Is this not similar to the SIP-NAT problem, where the internal part of a
network has different IP-addresses then the outside part?
 
Maybe I am overlooking a lot of issues.
 
Just my 2 cents.
 
Arnoud van Wijk

-----Original Message-----
From: hammer michael [mailto:[email-masked]]
Sent: donderdag 5 okt 2000 3:48
To: Brian Stucker; Rohan Mahy; Roy, Radhika R, ALCOO
Cc: [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )

All,

For the record, I agree with the idea that the lower layers should handle
mobility.  However, one possibility exists that could take the control out
of the hands of the lower layer.  I'm not sure if this is the issue we are
circling, but let me try to describe what I think could happen.

The IP layer can address what happens to the communication end-to-end so
long as it is really end-to-end.  If a proxy is used to patch together two
end-to-end IP streams, then any IP-dependent mechanism would be constrained
by its knowledge of what the endpoint is.

If only one end-to-end stream is used, then the IP layer should be able to
maintain flows to that endpoint even as it moves within a network domain.
If movement causes the terminal to relinquish an IP address and get a new
one in a new network, registrations at the network layer can reestablish IP
identities among communicating parties.  Also, that same registration
mechanism is how a user or proxy finds the other user to begin with.  If a
message is not acknowledged, then another location request is needed.

However, if the real end-point is hidden behind a proxy using another IP
stream, then the proxy is burdened with the responsibility to keep track of
the end-points on the two streams.  But this would be just two instances of
the simple example.

So, the problem seems to come down to whether the information on the
whereabouts of a user is present or can be obtained by some mechanism on a
timely basis should an acknowledgement not be received.  I had the
impression that this was not a problem.

Is it the responsibility of the user to push that information to the proxy,
or is it the proxy's responsibility to pull that information from the
registrar?  Either way, that should not be a problem in the time-scale of a
session set-up or release.

In a world where the terminal is "always on", the role of SIP may be more
attuned to whether the user wants to be reached, not where or how to reach
the user.  But that digresses into another subject.

Mike Hammer

At 04:23 PM 10/04/2000 -0500, Brian Stucker wrote:

I definitely agree with that sentiment. That was the point of my argument.
Do nothing in regards to SIP, and if there's something particular to SIP
that needs to be addressed in a layer below SIP, then we should be trying to
inject requirements and influence the decisions being made there first.

Brian 

-----Original Message----- 
From: Rohan Mahy [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, October 04, 2000 3:14 PM 
To: Roy, Radhika R, ALCOO 
Cc: Stucker, Brian [RICH2:WI12:EXCH]; [email-masked] 
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP 
Mobility ) 

At 10:51 AM 9/29/00 , Roy, Radhika R, ALCOO wrote: 
>Hi, Brian: 
> 
>I guess that your mail has provided some technical inputs: 1. Inter-session

>mobility and 2. Intra-session mobility. 
> 
>For inter-session mobility, you think that SIP in OK. 
> 
>For intra-session mobility, it appears that you are feeling comfortable, as

>if, SIP is not designed to do this. 
> 
>Let us go to the basic: SIP is a session initiation protocol. It is the 
>mandate of SIP. So, we like to see that it MUST deal with mobility as well 

*NO* !!  Part of SIPs mandate is *personal* mobility, as a user moves from 
device to device.  Personal mobility is a good, useful thing.  However, The 
SIP charter does *NOT* include solving the problem of a device moving 
through different layer 2 networks.  This is a problem for a layer 3 
protocol to solve generically.  If Mobile IP doesn't do what we need it to, 
then lets extend it, fix it, or replace it. 

thanks, 
-rohan 

>because people will use it in mobile environment (for both intra- and 
>inter-session). 

> 
>For inter-session, I guess that there may be some involvement of REGISTER 
>and re-INVITE messages (because of change in location). 
> 
>That's all! 
> 
>All works are done in the lower layer and SIP is not involved (for example,

>some one in the lower layer will find that the location has been changed, 
>accordingly the upper layer may take some actions, if needed). 
> 
>Hope this will clarify the things. 
> 
>Best regards, 
>Radhika R. Roy 
>AT&T 
> 
>-----Original Message----- 
>From: Brian Stucker [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>Sent: Friday, September 29, 2000 1:19 PM 
>To: [email-masked] 
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility
) 
> 
> 
> 
>My intent isn't to confuse anyone. Quite the contrary. 
> 
>My point is that SIP, as an application, should not be concerned about the 
>vagaries of the underlying media it's being carried on. All applications 
>that use IP as a transport are going to have to contend with mobility in
the 
>IP space on the intra-session timescale. So IP should solve the problem 
>because it's a general problem for IP. 
> 
>SIP does enough to handle inter-session mobility (I'm at my desk, I'm at 
>home), and not impede intra-session mobility. It's just simply not suited 
>for handling anything else because of the nature of the protocol. Any 
>intra-session mobility must be handled out-of-band as far as SIP is 
>concerned, and SIP must not make any requirements that would impede this. 
> 
>Again, to use wireless voice calls as an example, even with dedicated 
>transport links, thousands of pages of standards with CDMA/TDMA, IS-41,
SS7, 
>and TCAP, a mobile switching center doesn't attempt to do what you guys are

>talking about. It doesn't update the location of a mobile once it's handed 
>over to another switch in the location database until after your call has 
>completed, and the mobile registers on the system it moved into. Why? 
>Because the mobile could be handed back over to the first system, the 
>handoff could fail, etc. So they don't even attempt to keep the exact 
>location of the mobile up to date outside of the original switch until the 
>mobile is stable again, when the call ends. Instead, all incoming calls go 
>to the first switch, and that switch knows where to go from there to get
the 
>call completed. 
> 
>SIP shouldn't be updating the location database every time a wireless 
>terminal moves around. Some sort of mobile IP proxy function, should
instead 
>be used that knows how to currently find the terminal in it's mobile-aware 
>IP space. It should route based on the inbound packet's IP address only,
and 
>not care what the payload data is either. 
> 
>That solves the problem for SIP, HTTP, FTP, POP3, RTP, you name it. Why 
>write an extension to every protocol that uses IP as a transport (and have 
>it solved, and debugged a million different ways) instead of just fixing
the 
>problem at the IP layer (and have it solved, and debugged one way)? 
> 
>Brian Stucker 
>Nortel Networks 
> 
>-----Original Message----- 
>From: Roy, Radhika R, ALCOO [ mailto:[email-masked] <mailto:[email-masked]>
< mailto:[email-masked] <mailto:[email-masked]> > ] 
>Sent: Friday, September 29, 2000 11:39 AM 
>To: hammer michael; Michael Thomas; Henry Sinnreich 
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; [email-masked] 
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP 
>Mobility ) 
> 
> 
>Hi, Everyone: 
> 
>The need for addressing mobility is clear and SIP is only one part of the 
>whole equation. 
> 
>Let us not confuse people in the name of Pandora's box or otherwise. 
> 
>We have to meet the needs solving problems (not to show our back). 
> 
>For the SIP WG, it is the SIP session layer that needs to be addressed, if 
>it turns out that is a need to do some works. 
> 
>Best regards, 
>Radhika R. Roy 
>AT&T 
> 
>-----Original Message----- 
>From: hammer michael [ mailto:[email-masked] <mailto:[email-masked]>
< mailto:[email-masked] <mailto:[email-masked]> > ] 
> 
>Sent: Friday, September 29, 2000 1:57 PM 
>To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich 
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; [email-masked] 
>Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP 
>Mobility ) 
> 
> 
>I think Brian aptly pointed out the Pandora's box you open with "mobility."

>That should be sufficient motivation to avoid that type of mobility in SIP.

> 
>We are talking about different timescales, e.g.:  per packet, per call, and

>per registration. 
> 
>I thought your term "discrete" captured the idea that the type of 
>"mobility" you refer to is of the:  call me at the office, then later, call

>me at home, I'm here now "mobility."  Because mobility conjures up so many 
>more issues, I like the word "presence" better.  Presence management may be

>more descriptive that mobility management. 
> 
>Mike 
> 
> 
>At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: 
> >Hi, Mike: 
> > 
> >Yes, we will have problems if we do not define the terms accurately. 
> > 
> >Let us assume that we are using SIP (RFC 2543) and its session layer as
our 
> 
> >reference. Location, registration, and session are defined in SIP. 
> > 
> >Paging (and probably "path") has not been defined in SIP. I will not
argue 
> >to take this abstraction in the SIP layer for now. 
> > 
> >Point of attachment has been used as a generic term to indicate "address
of 
> 
> >the attachment." If we translate this abstraction in the SIP layer, it
will 
> 
> >mean the addresses that are being used in the SIP layer (e.g., E.164, IP 
> >address, etc.). 
> > 
> >Now let us examine your points: Presence of a person or terminal, etc. 
> > 
> >In the SIP layer, I guess, that the presence of a person on a terminal 
>needs 
> >to be abstracted in terms of an "address." If that address is also
related 
> >to the point of attachment, then it will also be related to mobility. 
> > 
> >(A person behind the terminal may have another ID to deal with personal 
> >mobility. Let us not address that personal mobility for now.) 
> > 
> >In this way, we can extend our analysis for each layer. 
> > 
> >Does this answer your question? 
> > 
> >Best regards, 
> >Radhika R. Roy 
> >AT&T 
> > 
> >-----Original Message----- 
> >From: hammer michael [ mailto:[email-masked]
<mailto:[email-masked]>  < mailto:[email-masked]
<mailto:[email-masked]> > 
>] 
> >Sent: Thursday, September 28, 2000 6:29 PM 
> >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich 
> >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; [email-masked] 
> >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP 
> >Mobility ) 
> > 
> > 
> >Roy, 
> > 
> >I need to be very careful what word I choose.  Session connection rather 
> >than path might have been more appropriate.  I believe confusion can
occur 
> >if the type of location, registration, location, paging, etc. is not 
> >accurately defined.  I think that the intent of such services revolves 
> >about maintaining relationships between certain elements, such as
between: 
> > 
> >user/application and terminal, 
> >terminal and network end-point, 
> >network end-point and link end-point, etc. 
> > 
> >The act of "registering" may mean different things at different layers
and 
> >use different mechanisms to accomplish them.  The question for me is 
> >whether these are handled independently or does one mechanism attempt to 
> >manage multiple associations or would one type of registration trigger 
> >another type at a different layer? 
> > 
> >Would SIP then manage the "presence" of a person on a terminal, where 
> >something else manages the "presence" of a terminal on the network? 
> > 
> >Mike Hammer 
> > 
> > 
> >At 12:28 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: 
> > >Hi, Mike: 
> > > 
> > >You have made excellent points. In fact, you are in the heart of this 
> > >problem: How the communications path(s) needs to be established as the 
> >point 
> > >of attachment is changed during the contiguous mobility. 
> > > 
> > >I personally believe that SIP does not need to be involved to set up
the 
> > >communications path(s) per se. 
> > > 
> > >However, SIP needs to be used to set up the session: re-INVITE (to the 
>new 
> > >address) may need to be used. 
> > > 
> > >In the process, location updates, paging, etc. are also involved. If
the 
> > >location update does not have any impact in the SIP layer, I do not
think 
> 
> > >that SIP should be aware of any change in the lower layer. For example,

> > >mobile IP has the power of providing location transparency of the IP 
>layer 
> > >(although it has some problems to meet the performance requirements for

>the 
> > >real-time communications like voice). 
> > > 
> > >In addition to IP addresses, there are also transport addresses (e.g., 
>UDP, 
> > >TCP) for media. One also needs to be careful how to deal with the TCP 
> > >connection. IP addresses change, but the TCP connections still remains 
>the 
> > >same. An update mechanism needs to be defined. In turn, does it mean
that 
> 
> > >this updated information may also be propagated to the SIP layer (other

> > >members may also provide comments on this) because SIP does have the 
> > >abstraction of the transport address? 
> > > 
> > >I have not yet talked about the link layer. 
> > > 
> > >I am not trying to solve the mobility problem here. 
> > > 
> > >All I am trying to show: If we try to analyze the situation doing an 
> > >end-to-end analysis, we can easily see what needs to be done in each 
>layer. 
> > >Finally, we can answer the question: Whether or not any new work is 
>needed 
> > >in the SIP layer to address both discrete and continuos mobility. 
> > > 
> > >But you are right that we MUST keep the involvement of the SIP layer to
a 
> 
> > >minimal level (if possible, we should avoid it) to address the mobility

> > >problem. 
> > > 
> > >Best regards, 
> > >Radhika R. Roy 
> > >AT&T 
> > > 
> > >-----Original Message----- 
> > >From: hammer michael [ mailto:[email-masked]
<mailto:[email-masked]>  
>< mailto:[email-masked] <mailto:[email-masked]> > ] 
> > >Sent: Thursday, September 28, 2000 2:41 PM 
> > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich 
> > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; [email-masked] 
> > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP 
> > >Mobility ) 
> > > 
> > > 
> > >Roy, 
> > > 
> > >Your use of the terms "discrete" and "continuous" strike to the heart
of 
> > >the issue.  In traditional mobile networks, there is an attempt to move

>the 
> > >stream of media with the terminal as it crosses cell boundaries 
> > >(continuous).  There are many papers related to voice and mobile-IP
that 
> > >address how to move the communications path. 
> > > 
> > >The discrete case is more an issue of identification of the presence
and 
> > >availability of recipients and the establishment of communications to 
> > >them.  Because names and addresses denoting physical location are often

> > >blurred, in essence, personal mobility involves the creation and
deletion 
> 
> > >of recipients rather than their movement. 
> > > 
> > >As I understand it, SIP does not move existing communications so much
as 
>it 
> > >destroys existing communications paths and replaces them with new ones.

>In 
> > >that respect, some of the traditional mobility issues such as handover 
>are 
> > >avoided, but others, e.g. location updates and paging are still needed.

> > > 
> > >While the telcos reverted to addressing hardware-oriented terminal 
>mobility 
> > >in PCS, the softer personal mobility is still open to definition.  The 
>same 
> > >issues have appeared in the net world and each will need to be solved
in 
> > >their respective layers. 
> > > 
> > >Mike 
> > > 
> > > 
> > >At 11:01 AM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote: 
> > > >Hi, Mike: 
> > > > 
> > > >In fact, this is the precisely the test why SIP should be involved or

>to 
> >be 
> > > >enhanced to support mobility (discrete + continuos) in the case of 
>Voice, 
> > > >chat, IM, messaging, conferencing, games, and others. 
> > > > 
> > > >If it is found that SIP does not need to be involved, I do not think 
>that 
> > > >anyone will force it to do this. 
> > > > 
> > > >By the way, do you not see that how SIP (RFC 2543) has taken care of 
>many 
> > > >aspects of users' discrete mobility? Has it not been be an excellent 
>way 
> >of 
> > > >involving SIP to solve a kind of mobility in the first place (what 
>other 
> > > >applications like H.323 is yet to support)? 
> > > > 
> > > >Along the same line, if people come up with the ideas that it is
better 
> 
> >to 
> > > >enhance SIP functionality to support other aspects of mobility (if 
> > > >alternative solutions are not there or not acceptable), I do not
think 
> >that 
> > > >we should have any objections. 
> > > > 
> > > >Let us keep our mind open and judge each proposal with its own
merits. 
> > > > 
> > > >Best regards, 
> > > >Radhika R. Roy 
> > > >AT&T 
> > > > 
> > > >-----Original Message----- 
> > > >From: Michael Thomas [ mailto:[email-masked] <mailto:[email-masked]>  <
mailto:[email-masked] <mailto:[email-masked]> > ] 
> > > >Sent: Wednesday, September 27, 2000 7:01 PM 
> > > >To: Henry Sinnreich 
> > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387;
'Henning 
> > > >Schulzrinne'; [email-masked] 
> > > >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP 
> > > >Mobility ) 
> > > > 
> > > > 
> > > >Henry Sinnreich writes: 
> > > >  > >what seems clear is that there are a 
> > > >  > >number of applications which won't be able to do 
> > > >  > >that for a variety of reasons. 
> > > >  > 
> > > >  > Voice, chat, IM, messaging, conferencing, games, etc., are 
> > > >  > plenty of reasons to justify the SIP approach to mobility. 
> > > > 
> > > >    But what if you could do all of the same things 
> > > >    and not need to modify or involve SIP and have the 
> > > >    additional gain that things like http worked as well? 
> > > > 
> > > >                    Mike 
> > > > 
> > > >  > 
> > > >  > Henry 
> > > >  > 
> > > >  > >-----Original Message----- 
> > > >  > >From: [email-masked] 
> > > >  > >[ mailto:[email-masked]
<mailto:[email-masked]>  
>< mailto:[email-masked]
<mailto:[email-masked]> > ]On Behalf Of 
> > > >  > >Michael Thomas 
> > > >  > >Sent: Wednesday, September 27, 2000 8:33 PM 
> > > >  > >To: Roy, Radhika R, ALCOO 
> > > >  > >Cc: Michael Thomas; Lewis Karl-QA3387; 'Henning Schulzrinne'; 
> > > >  > >[email-masked] 
> > > >  > >Subject: RE: [SIP] Attempt at summarizing current SIP 
> > > >  > >drafts (SIP 
> > > >  > >Mobility ) 
> > > >  > > 
> > > >  > > 
> > > >  > > 
> > > >  > >I guess what I'm having a hard time with is the 
> > > >  > >starting point that assumes that SIP based 
> > > >  > >application mobility is Good Thing. While it's 
> > > >  > >clear that many applications *could* design in 
> > > >  > >mobility, what seems clear is that there are a 
> > > >  > >number of applications which won't be able to do 
> > > >  > >that for a variety of reasons. Assuming that those 
> > > >  > >applications are important too, then we're already 
> > > >  > >stuck with needing to solve for the general 
> > > >  > >problem. 
> > > >  > > 
> > > >  > >Starting out with the assumption that Mobile IP 
> > > >  > >addresses the more general problem seems 
> > > >  > >attractive because a good solution with fast 
> > > >  > >handoff that addresses AAA and QoS would solve 
> > > >  > >most of the application layer problems in a 
> > > >  > >general way rather than just a SIP specific 
> > > >  > >way. 
> > > >  > > 
> > > >  > >There also seems to be an implicit assumption in 
> > > >  > >the draft of linkage of SIP to a AAA function. 
> > > >  > >I'm going to guess that it is along the same line 
> > > >  > >of thinking of the DQoS gate controller idea. The 
> > > >  > >problem I have with that is that it is in the end 
> > > >  > >an optimization on the normal RSVP/COPS pull 
> > > >  > >model. However, things that don't fit into that 
> > > >  > >model still have the non-optimized way of doing 
> > > >  > >QoS authorization. That's probably not the fault 
> > > >  > >of this draft, but it does seem to make the entire 
> > > >  > >draft a cart-before-horse situation. 
> > > >  > > 
> > > >  > >    Mike 
> > > >  > > 
> > > >  > >Roy, Radhika R, ALCOO writes: 
> > > >  > > > Hi, Mike: 
> > > >  > > > 
> > > >  > > > I guess that SIP, as you rightly pointed out, is 
> > > >  > >dealing with the signaling 
> > > >  > > > mechanism in the application layer. So, SIP does 
> > > >  > >not need to deal with L3 
> > > >  > > > media path. 
> > > >  > > > 
> > > >  > > > SIP does deal with addresses of the source and 
> > > >  > >destination(s). 
> > > >  > > > 
> > > >  > > > In mobile environment, the point of attachment 
> > > >  > >(i.e., addresses) changes: 1. 
> > > >  > > > Between the sessions (discrete mobility) and 2. 
> > > >  > >During the session 
> > > >  > > > (continuous mobility). 
> > > >  > > > 
> > > >  > > > The problem that is being addressed is: What is the 
> > > >  > >impact in SIP layer due 
> > > >  > > > to these two kinds of mobility. 
> > > >  > > > 
> > > >  > > > I guess that for discrete mobility, SIP has 
> > > >  > >probably addressed most of the 
> > > >  > > > problems (others may also provide comments on this). 
> > > >  > > > 
> > > >  > > > For continuous mobility, there may need (or may 
> > > >  > >not??) some works in the SIP 
> > > >  > > > layer, if any (others may also provide comments). 
> > > >  > > > 
> > > >  > > > However, SIP can only address the mobility related 
> > > >  > >problems in the 
> > > >  > > > application layer. This alone may not be enough to 
> > > >  > >solve all problems 
> > > >  > > > because some L3 and L2 problems may also need to be 
> > > >  > >addressed at the same 
> > > >  > > > time to have the complete solution. 
> > > >  > > > 
> > > >  > > > In any solution, SIP mobility needs to be limited 
> > > >  > >only to the application 
> > > >  > > > layer (not L3, L2, etc.). 
> > > >  > > > 
> > > >  > > > Best regards, 
> > > >  > > > Radhika R. Roy 
> > > >  > > > AT&T 
> > > >  > > > 
> > > >  > > > -----Original Message----- 
> > > >  > > > From: Michael Thomas [ mailto:[email-masked]
<mailto:[email-masked]>  
>< mailto:[email-masked] <mailto:[email-masked]> > ] 
> > > >  > > > Sent: Wednesday, September 27, 2000 12:32 PM 
> > > >  > > > To: Lewis Karl-QA3387 
> > > >  > > > Cc: 'Henning Schulzrinne'; [email-masked] 
> > > >  > > > Subject: RE: [SIP] Attempt at summarizing current SIP drafts 
> > > >  > > > 
> > > >  > > > 
> > > >  > > > 
> > > >  > > > While I'm more than willing to believe that there 
> > > >  > > > are mobility issues that SIP needs to deal with, 
> > > >  > > > this paper seems to be positing SIP as the means 
> > > >  > > > of initiating data sessions altogether. To my 
> > > >  > > > mind, that's a rather bellheaded way of thinking 
> > > >  > > > about how you do what amounts to L3 admission 
> > > >  > > > control. In fact, the IETF already has an L3 
> > > >  > > > admission control mechanism: RSVP. RSVP's main 
> > > >  > > > advantage is that it follows actual network 
> > > >  > > > topology. SIP is at a distinct disadvantage since 
> > > >  > > > all it knows about is the signaling path which 
> > > >  > > > in normal circumstances has nothing to do with 
> > > >  > > > the actual data path. 
> > > >  > > > 
> > > >  > > > Maybe I'm misreading this whole paper, but it sure 
> > > >  > > > looks like it to me. If my interpretation is 
> > > >  > > > right, however, I'd like to know if the intention 
> > > >  > > > is to signal the access routers providing the 
> > > >  > > > L2/L3 bits using SIP instead of, say, COPS (or 
> > > >  > > > DIAMETER). If so, I'd say that SIP truly has 
> > > >  > > > arrived at becoming the new millenium's kitchen 
> > > >  > > > sink if this is accepted. 
> > > >  > > > 
> > > >  > > >    Mike 
> > > >  > > > 
> > > >  > > > Lewis Karl-QA3387 writes: 
> > > >  > > >  > I have just reviewed the Mobility Related drafts 
> > > >  > >and am wondering if 
> > > >  > > > anyone 
> > > >  > > >  > is aware of the current status of 
> > > >  > >draft-itsumo-sip -mobility-req-01. In 
> > > >  > > >  > particular, several issues were identified such 
> > > >  > >as Mobile IP not being 
> > > >  > > >  > sufficient for personal mobility and location 
> > > >  > >services, completing 
> > > >  > > >  > registration in less than a few seconds, 
> > > >  > >reconfiguration in milliseconds, 
> > > >  > > >  > providing location services, support of inter 
> > > >  > >domain soft-hand and secure 
> > > >  > > >  > signaling. Have these issues been addressed or 
> > > >  > >actively being worked? 
> > > >  > > >  > 
> > > >  > > >  > Karl 
> > > >  > > >  > 
> > > >  > > >  > 
> > > >  > > >  > 
> > > >  > > >  > -----Original Message----- 
> > > >  > > >  > From: Henning Schulzrinne 
> > > >  > [ mailto:[email-masked]
<mailto:[email-masked]>  
>< mailto:[email-masked] <mailto:[email-masked]> >
] 
> > > >  >  >  > Sent: Monday, September 25, 2000 9:20 AM 
> > > >  >  >  > To: [email-masked] 
> > > >  >  >  > Subject: [SIP] Attempt at summarizing current SIP drafts 
> > > >  >  >  > 
> > > >  >  >  > 
> > > >  >  >  > Given the proliferation of SIP-related drafts, I've 
> > > >  > created a summary of 
> > > >  >  >  > efforts at 
> > > >  > http://www.cs.columbia.edu/~hgs/sip/drafts.html
<http://www.cs.columbia.edu/~hgs/sip/drafts.html>  
>< http://www.cs.columbia.edu/~hgs/sip/drafts.html
<http://www.cs.columbia.edu/~hgs/sip/drafts.html> > . This is 
> > > >  >  >  > known to be incomplete, so I'd appreciate if you could 
> > > >  > send me any 
> > > >  >  >  > additions or corrections. (Jonathan Rosenberg provided 
> > > >  > some of the text; 
> > > >  >  >  > any mistakes or misrepresentations are mine.) 
> > > >  >  >  > 
> > > >  >  >  > It is fairly clear that there are a large number of drafts 
> > > >  > that have not 
> > > >  >  >  > changed materially for half a year or more. Maybe it's 
> > > >  > time to have a WG 
> > > >  >  >  > last call or two or ten... 
> > > >  >  >  > 
> > > >  >  >  > Henning 
> > > >  >  >  > -- 
> > > >  >  >  > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
<http://www.cs.columbia.edu/~hgs>  
>< http://www.cs.columbia.edu/~hgs <http://www.cs.columbia.edu/~hgs> > 
> > > >  >  >  > 
> > > >  >  >  > 
> > > >  >  >  > _______________________________________________ 
> > > >  >  >  > SIP mailing list 
> > > >  >  >  > [email-masked] 
> > > >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
>< http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> > 
> > > >  >  >  > 
> > > >  >  >  > _______________________________________________ 
> > > >  >  >  > SIP mailing list 
> > > >  >  >  > [email-masked] 
> > > >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
>< http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> > 
> > > >  >  >  > 
> > > >  >  > 
> > > >  >  > _______________________________________________ 
> > > >  >  > SIP mailing list 
> > > >  >  > [email-masked] 
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
>< http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> > 
> > > >  >  > 
> > > >  >  > _______________________________________________ 
> > > >  >  > SIP mailing list 
> > > >  >  > [email-masked] 
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
>< http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> > 
> > > >  >  > 
> > > >  > 
> > > >  > _______________________________________________ 
> > > >  > SIP mailing list 
> > > >  > [email-masked] 
> > > >  > http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
>< http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> > 
> > > >  > 
> > > >  > 
> > > > 
> > > >_______________________________________________ 
> > > >SIP mailing list 
> > > >[email-masked] 
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
>< http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> > 
> > > > 
> > > >_______________________________________________ 
> > > >SIP mailing list 
> > > >[email-masked] 
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
>< http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> > 
> 
> 
>_______________________________________________ 
>SIP mailing list 
>[email-masked] 
> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
>< http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> > 
> 
> 
>_______________________________________________ 
>SIP mailing list 
>[email-masked] 
> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Billy Biggs <[email-masked]>
Date: Thu, 5 Oct 2000 09:36:30 -0500

Hi Radhika,

> The fact of the matter still remains true that the address information
> in the register needs to be updated and one may still like to use the
> re-INVITE messages to the new addresses. If this solution is
> acceptable to anyone, let us allow them to use it.

  I'm still confused about what you are asking.  I don't think anyone is
disallowing you to use this mechanism.

  Are you asking:

  1. What extensions to the SIP REGISTER and INVITE transactions are
     required to support active session mobility?

     The consensus on this list seems to be that no extensions are
     required.  Please correct me if I am wrong.  We've already
     established that the Contact address can be updated in a re-INVITE,
     and I believe this is in the bis.

     If you deployed a system which used this form of mobility, I
     believe you would have no problems interoperating with others.

  2. What technical problems are there with this solution?

     Many people have mentioned hand-off time as being a factor, I'd
     estimate having an upper-bound for a successful change to be about
     half a minute.  Another problem would be handling un-succcessful
     hand-offs: what if the other end does not accept the INVITE?  The
     call would likely be disconnected if the mobile user cannot remain
     at the old address.

  3. What extensions can we propose to solve these problems?

     Building a mobile-IP phone that updates the session only as an
     optimization might be worth pursuing.  However, I still don't see
     any work which may lead to extensions to SIP.  I think we have
     everything we need.

  4. What is the specific call-flow for a SIP session hand-off?

     If you're asking "how do I do it", I believe this has come up
     before on the list, and I would recommend searching the archives.
     Regardless, this is simply an afternoon research project.

  5. Is it a good idea?

     This is what I believe most people have been answering.  As I've
     mentioned before, I don't think it's a good idea.  However, that
     shouldn't stop you from researching it.

-- 
Billy Biggs                    [email-masked]
http://www.div8.net/billy/           [email-masked]