RE: [P2Prg] Re: [Sipping] Simple SIP usage scenario
<john.loughney@nokia.com> Wed, 21 March 2007 18:28 UTC
Return-path: <sipping-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5YC-0002Vq-IG; Wed, 21 Mar 2007 14:28:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5YA-0002VX-V0; Wed, 21 Mar 2007 14:28:42 -0400
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5Xx-0007BE-Cf; Wed, 21 Mar 2007 14:28:42 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2LIRwTq017122; Wed, 21 Mar 2007 20:28:20 +0200
Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 20:28:01 +0200
Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 13:27:58 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [P2Prg] Re: [Sipping] Simple SIP usage scenario
Date: Wed, 21 Mar 2007 13:27:57 -0500
Message-ID: <071568CA7B789D4AA170CEF8C9613B4F56BA06@daebe103.NOE.Nokia.com>
In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADEA7@namail5.corp.adobe.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [P2Prg] Re: [Sipping] Simple SIP usage scenario
Thread-Index: AcdrmN2A24TOsXtfSA6lItgUNePnzwANl4wgAAXWtiA=
References: <24CCCC428EFEA2469BF046DB3C7A8D225274F4@namail5.corp.adobe.com><45EF02F4.6060401@cisco.com><24CCCC428EFEA2469BF046DB3C7A8D223ADE9C@namail5.corp.adobe.com><4600F6A4.3070102@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADEA7@namail5.corp.adobe.com>
From: john.loughney@nokia.com
To: hsinnrei@adobe.com, pkyzivat@cisco.com
X-OriginalArrivalTime: 21 Mar 2007 18:27:58.0919 (UTC) FILETIME=[A6D84570:01C76BE6]
X-Nokia-AV: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab
Cc: sipping@ietf.org, p2psip@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org
Henry, Does this http://www.ietf.org/rfc/rfc4084.txt?number=4084 come close to your thoughts, or do you want something stronger_ john >-----Original Message----- >From: ext Henry Sinnreich [mailto:hsinnrei@adobe.com] >Sent: 21 March, 2007 08:50 >To: Paul Kyzivat >Cc: sipping@ietf.org; P2PSIP Mailing List >Subject: RE: [P2Prg] Re: [Sipping] Simple SIP usage scenario > >Paul, > >>My real point is how you distinguish between a "network service" >>and an endpoint. > >This is an excellent question. Until we find a more rigorous >definition, I would offer that in the spirit of the Carterfone >decision, anything that can be attached to the "stupid" >broadband network, wired or wireless with the logical >equivalent of an RJ-11 connector as an endpoint. The functions >of this endpoint must in no way be constrained by the >operator. Please see > >http://www.newamerica.net/publications/policy/wireless_net_neutrality > >Now we could use some contributors to help translate this in >IETF protocol language in the spirit of the recent IAB >"Reflections on Internet Transaprency": > >http://tools.ietf.org/group/iab/draft-iab-net-transparent-04.txt > >Thanks, Henry > >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >Sent: Wednesday, March 21, 2007 10:11 AM >To: Henry Sinnreich >Cc: P2PSIP Mailing List; sipping@ietf.org >Subject: Re: [P2Prg] Re: [Sipping] Simple SIP usage scenario > >Thanks henry. My real point is how you distinguish between a >"network service" and an endpoint. It seems to me that if >something acts like an endpoint (in the way it interacts), >then it *is* an endpoint for the purposes of p2psip. Whether a >server contains many "virtual endpoints" >or not, where it sits, and who owns/operates it is irrelevant. > > Paul > >Henry Sinnreich wrote: >> Paul, >> >> Thanks for your comments. They are all accurate and valid. >> >> There may be people around however and scenarios where >feature servers >> are not the best option, and where applications in the endpoints are >> preferable, either in a P2P SIP scenario or in a CS scenario with >> nothing more that 3261 SIP registrar/proxy/redirect available. >> >> Not all telephony and IM services can be implemented, but looking at >> Skype (though it is not the ultimate P2P system), good >enough for rich >> multimedia and even enterprise applications and good enough to have >> roughly 100 times more users than the nearest SIP based VoIP >provider >> that I know of (Vonage which is my "regular" telephone service, >besides >> Skype). >> >> The document has to be fixed however and all your comments are >welcome, >> so the next version will be improved. >> >> Simple SIP is just for one usage scenario - no "network services" >beyond >> what can be done with RFC 3261 (and some RFCs that >complement it), and >> the applications all in the endpoints. >> As in the e2e principle on the Internet. >> >> We believe this usage scenario benefits everybody: >> End users, enterprise IT networks, service providers, application >> developers and endpoint developers. >> >> Simple SIP however does not exclude all the other usage scenarios >> published in the SIPPING WG. >> >> Please everybody, keep the comments and questions coming, they are >very >> helpful for the next version. I promise to include answers, wherever >> pertinent. >> >> Thanks, Henry >> >> Note: Sorry for the duplicate messages to the p2prg, it was >my mistake >> and has propagated in the discussions. As per the indications of the >> SIPPING WG chair, the discussions on this topic will >continue only on >> the SIPPING list. >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, March 07, 2007 7:23 PM >> To: Henry Sinnreich >> Cc: p2prg@ietf.org; sipping@ietf.org >> Subject: [P2Prg] Re: [Sipping] Simple SIP usage scenario >> >> Henry, >> >> This is an interesting document. However I think I may not >understand >> all the assumptions that are being made. >> >> In particular, there is the assumption that network servers are not >> needed because all services can be provided by endpoints. But a >network >> server that terminates a call *is* an endpoint. (Lets keep B2BUAs out >of >> >> this for the moment.) >> >> For instance, take voicemail. I could have voicemail >implemented in my > >> phone. But that might not work very well if my phone is mobile and >isn't >> >> always online. So I may prefer to have a dedicated voicemail device, >> independent of my phone. I could buy this as a personal device, plug >it >> in at home, and go happily about my business. And I guess that would >fit >> >> your model. OTOH, I could contract with some voicemail service >provider >> to provide that service for me. It could be functionally >equivalent - >> registering with my AOR. Is that bad? There are pros and >cons to both >> approaches - I would be happy if both were available. >> >> Similarly with presence. If I have a single device that I >use with my >> AOR then it may be sufficient for it to implement presence itself. >> Watchers will realize that if they can't subscribe I must not be >> present. (But this will be inconvenient for watchers - they will have >to >> >> poll to discover when I am again available to accept presence >> subscriptions.) If I have more than one device that I use with the >same >> AOR, then having each implement presence presents some problems. SIP >> forking doesn't provide a reliable way for subscribers to establish >> subscriptions to all my endpoints, and the problem is compounded if >some >> >> of my devices go offline frequently. So, as with voicemail, >I may find > >> it useful to have a separate device that handles my presence. And >again, >> >> it could be an appliance I buy for myself, or a service I subscribe >to. >> >> The bottom line for the above: specialized services for an >AOR can be >> provided by a user owned/managed appliance, or by a network >service. I > >> see no reason to distinguish between them as long as they >function in >> the same manner. >> >> Regarding callee-caps/callerprefs: I sympathize that this is >a complex > >> spec. In many cases I think it could be replaced by pervasive use of >> presence. However I don't think access to presence will ever be >> pervasive. Even if everybody maintained presence, I have my doubts >that >> it will be made available to everyone who might want to call. The >value >> appears when there are multiple devices available for a single AOR, >not >> all of which have the same capabilities. The callerprefs >usecases RFC >> provides a number of plausible cases. However the key to whether >> callerprefs are useful comes in knowing when/how to incorporate them >> into requests. I don't expect anyone to provide a UI to a caller to >> explicitly construct caller preferences. Rather they are >potentially a > >> tool for implementing services in endpoints. At the least, some >> consideration is needed for how one reaches the appropriate endpoint >> when there are multiple candidates. >> >> Thanks, >> Paul >> >> Henry Sinnreich wrote: >>> Sorry, the discussions on this I-D were held on the initial >Columbia >>> University p2psip mailing list. They really belong here. >>> >>> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-01.txt > >>> >>> This memo discusses the usage scenario of SIP where all the >>> applications reside in the endpoints. This is an alternative to >the >> >>> current usage of SIP where the services reside in the network. >>> >>> The use of SIP where the applications reside in the endpoints is >>> applicable to P2P SIP networks and also to client-server >networks. > >>> >>> Such an approach reduces the number of required SIP related >> standards >>> (as by spring 2007) from roughly 100 to about 11. >>> >>> Successful IP communications must also include the relevant >>> standards for NAT traversal, some of which are not directly >>> related to SIP and also several standards for security. These > >>> standards are included in the simple usage scenario for SIP as >> well. >>> There may not be time to have it on the agenda of the SIPPING or >> P2PSIP >>> WGs, so any discussions on the lists will be helpful to correctly >> define >>> simple SIP usage scenario. One item to decide is whether the simple >> SIP >>> usage should be a WG item, in which WG, or an informational >individual >>> contribution. >>> Please comment. >>> >>> Here are some of the latest discussions: >>> >>> Benny Prijono wrote: >>> >>>> ask whether it's worth implementing it, since it's not too simple, >>>> and especially since without it these doesn't sound too >>>> "interesting", or they can be achieved by simpler/other means (for >>>> example, by looking at SDP for call hold. About talking to >>>> automaton, don't you just know when hearing it? >>> Implementing UA Capabilities is I believe a useful informational >>> reference, but should not be mandatory. I would add to Benny's >> comments >>> the following observation: >>> >>> Mobile devices are already predominating and we have to >think on what >> is >>> doable for mobile devices, as well as for other scenarios where a >> small >>> footprint is required. >>> >>> Proposal: Keep the normative and informational documents separate. >>> UA Capabilities and RPID belong to the informational part. >>> >>> What do you think? >>> >>> Henry >>> >>> -----Original Message----- >>> From: Benny Prijono [mailto:bennylp@pjsip.org] >>> Sent: Tuesday, March 06, 2007 3:40 PM >>> To: Alan Johnston >>> Cc: Henry Sinnreich; Spencer Dawkins; p2p-sip@cs.columbia.edu >>> Subject: Re: [p2p-sip] Lightweight SIP Toolkit for P2P and Basic CS >>> Systems >>> >>> Hi Alan, >>> >>> thanks for your response. Please see mine below. >>> >>> Alan Johnston wrote: >>>>> You are right. RFC 3840 indicating UA Capabilities is >designed for >>>>> network based services and need not be used in the simple SIP >>> scenario. >>>>> >>>> I don't really agree here. UA capabilities are useful even in >>>> peer-to-peer sessions. For example, isfocus is used to indicate >> local >>>> mixing is taking place, +sip.rendering=no indicates that you have >> been >>>> put on hold, automaton indicates that you are talking to a machine >> not >>> a >>>> human, etc. While caller preference implementation in servers is >>> very, >>>> very complicated, indicating capabilities in feature tags is very >> easy >>>> for UAs, in my opinion. >>> That is true of course, but I think I'm still not too convinced. >>> While such indications could be "useful" to know, IMO the main >>> strength, or even purpose, of the RFC is to allow UA >selection in the >>> server based on their capabilities (although please don't >quote me on >>> this since I only read it briefly). Without this capability in the >>> server, then UA implementors such as myself would seriously need to >>> ask whether it's worth implementing it, since it's not too simple, >>> and especially since without it these doesn't sound too >>> "interesting", or they can be achieved by simpler/other means (for >>> example, by looking at SDP for call hold. About talking to >automaton, >>> don't you just know when hearing it?). >>> >>> I could just be plainly wrong, of course... >>> >>> -benny >>> >>> _______________________________________________ >>> p2p-sip mailing list >>> p2p-sip@cs.columbia.edu >>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >>> >>> Benny, >>> >>> Thanks for your comments on the draft - see mine below on RFC 3840. >>> >>> Thanks, >>> Alan >>> >>> Henry Sinnreich wrote: >>>> Benny, >>>> >>>> Upon reviewing you excellent suggestions for simple SIP >usage, here >>>> are the considerations, item by item: >>>> >>>> >>>>> Since we taking out RFC 2119, what about putting in RFC 3265 >> (Session >>>>> Initiation Protocol (SIP)-Specific Event Notification) to fill in >> the >>>>> hole since presence depends on this. >>>>> >>>> Yes, definitely. RFC 3265 defining SIP events is very >useful for all > >>>> kind of new e2e services combining presence, applications and >>>> communications. >>>> >>>> >>>>> And thinking about other stuffs that are normative, what about RFC >>>>> 2617 for SIP digest authentication? >>>>> >>>> The SIP digest authentication scheme is already included in RFC >3261. >>>> >>>> >>>>> And RFC 4566 for SDP? >>>>> >>>> SDP is already implied in RFC 3261, so the updated RFC 4566 on SDP >is >> >>>> implied as well. >>>> >>>> >>>>> And is RFC 3840 really essential for endpoint based operations? >>>>> Looks like it's more to network based service to me. >>>>> >>>> You are right. RFC 3840 indicating UA Capabilities is designed for >>>> network based services and need not be used in the simple SIP >>> scenario. >>>> >>> I don't really agree here. UA capabilities are useful even in >>> peer-to-peer sessions. For example, isfocus is used to indicate >local >>> mixing is taking place, +sip.rendering=no indicates that you have >been >>> put on hold, automaton indicates that you are talking to a machine >not >> a >>> human, etc. While caller preference implementation in servers is >> very, >>> very complicated, indicating capabilities in feature tags is very >easy >>> for UAs, in my opinion. >>>>> And don't we want RPID (RFC 4480) for presence? I think we do. >>>>> >>>> RFC 4480 for rich presence extensions is useful/informative for >>>> developers, but the rich presence RPID may be a nuisance for some >and >> >>>> not enough for others. I suggest leaving this to the endpoint >>>> developers and to the market. >>>> >>>> >>>>> Call transfer (RFC 3515, 3420, 3891, 3892, 4488)? Probably not. >>>>> >>>> You are right again. Call transfer between UAs can be also done by >>>> IM-ing the URL of the caller or with a SIP event package as in RFC >>>> 3265 mentioned above. >>>> >>>> This brings the new count of SIP standards for the simple SIP >> scenario >>>> back to 11, if we don't include the SDP update. >>>> >>>> Last but not least, a successful standard must have OS code UA >>>> implementations, such as http://sourceforge.net/ and your >>>> http://pjsip.org/ >>>> >>>> Let's hope this reduced number (11 as of now) of SIP >standards will >>>> make this much easier, compared to the count at >http://rfc3261.net/ >>>> This applies both the core CS SIP (no network application >services) >>>> and P2P SIP. >>>> >>>> What do all you think? >>>> >>>> Thanks again, Henry >>>> >>>> -----Original Message----- >>>> From: Benny Prijono [mailto:bennylp@pjsip.org] >>>> Sent: Monday, March 05, 2007 7:31 PM >>>> To: Henry Sinnreich >>>> Cc: Spencer Dawkins; p2p-sip@cs.columbia.edu >>>> Subject: Re: [p2p-sip] Lightweight SIP Toolkit for P2P and >Basic CS >>>> Systems >>>> >>>> Hi Henry, >>>> >>>> Henry Sinnreich wrote: >>>> >>>>> Thanks for catching that RFC 2119 need not be counted as >a SIP RFC. >>>>> >>>>> >>>> Since we taking out RFC 2119, what about putting in RFC 3265 >(Session >> >>>> Initiation Protocol (SIP)-Specific Event Notification) to fill in >the >> >>>> hole since presence depends on this. >>>> >>>> And thinking about other stuffs that are normative, what about RFC >>>> 2617 for SIP digest authentication? And RFC 4566 for SDP? >>>> >>>> And is RFC 3840 really essential for endpoint based operations? >>>> Looks like it's more to network based service to me. >>>> >>>> And don't we want RPID (RFC 4480) for presence? I think we do. >>>> >>>> Call transfer (RFC 3515, 3420, 3891, 3892, 4488)? Probably not. >>>> >>>> Just my 2p. >>>> >>>> -benny >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>> This list is for NEW development of the application of SIP Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sip@ietf.org for new developments of core SIP >>> >> >> _______________________________________________ >> P2prg mailing list >> P2prg@irtf.org >> https://www1.ietf.org/mailman/listinfo/p2prg >> > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP Use >sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- [Sipping] Simple SIP usage scenario Henry Sinnreich
- Re: [Sipping] Simple SIP usage scenario Paul Kyzivat
- RE: [Sipping] Simple SIP usage scenario Henry Sinnreich
- Re: [Sipping] Simple SIP usage scenario Paul Kyzivat
- Re: [Sipping] Simple SIP usage scenario Dale.Worley
- RE: [Sipping] Simple SIP usage scenario Henry Sinnreich
- Re: [Sipping] Simple SIP usage scenario Paul Kyzivat
- RE: [Sipping] Simple SIP usage scenario Henry Sinnreich
- Re: [Sipping] Simple SIP usage scenario Dale.Worley
- Re: [Sipping] Simple SIP usage scenario Paul Kyzivat
- RE: [P2Prg] Re: [Sipping] Simple SIP usage scenar… Henry Sinnreich
- Re: [Sipping] Simple SIP usage scenario Eunsoo Shim
- RE: [Sipping] Simple SIP usage scenario Brian Stucker
- Re: [Sipping] Simple SIP usage scenario Eric Burger
- Re: [P2Prg] Re: [Sipping] Simple SIP usage scenar… Paul Kyzivat
- Re: [Sipping] Simple SIP usage scenario Paul Kyzivat
- Re: [Sipping] Simple SIP usage scenario Paul Kyzivat
- Re: [Sipping] Simple SIP usage scenario Eric Burger
- Re: [Sipping] Simple SIP usage scenario Diego B
- Re: [Sipping] Simple SIP usage scenario Paul Kyzivat
- Re: [Sipping] Simple SIP usage scenario Eric Burger
- RE: [P2Prg] Re: [Sipping] Simple SIP usage scenar… Henry Sinnreich
- RE: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Henry Sinnreich
- Re: [P2Prg] Re: [Sipping] Simple SIP usage scenar… Paul Kyzivat
- RE: [P2Prg] Re: [Sipping] Simple SIP usage scenar… john.loughney
- Re: [Sipping] Simple SIP usage scenario Dale.Worley
- Re: [Sipping] Simple SIP usage scenario Dale.Worley
- RE: [P2PSIP] RE: [P2Prg] Re: [Sipping] Simple SIP… Henry Sinnreich
- RE: [Sipping] Simple SIP usage scenario Michael Hammer (mhammer)
- RE: [Sipping] Simple SIP usage scenario Michael Hammer (mhammer)
- Re: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Paul Kyzivat
- RE: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Henry Sinnreich
- RE: [Sipping] Simple SIP usage scenario colin.pons
- Re: [P2Prg] RE: [Sipping] Simple SIP usage scenar… David R Oran
- RE: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Henry Sinnreich
- Re: [P2Prg] RE: [Sipping] Simple SIP usage scenar… David R Oran
- RE: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Michael Hammer (mhammer)
- Re: [Sipping] Simple SIP usage scenario Eric Burger
- RE: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Henry Sinnreich
- Re: [Sipping] Simple SIP usage scenario Paul Kyzivat
- Re: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Eunsoo Shim
- Re: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Paul Kyzivat
- Re: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Eunsoo Shim
- Re: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Paul Kyzivat
- RE: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Henry Sinnreich
- Re: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Jeroen van Bemmel
- Re: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP… Eric Cooper
- RE: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Henry Sinnreich
- Re: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Paul Kyzivat
- RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP… Brian Rosen
- Re: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Michael Slavitch
- Re: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Paul Kyzivat
- RE: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP… colin.pons
- RE: [P2Prg] RE: [Sipping] Simple SIP usage scenar… Michael Slavitch
- RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP… Michael Slavitch
- RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP… Henry Sinnreich
- Re: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP… David A. Bryan
- RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP… Michael Slavitch
- [Sipping] P2P SIP service assurance (was Simple S… Henry Sinnreich
- Re: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP… Adrian Georgescu
- RE: [Sipping] Simple SIP usage scenario Eric Burger
- Re: [Sipping] Simple SIP usage scenario Jeroen van Bemmel
- Re: [Sipping] Simple SIP usage scenario Paul Kyzivat
- RE: [Sipping] Simple SIP usage scenario Henry Sinnreich
- Re: [Sipping] Simple SIP usage scenario David R Oran