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

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Wed, 27 Sep 2000 16:03:46 -0400

Hi, Mike:

I do not think that anyone is saying - "SIP based application mobility is
Good Thing."

I think that I have clearly defined the problem (please see my email). 

For example, if a use starts talking using the SIP phone with another user
(fixed or mobile) and moves from one place to another while talking, do we
need to do any new work in the SIP layer as it stands today considering this
mobile environment (in this case it is continuous mobility)?

Let us do an analysis: 1. What needs to be done in the SIP layer, if any, 2.
What needs to be done in the IP layer (may be mobile IP if one likes to use
it), 3. What needs to be done in the link layer (e.g., wireless LANs,
cellular networks: CDMA, TDMA), and so and so forth.

In each layer there are two things: 1. Signaling and 2. Media.

For an end-to-end solution, one needs to analyze all things of all layers
together.

However, SIP WG only needs to confine itself to the SIP session layer in the
context SIP RFC 2543 only.

Hope this will clarify your concerns.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Wednesday, September 27, 2000 3: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]]
 > 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]]
 >  > 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. 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
 >  > 
 >  > 
 >  > _______________________________________________
 >  > 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
 >  > 
 > 
 > _______________________________________________
 > 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
 > 

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

---

From: hammer michael <[email-masked]>
Date: Thu, 28 Sep 2000 11:40:55 -0700

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
>
>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]
>Henry Sinnreich writes:
>  > >what seems clear is that there are a
>  > >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
>  >
>  > >From: [email-masked]
>  > >[mailto:[email-masked]]On Behalf Of
>  > >Michael Thomas
>  > >Sent: Wednesday, September 27, 2000 8:33 PM
>  > > > I guess that SIP, as you rightly pointed out, is
>  > >dealing with the signaling
>  > > > In mobile environment, the point of attachment
>  > >(i.e., addresses) changes: 1.
>  > > > The problem that is being addressed is: What is the
>  > >impact in SIP layer due
>  > > > I guess that for discrete mobility, SIP has
>  > >probably addressed most of the
>  > > > For continuous mobility, there may need (or may
>  > >not??) some works in the SIP
>  > > >  > is aware of the current status of
>  > >draft-itsumo-sip -mobility-req-01. In
>  > > >  > registration in less than a few seconds,
>  > >reconfiguration in milliseconds,
>  > > >  > providing location services, support of inter
>  > >domain soft-hand and secure
>  >  >  > Given the proliferation of SIP-related drafts, I've
>  > created a summary of
>  >  >  > efforts at
>  > http://www.cs.columbia.edu/~hgs/sip/drafts.html. This is
>  >  >  > additions or corrections. (Jonathan Rosenberg provided
>  > some of the text;
>  >  >  > 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

---

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

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

Mike

---

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

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

---

From: hammer michael <[email-masked]>
Date: Fri, 29 Sep 2000 10:56:39 -0700

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

---

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Fri, 29 Sep 2000 12:38:45 -0400

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

Mike

At 04:11 PM 09/28/2000 -0400, Roy, Radhika R, ALCOO wrote:
> > >In fact, this is the precisely the test why SIP should be involved or
to
>be
> > >aspects of users' discrete mobility? Has it not been be an excellent
way

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 29 Sep 2000 12:19:03 -0500

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

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: hammer michael [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 )

Mike

to
way

---

From: "Roy, Radhika R, ALCOO" <[email-masked]>
Date: Fri, 29 Sep 2000 13:51:12 -0400

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

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: 

Best regards, 
Radhika R. Roy 
AT&T 

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

Mike 

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

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

to 
way 
> > >Along the same line, if people come up with the ideas that it is better

> > >From: Michael Thomas [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > >  > >[ mailto:[email-masked]
<mailto:[email-masked]> ]On Behalf Of 
> > >  > > > From: Michael Thomas [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > >  > > >  > From: Henning Schulzrinne 
> > >  > [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > >  > http://www.cs.columbia.edu/~hgs/sip/drafts.html
<http://www.cs.columbia.edu/~hgs/sip/drafts.html> . This is 
> > >  >  >  > last call or two or ten... 
<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>  

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

---

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

Hi, Brian:
 
Let me add one more important technical point that has been raised by you:
Race, synchronization, performance, and other problems in the case of
re-INVITE message sent during the mid-session.
 
In general, these are the inherent problems of "continuous (intra-session)"
mobility in all layers: Physical, link, network, and application/session
layer.
 
It is worthwhile to investigate not only for the session layer, but for all
layers together.
 
Some I-Ds are there and people are experimenting in the labs. We like to
hear from them.
 
In the meantime, if you can provide some data on this, it would be much
helpful to see whether more innovative solutions can be found out.
 
Best regards,
Radhika R. Roy
AT&T
 
PS: I have added one word "NOT" in correcting my previous mail.

-----Original Message-----
From: Roy, Radhika R, ALCOO 
Sent: Friday, September 29, 2000 1:51 PM
To: 'Brian Stucker'; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )

Hi, Brian:

 
For intra-session mobility, it appears that you are feeling [Roy, Radhika R,
ALARC] "NOT" comfortable, as if, SIP is not designed to do this.

 
That's all!

 
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 )

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: 

Best regards, 
Radhika R. Roy 
AT&T 

-----Original Message----- 

Mike 

] 

to 
way 

<mailto:[email-masked]> ]

