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

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

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