Subject: RE: [SIP] sip mobility with REGISTER

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Thu, 28 Sep 2000 16:37:08 -0400

Hi, Billy:

Let me clarify again:

I am assuming that the general mobility problems are being addressed in each
layer as necessary. For example, mobile/cellular IP for the IP layer.
TDMA/CDMA-based cellular wireless mobility solution for the link layer, and
so on. These are all complementary solutions.

However, there is one fundamental point: Change in point of attachment in
the mobile environment.

The next question is: Whether or not this change in point of attachment will
cause any change in the address of the link layer, network layer, and/or
other layers.

Depending on this "change of address," each layer has to take the
appropriate action.

If any layer is transparent to this change of address, no action is
necessary.

(Again in the application layer, each application may express the addresses
in different ways. For example, SIP and H.323 have different addressing
schemes. It is very important to note that, in the network/link layer, it is
may not be the case.)

If we follow the above principles, we can easily find out what needs to be
done in each layer.

Hope this will clarify your points.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Billy Biggs [mailto:[email-masked]]
Sent: Thursday, September 28, 2000 4:02 PM
To: Roy, Radhika R, ALCOO
Cc: farhan; sip
Subject: Re: [SIP] sip mobility with REGISTER

  Radhika,

> The bottom line of your argument is "performance (e.g., frequency of
> use, latency, etc.)" problems, if you use anything in the SIP layer to
> address mobility.

  No, the bottom line of my argument is correctness of the solution.

> Let assume for sake of argument that there is no performance problem: Will
> the procedure work using REGISTER and re-INVITE?

  Yes it will work, in a sense of technically you can send SIP messages
which can effectively divert an active SIP session from one endpoint to
another.

  However, that solution is not the correct solution for solving the
more general problem of a mobile endpoint which uses communication
services which run over IP.

  If an endpoint decides to change IP addresses, what happens to any
active HTTP connections, or telnet connections, or TCP connections, or
SIP sessions?  A solution which solves the problem only for SIP sessions
seems to be a waste.

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

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

---

From: Billy Biggs <[email-masked]>
Date: Thu, 28 Sep 2000 16:11:28 -0500

Radhika,

> However, there is one fundamental point: Change in point of attachment
> in the mobile environment.  [...]   Depending on this "change of
> address," each layer has to take the appropriate action.  If any layer
> is transparent to this change of address, no action is necessary.

  The IP layer has no concept of mobility, and IP addresses are used
casually in upper-layer protocols.  As well, all protocols which run
over IP assume that the IP addresses used do not change mid-session.
So, any mobility solution in an IP network MUST NOT allow the IP address
of an active session to change.

  This means that IP mobility can only be implemented through address
changes in the lower layers, tunnelling through a 3rd party with a fixed
IP address, or informing the routers of new route information for a
specific address.

  Because of this architecture, applications built on IP are guarenteed
that they do not need to worry about mobility, since it is unsupported
by the IP layer they are built on.

  Since SIP is built on IP, by definition no changes need to be made to
SIP to support terminal mobility.

  The mechanisms SIP provides for doing SIP "mobility" are addressing a
different problem: that of user mobility, not endpoint mobility.  While
I agree that you can get away with updating a session endpoint in SIP, I
don't believe this solution should be in any way associated with the
concept of endpoint mobility.