---

From: Lewis Karl-QA3387 <[email-masked]>
Date: Fri, 29 Sep 2000 16:10:54 -0500

This was forwarded to me. I haven't had a  chance to review it.

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Friday, September 29, 2000 9:57 AM
To: Michael Thomas; Roy, Radhika R, ALCOO
Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )

>   the SIP mobility draft
Where can I find it?

Thanks, Henry

>Sent: Thursday, September 28, 2000 5:05 PM
>Cc: Michael Thomas; Henry Sinnreich; Lewis
>Karl-QA3387; 'Henning
>   OK.
>   Just to be pedantic about my concern: if the
>   reality of the situation is that mobile ip is
>   going to be needed in the vast majority of
>   devices using SIP -- say because they have
>   embedded web browsers -- as a group, IETF
>   would be better served by trying to solve
>   the problem at layer 3 instead of each WG
>   trying to tackle the problem on their own.
>
>   Remember, the context of my concern here was
>   the SIP mobility draft which seems to take
>   application layer continuous mobility as a
>   starting point.
>
>   By discrete mobility, I assume you mean that
>   SIP doesn't repeat the PSTN'ism of assigning
>   a name (phone number) to the physical end of a
>   wire? Ie, that to: [email-masked] is divorced
>   from where I happen to be injecting IP packets
>   from? If so, I agree this is a Good Thing, but
>   I'm not sure that there's much if anything to
>   be done beyond that.
>
> > Let us keep our mind open and judge each proposal
>with its own
> > merits.
>
>   Sure. I said up front that I'm willing to believe
>   that real device layer mobility may very well dredge
>   up problems that need to be solved at the SIP layer
>   too.
>
>		Mike
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> >
> >  > [mailto:[email-masked]]
> >  >  >  > known to be incomplete, so I'd appreciate
>if you could
> >  > send me any

Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )
From: "Roy, Radhika R, ALCOO" <[email-masked]>
To: "Roy, Radhika R, ALCOO" <[email-masked]>, Brian Stucker <[email-masked]>, [email-masked]
Date: Fri, 29 Sep 2000 14:16:35 -0500

Hi, Brian:

 

 
Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Roy, Radhika R, ALCOO 
Sent: Friday, September 29, 2000 1:51 PM
To: 'Brian Stucker'; [email-masked]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )

Hi, Brian:

 

 
That's all!

 
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 )

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: 

Best regards, 
Radhika R. Roy 
AT&T 

-----Original Message----- 

Mike 

] 

to 
way 

<mailto:[email-masked]> ]