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

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

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

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Thu, 28 Sep 2000 09:04:52 -0700 (PDT)

> chat, IM, messaging, conferencing, games, and others.

   OK.

 > anyone will force it to do this.

   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.
 
 > applications like H.323 is yet to support)?

   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

   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

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 29 Sep 2000 15:56:30 +0100

>   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
> > Let us keep our mind open and judge each proposal
>with its own
> > merits.
>

---

From: "Simon Barber" <[email-masked]>
Date: Sat, 30 Sep 2000 00:33:23 -0700

I currently have a commercial need to make my SIP client operate from
networks with firewalls that will not allow SIP or RTP traffic through. I
have just posted a proposal to the AFT mailing list for a generic mechanism
to allow any protocol to operate through HTTP only firewalls. I've included
a copy of the message below - but this is definately off topic for the SIP
mailing list. Please post your replies on the AFT mailing list.

Simon Barber

------

proxy sockets

firewall admins will hate this.

This is a varient on the SOCKS protocol, with a couple of significant
differences. SOCKS V4 only allows a single TCP connection to be mapped to a
single SOCKS connection. SOCKS V5 is similar to V4 for TCP, and for UDP uses
a second UDP connection to transport the data for the socket that is
proxied.

Increasingly applications are finding that they have to run behindfirewalls,
with restricted access out. Either only TCP, or even HTTP connections may be
possible. As as result any protocol the application requires must be mapped
down to these protocols.

Here I propose a simple RPC mechanism for the berkeley sockets API, to run
over any bi-directional character stream. This could be implemented over
whatever the user wishes - TCP, TLS, HTTP, HTTPS or whatever connection is
available.

Multiple TCP connections, incoming and outgoing, and UDP connections would
all be supported over a single bi-directional character stream.

The protocol is defined in binary, to conserve bandwidth, especially
important since it is envisioned one use will be to carry RTP traffic over
TCP and HTTP connections. These connections are rate-limited, where RTP is
not. Because of this it is considered important to not add to the session
bandwidth. This would exacerbate problems with real-time media during
periods of congestion.

It is recommended that this protocol is implemented on the client as a
library - with a similar API as the berkeley sockets API. This will make it
simple to port non firewall friendly apps to use this protocol.

Messages, client->server:

Format:

1 byte - message number
followed by:

(todo: map API calls to binary messages)
Create
Bind
GetLocalAddr
Listen
GetPeerAddr
Connect
Send
SendTo
Close
IoCtl (used for multicast sockets)

Messages server->client

Create result
Bind result
Accept
Connect result
Recv
IoCtl result