RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )
Lewis Karl-QA3387 <K.Lewis@motorola.com> Wed, 04 October 2000 21:09 UTC
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01829 for <sip-archive@odin.ietf.org>; Wed, 4 Oct 2000 17:09:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DAB63443E5; Wed, 4 Oct 2000 16:09:01 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id 623CB443E5 for <sip@lists.bell-labs.com>; Wed, 4 Oct 2000 16:08:00 -0400 (EDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA20197 for <sip@lists.bell-labs.com>; Wed, 4 Oct 2000 14:07:36 -0700 (MST)]
Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA04381 for <sip@lists.bell-labs.com>; Wed, 4 Oct 2000 14:07:36 -0700 (MST)]
Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2650.21) id <TYQNG1J4>; Wed, 4 Oct 2000 16:07:36 -0500
Message-ID: <BB60654DFAA8D311B16400508B6F2538042FB2A3@il27exm05.cig.mot.com>
From: Lewis Karl-QA3387 <K.Lewis@motorola.com>
To: "'Roy, Radhika R, ALCOO'" <rrroy@att.com>, Lewis Karl-QA3387 <K.Lewis@motorola.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Attempt at summarizing current SIP drafts (SIP Mobility )
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 04 Oct 2000 16:07:35 -0500
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:rrroy@att.com] Sent: Wednesday, October 04, 2000 4:03 PM To: Lewis Karl-QA3387; sip@lists.bell-labs.com 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:K.Lewis@motorola.com] Sent: Wednesday, October 04, 2000 4:57 PM To: sip@lists.bell-labs.com 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:rrroy@att.com] Sent: Wednesday, October 04, 2000 3:34 PM To: Rohan Mahy Cc: Brian Stucker; sip@lists.bell-labs.com 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:rohan@cisco.com] Sent: Wednesday, October 04, 2000 4:14 PM To: Roy, Radhika R, ALCOO Cc: Brian Stucker; sip@lists.bell-labs.com 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:bstucker@nortelnetworks.com] >Sent: Friday, September 29, 2000 1:19 PM >To: sip@lists.bell-labs.com >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:rrroy@att.com <mailto:rrroy@att.com> ] >Sent: Friday, September 29, 2000 11:39 AM >To: hammer michael; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >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:mhammer@cisco.com <mailto:mhammer@cisco.com> ] > >Sent: Friday, September 29, 2000 1:57 PM >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com >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:mhammer@cisco.com <mailto:mhammer@cisco.com> >] > >Sent: Thursday, September 28, 2000 6:29 PM > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > >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:mhammer@cisco.com ><mailto:mhammer@cisco.com> ] > > >Sent: Thursday, September 28, 2000 2:41 PM > > >To: Roy, Radhika R, ALCOO; Michael Thomas; Henry Sinnreich > > >Cc: Lewis Karl-QA3387; 'Henning Schulzrinne'; sip@lists.bell-labs.com > > >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:mat@cisco.com <mailto:mat@cisco.com> ] > > > >Sent: Wednesday, September 27, 2000 7:01 PM > > > >To: Henry Sinnreich > > > >Cc: Michael Thomas; Roy, Radhika R, ALCOO; Lewis Karl-QA3387; 'Henning > > > >Schulzrinne'; sip@lists.bell-labs.com > > > >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: sip-admin@lists.bell-labs.com > > > > > >[ mailto:sip-admin@lists.bell-labs.com ><mailto:sip-admin@lists.bell-labs.com> ]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'; > > > > > >sip@lists.bell-labs.com > > > > > >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:mat@cisco.com ><mailto:mat@cisco.com> ] > > > > > > > Sent: Wednesday, September 27, 2000 12:32 PM > > > > > > > To: Lewis Karl-QA3387 > > > > > > > Cc: 'Henning Schulzrinne'; sip@lists.bell-labs.com > > > > > > > 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:schulzrinne@cs.columbia.edu ><mailto:schulzrinne@cs.columbia.edu> ] > > > > > > > Sent: Monday, September 25, 2000 9:20 AM > > > > > > > To: sip@lists.bell-labs.com > > > > > > > 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 > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip ><http://lists.bell-labs.com/mailman/listinfo/sip> > > > > > > > > > > > > > > _______________________________________________ > > > > > > > SIP mailing list > > > > > > > SIP@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip ><http://lists.bell-labs.com/mailman/listinfo/sip> > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip ><http://lists.bell-labs.com/mailman/listinfo/sip> > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip ><http://lists.bell-labs.com/mailman/listinfo/sip> > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip ><http://lists.bell-labs.com/mailman/listinfo/sip> > > > > > > > > > > > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip ><http://lists.bell-labs.com/mailman/listinfo/sip> > > > > > > > >_______________________________________________ > > > >SIP mailing list > > > >SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip ><http://lists.bell-labs.com/mailman/listinfo/sip> > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip ><http://lists.bell-labs.com/mailman/listinfo/sip> > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip
- RE: [SIP] Attempt at summarizing current SIP draf… hammer michael
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… Brian Stucker
- RE: [SIP] Attempt at summarizing current SIP draf… Michael Thomas
- RE: [SIP] Attempt at summarizing current SIP draf… Lewis Karl-QA3387
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… Brian Stucker
- RE: [SIP] Attempt at summarizing current SIP draf… Michael Thomas
- RE: [SIP] Attempt at summarizing current SIP draf… Henry Sinnreich
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- Re: [SIP] Attempt at summarizing current SIP draf… Michael Thomas
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… Arnoud van Wijk (ELN)
- RE: [SIP] Attempt at summarizing current SIP draf… Brian Stucker
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… Lewis Karl-QA3387
- RE: [SIP] Attempt at summarizing current SIP draf… Rohan Mahy
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… hammer michael
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… hammer michael
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… Brian Stucker
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- Re: [SIP] Attempt at summarizing current SIP draf… Henning Schulzrinne
- RE: [SIP] Attempt at summarizing current SIP draf… archow
- [SIP] SIP through firewalls without SIP proxy Simon Barber
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… Henry Sinnreich
- RE: [SIP] Attempt at summarizing current SIP draf… hammer michael
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- Re: [SIP] Attempt at summarizing current SIP draf… Bobby Sardana
- RE: [SIP] Attempt at summarizing current SIP draf… Henry Sinnreich
- RE: [SIP] Attempt at summarizing current SIP draf… Lewis Karl-QA3387
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… hammer michael
- RE: [SIP] Attempt at summarizing current SIP draf… Michael Thomas
- RE: [SIP] Attempt at summarizing current SIP draf… Brian Stucker
- RE: [SIP] Attempt at summarizing current SIP draf… Roy, Radhika R, ALCOO
- RE: [SIP] Attempt at summarizing current SIP draf… Lewis Karl-QA3387
- Re: [SIP] Attempt at summarizing current SIP draf… Billy Biggs