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

[Lewis Karl-QA3387 <[e-mail]>]

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

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


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:[e-mail]]
Sent: Wednesday, October 04, 2000 5:08 PM
To: Roy, Radhika R, ALCOO; Lewis Karl-QA3387; [e-mail]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )


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:[e-mail]]
Sent: Wednesday, October 04, 2000 4:03 PM
To: Lewis Karl-QA3387; [e-mail]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )


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:[e-mail]]
Sent: Wednesday, October 04, 2000 4:57 PM
To: [e-mail]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )


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:[e-mail]]
Sent: Wednesday, October 04, 2000 3:34 PM
To: Rohan Mahy
Cc: Brian Stucker; [e-mail]
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:[e-mail]]
Sent: Wednesday, October 04, 2000 4:14 PM
To: Roy, Radhika R, ALCOO
Cc: Brian Stucker; [e-mail]
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP
Mobility )


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:[e-mail]]
>Sent: Friday, September 29, 2000 1:19 PM
>To: [e-mail]
>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:[e-mail] <mailto:[e-mail]> ]
>Sent: Friday, September 29, 2000 11:39 AM
>To: hammer michael; Michael Thomas; Henry Sinnreich
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; [e-mail]
>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:[e-mail] <mailto:[e-mail]>
]
>
>Sent: Friday, September 29, 2000 1:57 PM
>To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
>Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; [e-mail]
>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:[e-mail]
<mailto:[e-mail]>
>]
> >Sent: Thursday, September 28, 2000 6:29 PM
> >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
> >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; [e-mail]
> >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:[e-mail]
><mailto:[e-mail]> ]
> > >Sent: Thursday, September 28, 2000 2:41 PM
> > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich
> > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; [e-mail]
> > >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:[e-mail] <mailto:[e-mail]> ]
> > > >Sent: Wednesday, September 27, 2000 7:01 PM
> > > >To: Henry Sinnreich
> > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387;
'Henning
> > > >Schulzrinne'; [e-mail]
> > > >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: [e-mail]
> > > >  > >[ mailto:[e-mail]
><mailto:[e-mail]> ]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';
> > > >  > >[e-mail]
> > > >  > >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:[e-mail]
><mailto:[e-mail]> ]
> > > >  > > > Sent: Wednesday, September 27, 2000 12:32 PM
> > > >  > > > To: Lewis Karl-QA3387
> > > >  > > > Cc: 'Henning Schulzrinne'; [e-mail]
> > > >  > > > 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:[e-mail]
><mailto:[e-mail]> ]
> > > >  >  >  > Sent: Monday, September 25, 2000 9:20 AM
> > > >  >  >  > To: [e-mail]
> > > >  >  >  > 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
> > > >  >  >  > [e-mail]
> > > >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >  >
> > > >  >  >  > _______________________________________________
> > > >  >  >  > SIP mailing list
> > > >  >  >  > [e-mail]
> > > >  >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >  >
> > > >  >  >
> > > >  >  > _______________________________________________
> > > >  >  > SIP mailing list
> > > >  >  > [e-mail]
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >
> > > >  >  > _______________________________________________
> > > >  >  > SIP mailing list
> > > >  >  > [e-mail]
> > > >  >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >  >
> > > >  >
> > > >  > _______________________________________________
> > > >  > SIP mailing list
> > > >  > [e-mail]
> > > >  > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >  >
> > > >  >
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >[e-mail]
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >[e-mail]
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
>
>
>_______________________________________________
>SIP mailing list
>[e-mail]
>http://lists.bell-labs.com/mailman/listinfo/sip
><http://lists.bell-labs.com/mailman/listinfo/sip>
>
>
>_______________________________________________
>SIP mailing list
>[e-mail]
>http://lists.bell-labs.com/mailman/listinfo/sip


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

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

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

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

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