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

From: Rohan Mahy <[email-masked]>
Date: Wed, 04 Oct 2000 13:13:52 -0700

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]]
>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]> ]
>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]> ]
>
>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]>
>]
> >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]> ]
> > >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]> ]
> > > >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]> ]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]> ]
> > > >  > > > 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]> ]
> > > >  >  >  > 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> . 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>
> > > >  >  >  >
> > > >  >  >  >
> > > >  >  >  > _______________________________________________
> > > >  >  >  > 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
><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
><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
><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
><http://lists.bell-labs.com/mailman/listinfo/sip>
>
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip

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

---

From: Lewis Karl-QA3387 <[email-masked]>
Date: Wed, 4 Oct 2000 15:56:36 -0500

MobileIP is addressing this issue with drafts such as
draft-elmalki-mobileip-fast-handoffs-03.txt and
draft-soliman-mobileip-hmipv6-01.txt.

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

Hi, Rohan:

Again, let us go back to the basic:

SIP is a session initiation protocol. What needs to be done, if any, in the
SIP layer if the point of attachment is changed during the session.

Best regards,
Radhika R. Roy
AT&T

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

thanks,
-rohan

]
> >From: hammer michael [ mailto:[email-masked]
<mailto:[email-masked]>

---

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Wed, 4 Oct 2000 16:59:15 -0400

Hi, Bobby:

I doubt it because SIP has an abstraction of addresses (i.e., point of
attachments). The messages may go to the wrong places unless it is fixed.

So, re-REGISTER and re-INVITE have been suggested (some I-Ds are there).

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Bobby Sardana [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:45 PM
To: Roy, Radhika R, ALCOO
Cc: Rohan Mahy; Brian Stucker; [email-masked]
Subject: Re: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility)

Hello Radhika:

> SIP layer if the point of attachment is changed during the session.

IMHO, nothing should be done. Application layer protocols should be
transparent
to IP mobility changes which is a layer 3 problem.

Regards,

[email-masked]

> >Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility
> )
> > >Point of attachment has been used as a generic term to indicate
"address
> > > >But you are right that we MUST keep the involvement of the SIP layer
to
> a
drafts

---

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Wed, 4 Oct 2000 17:03:27 -0400

I guess that it is needed in L3.
I-Ds show that still there may be a need for re-REGISTER and re-INVITE
messages in the SIP layer.

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:57 PM
To: [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

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

Hi, Rohan:

Best regards,
Radhika R. Roy
AT&T

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

thanks,
-rohan

]

---

From: Lewis Karl-QA3387 <[email-masked]>
Date: Wed, 4 Oct 2000 16:07:35 -0500

I don't understand why you need to involve SIP if L3 is addressing this
issue. For instance, packets can still be routed to the new destination when
the point of attachment changes.

-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:03 PM
To: Lewis Karl-QA3387; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:57 PM
To: [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

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

Hi, Rohan:

Best regards,
Radhika R. Roy
AT&T

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

thanks,
-rohan

]

---

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Wed, 4 Oct 2000 17:19:41 -0400

May be several reasons:
Register may need to be have the current updated information.
Session may need to be established to the right addresses optimizing
resources.

(Point of attachment may have the abstraction from L1 through L7)

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 5:08 PM
To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:03 PM
To: Lewis Karl-QA3387; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:57 PM
To: [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

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

Hi, Rohan:

Best regards,
Radhika R. Roy
AT&T

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

thanks,
-rohan

]

---

From: Lewis Karl-QA3387 <[email-masked]>
Date: Wed, 4 Oct 2000 16:22:39 -0500

Are you saying that every time the point of attachment changes a reregister
is needed?

-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:20 PM
To: Lewis Karl-QA3387; Lewis Karl-QA3387; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

May be several reasons:

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 5:08 PM
To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:03 PM
To: Lewis Karl-QA3387; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:57 PM
To: [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

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

Hi, Rohan:

Best regards,
Radhika R. Roy
AT&T

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

thanks,
-rohan

]

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 4 Oct 2000 16:23:35 -0500

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]]
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 )

