Subject: [SIP] sip mobility with REGISTER

From: "farhan" <[email-masked]>
Date: Thu, 28 Sep 2000 22:15:08 +0530

i maybe a little naive here. but isn't REGISTER already covering a great
deal of mobility issues?

moblity will be, for a fact handled at lower levels. for instance,
bluetooth. On my Windows CE PDA, running off a bluetooth pcmcia card from
ericssons, I have little problem of mobility - bluetooth handles everything.

in the coming ICE age, i dont think we are going to be faced with exclusive
sip-only network. as per the RFC, sip is an application level protocol thus,
the transport layer issues are, well, transport level issues. The issue is
aren't we really talking about using a general purpose networking layer to
run SIP? If we are, then it is understood that SIP, http, and a host of
other application layer protocols for services being delivered over the
network will not have to reinvent their own mobility schemes which may also
work in separate ways. I mean, if my sip UA is in turn going to invoke a web
page that creates a http persistent session with cookies, i wouldn't want to
loose the continuity of the page as i move from one room to another while
the sip session goes on. Thus, it is essential to have the mobility issues
handled at a lower level. SIP is and should be an application layer
protocol. Lets

in anycase, what specific mobility issues are not handlable by the REGISTER
request? Are we also discussiing when REGISTER should be invoked? I dont
think that even that is a good idea to put on paper. Different types of
networks will have different approaches and needs. A mobile network may
derive their 'q' from signal strength and the registrar may have to decide
on a criterion different from a provider like hotsip which maybe searching
for a least-cost route (prefer a sip UA to a sip gateway).

- farhan

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

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 28 Sep 2000 19:19:16 -0500

Radhika, et. al.

Any robust IP-aware solution for a wireless terminal has to take into
account the underlying transport media being switched during an IP session.
I seriously doubt you will find anyone deploying a service on a wireless
network where the IP address visibly changes outside of the provider's
network every time the terminal hands-off. In other words, the IP stack at
the service provider and on the terminal has to be cognizant of mobility and
make that transparent to higher-order applications through some sort of
NAT/router functionality. It's simply unacceptible to deploy a system where
you have to rewrite all of the major IP application level protocols in order
to support IP layer mobility, or setup a system whereby all of your TCP
streams die whenever you do a handover because your IP changed.

As long as the mobility-capable IP endpoint uses the external IP presence
assigned to it by the network (regardless if the underlying IP structure
changes) for REGISTERS and INVITES you should be in good shape, or at the
very least in no worse shape than someone running a SIP stack in a DHCP
environment. The mobile IP network should perform any address translation
needed to map external packets destined for the external IP to the one
currently in use by the device if necessary.

I would also suggest that trying to "engineer" SIP, which by the nature of
it's routing mechanisms alone makes it a "slow propagation" protocol, into
hiding IP mobility problems (which require "instant propagation") is going
to cause whomever tries to implement this a great deal of headache, and
their implementation users a great deal of foul language directed at their
devices.

In order to effectively deal with problems such as packet black-outs on
handover, ping-ponging, handover retries, handbacks, shoe-stringing, etc.
You're going to need to deal with this at a layer lower than SIP. In a
real-world environment you run into all manner of wild scenarios that can
cause trying to deal with intra-session mobility with an inter-session
solution (ie. INVITE, REGISTER) a recipe for disaster due to all sorts of
race conditions that you'd be introducing. It's hard enough to deliver, and
keep up a simple circuit-switched phone call to a mobile phone due to
mobility, and the protocols are designed specifically to handle this. =)

Brian Stucker
Nortel Networks

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

Hi, Billy:

I guess that we agreeing on the fundamental points.

What is the difference then?

SIP is basically transport independent (e.g., it is not tied to any
transport - it can run on IP, it can also run on ATM).

No layer is basically aware about mobility (e.g., CDMA, TDMA, LAN, IP, ATM,
etc.).

To solve some mobility related problems people devise some mechanisms. For
example, mobile IP, cellular IP, wireless ATM, wireless LAN, etc. are the
answers for addressing some kinds of mobility related problems. These are
value-added features. So, no one can mandate what needs to be done in the
value-added features (e.g., "any mobility solution in an IP network MUST NOT
allow the IP address of an active session to change" is NOT applicable).

Hope this will clarify the points.

Best regards,
Radhika R. Roy
AT&T

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

  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.

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

---

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Fri, 29 Sep 2000 15:02:46 -0400

Hi, Farhan:

I think that you have rightly captured the true essence: Let us keep the
doors open for innovative solutions.

You are right that Re-INVITE and re-REGISTRATION are SIP messages and belong
to the session layer of SIP.

We are using re-INVITE and re-REGISTRAION even in the static environment
even today. We will be using the same thing in mobile environment as well.
It does not change the basic procedures in SIP whether it is mobile or
non-mobile environment.

It is the lower layer that is doing all  mobility related functions. As a
result, a reaction may propagate to the upper layer to cause it to send the
re-INVITE and re-REGISTRAION messages.

So, I guess that we are in agreement.

Best regards,
Radhika R. Roy
AT&T

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

Billy Biggs wrote: 
>   I think you are confused as to the general purpose of a REGISTER
> message.  A REGISTER is intended to be used to inform the proxy of a new
> point of contact for a user, not a new location for an active point of
> contact.

we dont 'intend' things in a protocol. we just use them. a protocol
specifies how two entities will interact in a predictible manner. it
does not and should not enter into the realm of why they want to do
that. if that were the case, you are essentially arguing against
innovative application of existing protocols. for instance, the purpose
of http is to transfer documents and not read email - hotmail is out.
the purpose of UDP is not real time communication but unreliable
delivery- rtp is out.

> Even to do the hacked solution of REGISTER'ing under the new
> address and attempting to re-INVITE any active sessions, you don't need
> to add any new modifications to SIP.
> 

i dont forsee reinvites or re-registers due to mobile ip issues. mobile
ip should gaurenttee seamless and continuous coverage. it is completely
an issue of the network (or maybe even a lower layer - like in
bluetooth).

lets define the issue of mobility. when we are talking within sip
persepective, we are essentially talking of app level mobility. correct
me if i am wrong.

app level mobility means that i should be able to switch between varying
apps. from my desktop UA to my cell phone to my answering machine at
voicemail.com seamlessly and on a single id. something that is being
promised by likes of hotsip. the mobility is NOT in terms of physical
space but application layer. for that end, REGISTER is perfect. With
remarkable clarity and insight, REGISTER talks about third party
registerations, multiple registerations and forking locators. All of
them fully and completely cover mobility.

- farhan