thanks,
-rohan

]

---

From: hammer michael <[email-masked]>
Date: Wed, 04 Oct 2000 18:48:25 -0700

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:

>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
>
>From: Rohan Mahy [<mailto:[email-masked]>mailto:[email-masked]]
> >From: Brian Stucker 
> [<mailto:[email-masked]>mailto:[email-masked]]
> >From: Roy, Radhika R, ALCOO [ <mailto:[email-masked]>mailto:[email-masked] 
> <mailto:[email-masked]> ]
> >From: hammer michael [ 
> <mailto:[email-masked]>mailto:[email-masked] 
> "address of
> > >From: hammer michael [ 
> <mailto:[email-masked]>mailto:[email-masked] <mailto:[email-masked]>
> >]
> to a
> > > >From: hammer michael [ 
> <mailto:[email-masked]>mailto:[email-masked]
> > > > >From: Michael Thomas [ <mailto:[email-masked]>mailto:[email-masked] 
> <mailto:[email-masked]> ]
> > > > >  > >[ 
> <mailto:[email-masked]>mailto:[email-masked]
> > > > >  > > > From: Michael Thomas [ 
> <mailto:[email-masked]>mailto:[email-masked]
> ><mailto:[email-masked]> ]
> > > > >  > [ 
> <mailto:[email-masked]>mailto:[email-masked]
> <http://www.cs.columbia.edu/~hgs/sip/drafts.html>http://www.cs.columbia.edu/~hgs/sip/drafts.html 
>
> Schulzrinne   <http://www.cs.columbia.edu/~hgs>http://www.cs.columbia.edu/~hgs
> <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 
>
> <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 
>
> <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 
>
> <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.c 
> om/mailman/listinfo/sip
> ><http://lists.bell-labs.com/mailman/listinfo/sip>http://lists.bell-labs.c 
> om/mailman/listinfo/sip

---

From: "Arnoud van Wijk (ELN)" <[email-masked]>
Date: Thu, 5 Oct 2000 11:40:00 +0200

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

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 ) 

thanks, 
-rohan 

>From: Brian Stucker [ mailto:[email-masked] <mailto:[email-masked]> ] 
>From: Roy, Radhika R, ALCOO [ mailto:[email-masked] <mailto:[email-masked]>  < mailto:[email-masked] <mailto:[email-masked]> > ] 
>From: hammer michael [ mailto:[email-masked] <mailto:[email-masked]>  < mailto:[email-masked] <mailto:[email-masked]> > ] 
> 
> >From: hammer michael [ mailto:[email-masked] <mailto:[email-masked]>  < mailto:[email-masked] <mailto:[email-masked]> > 
>] 
>< mailto:[email-masked] <mailto:[email-masked]> > ] 
> > > >From: Michael Thomas [ mailto:[email-masked] <mailto:[email-masked]>  < mailto:[email-masked] <mailto:[email-masked]> > ] 
> > > >  > >[ mailto:[email-masked] <mailto:[email-masked]>  
>< mailto:[email-masked] <mailto:[email-masked]> > ]On Behalf Of 
> > > >  > >Michael Thomas 
> > > >  > > > From: Michael Thomas [ mailto:[email-masked] <mailto:[email-masked]>  
>< mailto:[email-masked] <mailto:[email-masked]> > ] 
> > > >  > [ mailto:[email-masked] <mailto:[email-masked]>  
>< mailto:[email-masked] <mailto:[email-masked]> > ] 
> > > >  > 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 
> > > >  >  >  > 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> > 
> > > >  >  >  > 
> > > >  >  >  > 
> > > >  >  >  > 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> > 
> > > >  >  >  > 
> > > >  >  >  > 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> > 
> > > >  >  >  > 
> > > >  >  > 
> > > >  >  > 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> > 
> > > >  >  > 
> > > >  >  > 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> > 
> > > >  >  > 
> > > >  > 
> > > >  > 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> > 
> > > >  > 
> > > >  > 
> > > > 
> > > > 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> > 
> > > > 
> > > > 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> > 
> 
> 
> 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> > 
> 
> 
> http://lists.bell-labs.com/mailman/listinfo/sip <http://lists.bell-labs.com/mailman/listinfo/sip>

---

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

If one likes to use this opportunity for keeping the updated information in
the register, let us allow them to use it.

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 5:23 PM
To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; Lewis Karl-QA3387;
[email-masked]

-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:20 PM
To: Lewis Karl-QA3387; Lewis Karl-QA3387; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

May be several reasons:

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 5:08 PM
To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:03 PM
To: Lewis Karl-QA3387; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 4:57 PM
To: [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

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

Hi, Rohan:

Best regards,
Radhika R. Roy
AT&T

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

thanks,
-rohan

]

---

From: [email-masked]
Date: Thu, 5 Oct 2000 18:46:15 +0530

Yes-
I always liked REGISTER + re-INVITE addressing change of point of
attachment. However, I think the basic
problem that people had/have with this is that it *may* take too long to
propogate. If so, let it be solved more
efficiently in lower layers if it can . However, the idea that I can still
handle mobility at application level using SIP is equally
exciting for me. Just like we handle personal mobility using REGISTER, is
there really a problem if we allow a person
to do a re-INVITE at application level for dynamic point of att. changes -
especially since it does not warrant any changes to existing SIP ?

A basic question regarding time: Why exactly do we say that application
level re-INV will take too long and that doing it in
lower levels is faster ? Is it because the app. level SIP message may
traverse more hops ? If so, why cant we make
the SIP message traverse the same set of hops as this lower level message
would ? Or , is it due to INV-OK-ACK 3 way
transaction ? If so, would this be solved if we just used a 2-way
re-session establishment which only changes port and IP
and not codec for a session ? (probably in this case, there is no real
"capability " re-negotiation problems as its only an IP+port change...)
Just thinking aloud - am I missing something basic ?

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

"Roy, Radhika R, ALCOO" <[email-masked]> on 10/05/2000 06:01:52 PM

To:   Lewis Karl-QA3387 <[email-masked]>, Lewis Karl-QA3387
      <[email-masked]>, Lewis Karl-QA3387 <[email-masked]>,
      [email-masked]
cc:

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

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 5:23 PM
To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; Lewis Karl-QA3387;
[email-masked]

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 5 Oct 2000 09:55:51 -0500

Yes, you could emulate end-points changing their IP address by constantly
re-REGISTERing and re-INVITEing every time. However, that's an extremely
inefficient way of handling intra-session mobility because you're updating
the far end as to where you are, when if the lower layer takes care of this
(by a method in which the far end doesn't need to be aware that your IP has
changed) you'll be much better off.

In a mobile network, the problem of IP mobility is going to exist for
anything using IP. Also, only the mobile portion of the network necessarily
needs to be made cognizant of this. Elements beyond the edge-router of the
mobility capable network don't necessarily need to constantly be made aware
every time someone's IP changes. That's why I consider SIP a relatively slow
protocol for this purpose, because it works by updating nodes that don't
necessarily need to be made aware of the change in the IP address.

Here's an example: The solution that you are proposing, if we extended it to
a voice cell-phone network boils down to this. Every time you move far
enough in the network to need to make an underlying media change (a
handover, which can happen every few seconds if you're travelling in a car
on a busy highway), you want to have your phone to give the yellow pages a
new number for you to be listed at; then tell the person at the far end to
hang-up, and call you back at this new number. Yeah, it does the job, but
it's incredibly inefficient.

Also, in a mobile environment, you could potentially be changing locations
(and thus potentially IP addresses) at a rate faster than conventional
retransmission timer lengths for SIP. So now you run into race conditions
that require even more messages to resolve.

If you use a re-INVITE, you're also forcing the media change for the RTP
stream (in the case of voice) to now be held hostage to however long it
takes SIP to setup a new session. What are you going to do with the voice
path during the time that the mobile SIP stack figures out it's IP changed,
and it needs to setup a new RTP stream? How are you going to solve problems
arising from other network issues such as maybe the endpoint only has enough
bandwidth for 1 RTP stream at a time. You're requiring him to multicast 2
streams now until you can get the first one torn down (which doesn't matter
because all those packets are going to be lost since they're going to the
wrong IP now). What are you going to do if we start seeing that RTP packets
are getting to the wrong person (you change IPs, and someone else gets your
old IP that's in a call and starts receiving your old RTP packets). There
are a lot of implications of trying to solve a transport layer issue at the
application layer.

If you choose to solve the problem in this manner, and you test it in a lab
setting, it will likely work most of the time. Maybe all of the time.
However, once this hits the field and you start dealing with the low
bandwidth environments that air-links generally present us with today, and
higher levels of mobility that you will likely find in a deployed network;
you're going to run into some serious problems.

Brian Stucker
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 05, 2000 8:16 AM
To: Roy, Radhika R, ALCOO
Cc: Lewis Karl-QA3387; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

Yes-

Regds
Arjun

-----Original Message-----
From: Lewis Karl-QA3387 [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 5:23 PM
To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; Lewis Karl-QA3387;
[email-masked]

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 5 Oct 2000 10:18:51 -0500

What are you going to do with the media stream during a re-INVITE? How are
you going to ensure there is no RTP muting that results from this
"solution"?

SIP supports fixed length fields as well, but it's not a good idea at all to
implement that way.

Brian

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

Hi, Billy:

I guess that you have answered (i.e., clarified) most of the questions:

1. You are right that no new extension is needed using re-registration and
re-INVITE messages. So, people will be allowed to use these procedures. If
this is accepted, I assume that a significant milestone has been achieved
(by default, SIP becomes a mobility-aware application).

Once we accept this basic fact, people can go back to see what additional
things need to be done (some I-Ds are there), if any (may need some minor
extensions in SIP as well as some I-Ds suggest).

2. Hand-off is an area to see the impact in the SIP session layer. It is
primarily the performance aspect of it. (It is inherent problems for all
layers in the case of mobility).

3. Some (minor) extensions may be needed as I mentioned in item 1 (some I-Ds
have been proposed, but more can be looked into).

4. Logical call flows may not change at all (something similar to call
transfer and/or adding a new party in the call during the creation of ad hoc
conference call) to take care-of the hand-off situation.

5. It is not whether the idea is good or bad. It is a basic need of the
users to address the issues while the point of attachment changes during the
SIP session.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Billy Biggs [mailto:[email-masked]]
Sent: Thursday, October 05, 2000 10:37 AM
To: Roy, Radhika R, ALCOO
Cc: Arnoud van Wijk (ELN); 'hammer michael'; Brian Stucker; Rohan Mahy;
[email-masked]

  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]

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 5 Oct 2000 10:13:52 -0500

That's not necessarily true if I understand you correctly. Your SIP proxy
would not necessarily have to keep up with what is going on with the
endpoint as long as the transport network does the appropriate routing work
for anyone trying to address the mobile. You could have a stateless proxy,
for instance. The problem isn't so much with SIP as it is the media exchange
being setup through SIP (ie. an RTP stream).
 
Brian

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

All,

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.

Mike Hammer

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 ) 

thanks, 
-rohan 

) 

>From: Roy, Radhika R, ALCOO [ mailto:[email-masked] <mailto:[email-masked]>
< mailto:[email-masked] <mailto:[email-masked]> > ] 

> >From: hammer michael [ mailto:[email-masked]
<mailto:[email-masked]>  < mailto:[email-masked]
<mailto:[email-masked]> > 

> > > >From: Michael Thomas [ mailto:[email-masked] <mailto:[email-masked]>  <
mailto:[email-masked] <mailto:[email-masked]> > ] 
> > > >  > >[ mailto:[email-masked]
<mailto:[email-masked]>  
>< mailto:[email-masked]
<mailto:[email-masked]> > ]On Behalf Of 
> > > >  > > > From: Michael Thomas [ mailto:[email-masked]
<mailto:[email-masked]>  
> > > >  > [ mailto:[email-masked]
<mailto:[email-masked]>  
> > > >  > 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 
>< 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> > 
>< 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> > 
>< 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> > 
>< 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> >

---

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Thu, 5 Oct 2000 11:38:45 -0400

Hi, Brian:
 
You have nicely summarized the problems that are related to the media
re-direction due to the re-INVITE. It is worthwhile to investigate (I
believe that the lower layer [e.g., mobile IP] is also not solving this
satisfactorily).
 
The conclusion that you may have reached: Low bandwidth vs. High bandwidth
network.
 
However, not all wireless networks have low bandwidth (e.g., wireless LANs,
etc. are exceptions). The other thing is that not all hand-offs reach to the
SIP layer.
 
The things that we may need to address are as follows:
 
1. Let there be a general procedure in the SIP layer to deal with mobility.
2. There may be some performance problems when it is implemented in certain
networking conditions. Let people address this case by case basis.
 
Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Thursday, October 05, 2000 10:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )

Brian Stucker 
Nortel Networks 

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, October 05, 2000 8:16 AM 
To: Roy, Radhika R, ALCOO 
Cc: Lewis Karl-QA3387; [email-masked] 
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP 
Mobility ) 

Yes- 

Regds 
Arjun 

-----Original Message----- 
From: Lewis Karl-QA3387 [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, October 04, 2000 5:23 PM 
To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; Lewis Karl-QA3387; 
[email-masked] 
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP 
Mobility )

---

From: hammer michael <[email-masked]>
Date: Thu, 05 Oct 2000 14:35:34 -0700

Brian,

My main point was that the scope of control of the transport network 
extends only as far as the end of the transport connection.  If that 
connection bypasses the proxy, then the proxy would not be informed of the 
subsequent location of the user.  If the proxy was one of the end-points, 
then the flow of messages would probably keep in informed.  But it is best 
left to the transport network to maintain those connections once 
established, for all the reasons you pointed out, i.e. handoffs every few 
seconds.

But the question still remains in the bypass situation, as in the function 
of an HLR, if a new person were to want to contact the moving user, how 
does the proxy know where he is at any given time.  (As you know, from the 
VLR on down to the radio site, the serving network maintains the call path 
until the call ends.  At which point the user re-registers in the new 
network.  The home network has no idea until that time.)

If the user gets handed-off to another network operator and uses a new IP 
address:
-   Either the user tells the proxy directly by message to/through the 
proxy, or
-   the user tells some registration device (which may be at the network 
layer), or
-   the network nodes inform the registration device, and the proxy pulls 
it from there.

Else, as far as the proxy is concerned, the user is incommunicado.

Mike

At 10:13 AM 10/05/2000 -0500, Brian Stucker wrote:
>endpoint as long as the transport network does the appropriate routing 
>work for anyone trying to address the mobile. You could have a stateless 
>proxy, for instance. The problem isn't so much with SIP as it is the media 
>exchange being setup through SIP (ie. an RTP stream).
>
>Brian
>end-to-end IP streams, then any IP-dependent mechanism would be 
>constrained by its knowledge of what the endpoint is.
>
>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.
>
>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.
>
>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.
>
>>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
>>
>> >From: Roy, Radhika R, ALCOO [ 
>> <mailto:[email-masked]>mailto:[email-masked] <mailto:[email-masked]> ]
>> Schulzrinne 
>> <http://www.cs.columbia.edu/~hgs>http://www.cs.columbia.edu/~hgs