From pierreantoine.antonini at francetelecom.com Mon Aug 8 08:34:38 2005 From: pierreantoine.antonini at francetelecom.com (ANTONINI Pierre-Antoine RD-SIRP-ISS) Date: Mon Aug 8 08:34:54 2005 Subject: [p2p-sip] Why using Chord in P2P SIP? Message-ID: <14FD20369E52DE478BD9612D63BE21B4059508C4@ftrdmel3.rd.francetelecom.fr> Dear All, I am currently reading the several drafts regarding P2P SIP and I am wondering why everyone is going for Chord as the P2P routing protocol and not Pastry, Kademlia or CAN. Is there any particular reason for this choice or is it only quoted as an example? Best Regards, Pierre-Antoine Antonini France Telecom DivR&D SIRP/SIS 38-40 rue du G?n?ral Leclerc F-92794 Issy-Les-Moulineaux Tel: +33 1 45 29 65 74 Email: pierreantoine.antonini@rd.francetelecom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20050808/bb9d99c0/attachment.html From lists at bulukucing.org Mon Aug 8 16:30:33 2005 From: lists at bulukucing.org (Benny Prijono) Date: Mon Aug 8 10:29:05 2005 Subject: [p2p-sip] P2P SIP Motivation Message-ID: <42F7C0E9.4010601@bulukucing.org> Dear all, just as I'm eager to follow the development of P2P standard using SIP, I have yet still remain unconvinced about the real need to have a P2P SIP. The draft (draft-bryan-sipping-p2p-01.html) promises to explain the motivation, but the sample usage scenarios described in the introduction doesn't seem to convince me. So I need to ask this very naive question (sorry). Why do we need P2P. I thought that the ideal communication model endorsed by IETF is where people subscribe (register) to different ITSP/domains (just like ISP) and then they would be able to call/chat/conference people on different domains (just like email), ideally for free. If I were visiting my parents in East Java, I would then just use local ISP's proxy as outbound proxy or whatever, and still register to my main ITSP so that others can call me. I know that *probably* current services offerred by ITSPs at the moment prohibit people from calling others/receiving calls from outside the domain, thus creating "walled gardens" between different ITSPs. But wouldn't P2P create another walled garden, where you still wouldn't be able to call your friends@ITSP? Of course you can call your friend@ITSP if the ITSP allows its subscribers to receive calls from outside the domain, but when this happens, why would we still need P2P then? Please someone shed a light. thanks, benny From mah at inode.at Mon Aug 8 18:24:30 2005 From: mah at inode.at (Michael Haberler) Date: Mon Aug 8 18:25:48 2005 Subject: [p2p-sip] P2P SIP Motivation In-Reply-To: <42F7C0E9.4010601@bulukucing.org> References: <42F7C0E9.4010601@bulukucing.org> Message-ID: <6.2.1.2.2.20050808234256.0325f220@localhost> At 22:30 08.08.2005, Benny Prijono wrote: >Dear all, > >just as I'm eager to follow the development of P2P standard using SIP, I >have yet still remain unconvinced about the real need to have a P2P SIP. >The draft (draft-bryan-sipping-p2p-01.html) promises to explain the >motivation, but the sample usage scenarios described in the introduction >doesn't seem to convince me. > >So I need to ask this very naive question (sorry). > >Why do we need P2P. I thought that the ideal communication model endorsed >by IETF is where people subscribe (register) to different ITSP/domains >(just like ISP) and then they would be able to call/chat/conference people >on different domains (just like email), ideally for free. If I were >visiting my parents in East Java, I would then just use local ISP's proxy >as outbound proxy or whatever, and still register to my main ITSP so that >others can call me. > >I know that *probably* current services offerred by ITSPs at the moment >prohibit people from calling others/receiving calls from outside the >domain, thus creating "walled gardens" between different ITSPs. But >wouldn't P2P create another walled garden, where you still wouldn't be >able to call your friends@ITSP? Of course you can call your friend@ITSP if >the ITSP allows its subscribers to receive calls from outside the domain, >but when this happens, why would we still need P2P then? I join the fool's league - that's something I had been asking myself - what is the problem being adressed, given that the cost of operating a SIP proxy and owning a domain is next to zero in the first place? looking at skype: what is P2P here is a *distributed media relay* (that clearly saves cost, might scale, great idea) target discovery might be P2P, few savings here but who cares - DNS, databases actually do work (what problem is actually being fixed here by P2P ?) authentication is centralized, no savings wrt SIP proxy media gateways to/from PSTN centralized too, same as above unsolved problems: certified identity - orthogonal but potentially worse except if fallback to centralized authentication (well guess what skype does for billable services) related to that: spam/spit - no change attributable to the core concept SIP/SIMPLE efforts convergence on something implementable/interoperable/deployable - as above potential upsides: getting around political problems with ITU, ICANN, CALEA, regulators etc, time to market - most of which could be downsides in some respect too. My personal experience is that these problems are tractable. I cant see the walled garden problem you are mentioning - this effort which is obviously geared towards a standard, interoperable and all. I like the P2P concept and algorithms, sounds cute, all the rage these days, wrt to standards-based VoIP/IP communications adoption thats currently rearranging deckchairs on the Titanic for me. But I might be overlooking something. Flame & enligthen me. just as naive & lost in Vienna. -Michael MBA at times From davidbryan at gmail.com Fri Aug 12 10:41:33 2005 From: davidbryan at gmail.com (David A. Bryan) Date: Fri Aug 12 10:41:51 2005 Subject: [p2p-sip] Pre-IETF meeting on P2P SIP in Vancouver Message-ID: <8b2769930508120741605901f1@mail.gmail.com> (cross posted to sipping and the new P2P SIP list in case interested parties aren't subscribed yet...) At the P2P SIP informal BOF at IETF-63 in Paris, one item that came out of the meeting was the desire for another, longer meeting to try to discuss some of these topics. The general consensus was that we should try to meet just prior to the next IETF in Vancouver. I wanted to go ahead and start to organize/coordinate this. Can people please reply (either to me directly, or to the P2P SIP list -- try to keep the traffic on SIPPING down) to let me know if they are interested (head count), and any thoughts on structure for the meeting. Currently, I am thinking a good plan is the Sunday before IETF-64 (the 6th of November), likely a longer session (4 or 8 hours) somewhere in Vancouver that would be convenient for IETF attendees. Also, can people start sending me a list of topics they are interested in, so that I can start to organize an agenda of the topics people would like discussed? For those that may have missed the announcement or haven't yet joined the P2P list, but are interested in discussing this issue or any other P2P SIP issue, the URL for the new mailing list Henning put together (thank you Henning!) is here: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip I'm also assembling all the notes from the informal BOF and will put them up at p2psip.org. Thanks, and looking forward to moving forward on this! David Bryan -- David Bryan Please continue to send me email at the address bryan@ethernot.org From davidbryan at gmail.com Fri Aug 12 11:52:58 2005 From: davidbryan at gmail.com (David A. Bryan) Date: Fri Aug 12 12:21:51 2005 Subject: [p2p-sip] Pre-IETF meeting on P2P SIP in Vancouver In-Reply-To: <42FCBFE1.1010608@research.panasonic.com> References: <8b2769930508120741605901f1@mail.gmail.com> <42FCBFE1.1010608@research.panasonic.com> Message-ID: <8b27699305081208523092cfc9@mail.gmail.com> Yes, this is the idea proposed at the ad-hoc, I just wanted to start the work involved in organizing it so that we had an idea of interest, and could start planning topics people were interested in and the like. --David On 8/12/05, Eunsoo Shim wrote: > Hi, David, > > I am interested. > BTW, is that something similar to the workshop idea proposed in the last > ad-hoc meeting? > Thanks. > > Eunsoo > > David A. Bryan wrote: > > >(cross posted to sipping and the new P2P SIP list in case interested > >parties aren't subscribed yet...) > > > >At the P2P SIP informal BOF at IETF-63 in Paris, one item that came > >out of the meeting was the desire for another, longer meeting to try > >to discuss some of these topics. The general consensus was that we > >should try to meet just prior to the next IETF in Vancouver. > > > >I wanted to go ahead and start to organize/coordinate this. Can people > >please reply (either to me directly, or to the P2P SIP list -- try to > >keep the traffic on SIPPING down) to let me know if they are > >interested (head count), and any thoughts on structure for the > >meeting. > > > >Currently, I am thinking a good plan is the Sunday before IETF-64 (the > >6th of November), likely a longer session (4 or 8 hours) somewhere in > >Vancouver that would be convenient for IETF attendees. Also, can > >people start sending me a list of topics they are interested in, so > >that I can start to organize an agenda of the topics people would like > >discussed? > > > >For those that may have missed the announcement or haven't yet joined > >the P2P list, but are interested in discussing this issue or any other > >P2P SIP issue, the URL for the new mailing list Henning put together > >(thank you Henning!) is here: > > > >http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > >I'm also assembling all the notes from the informal BOF and will put > >them up at p2psip.org. > > > >Thanks, and looking forward to moving forward on this! > > > >David Bryan > > > > > > > > -- David Bryan Please continue to send me email at the address bryan@ethernot.org From eunsoo at research.panasonic.com Fri Aug 12 11:27:29 2005 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Fri Aug 12 13:06:11 2005 Subject: [p2p-sip] Pre-IETF meeting on P2P SIP in Vancouver In-Reply-To: <8b2769930508120741605901f1@mail.gmail.com> References: <8b2769930508120741605901f1@mail.gmail.com> Message-ID: <42FCBFE1.1010608@research.panasonic.com> Hi, David, I am interested. BTW, is that something similar to the workshop idea proposed in the last ad-hoc meeting? Thanks. Eunsoo David A. Bryan wrote: >(cross posted to sipping and the new P2P SIP list in case interested >parties aren't subscribed yet...) > >At the P2P SIP informal BOF at IETF-63 in Paris, one item that came >out of the meeting was the desire for another, longer meeting to try >to discuss some of these topics. The general consensus was that we >should try to meet just prior to the next IETF in Vancouver. > >I wanted to go ahead and start to organize/coordinate this. Can people >please reply (either to me directly, or to the P2P SIP list -- try to >keep the traffic on SIPPING down) to let me know if they are >interested (head count), and any thoughts on structure for the >meeting. > >Currently, I am thinking a good plan is the Sunday before IETF-64 (the >6th of November), likely a longer session (4 or 8 hours) somewhere in >Vancouver that would be convenient for IETF attendees. Also, can >people start sending me a list of topics they are interested in, so >that I can start to organize an agenda of the topics people would like >discussed? > >For those that may have missed the announcement or haven't yet joined >the P2P list, but are interested in discussing this issue or any other >P2P SIP issue, the URL for the new mailing list Henning put together >(thank you Henning!) is here: > >http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > >I'm also assembling all the notes from the informal BOF and will put >them up at p2psip.org. > >Thanks, and looking forward to moving forward on this! > >David Bryan > > > From mahfuz at research.panasonic.com Fri Aug 12 15:07:28 2005 From: mahfuz at research.panasonic.com (Mahfuzur Rahman) Date: Fri Aug 12 15:11:20 2005 Subject: [p2p-sip] Pre-IETF meeting on P2P SIP in Vancouver References: <8b2769930508120741605901f1@mail.gmail.com><42FCBFE1.1010608@res earch.panasonic.com> <8b27699305081208523092cfc9@mail.gmail.com> Message-ID: <004801c59f71$1527ae10$6a01a996@MAHFUZT12K> I like the idea to organize it around November IETF. -Mahfuz ----- Original Message ----- From: "David A. Bryan" To: "Eunsoo Shim" Cc: ; "Bruce Lowekamp" ; Sent: Friday, August 12, 2005 11:52 AM Subject: Re: [p2p-sip] Pre-IETF meeting on P2P SIP in Vancouver > Yes, this is the idea proposed at the ad-hoc, I just wanted to start > the work involved in organizing it so that we had an idea of interest, > and could start planning topics people were interested in and the > like. > > --David > > On 8/12/05, Eunsoo Shim wrote: > > Hi, David, > > > > I am interested. > > BTW, is that something similar to the workshop idea proposed in the last > > ad-hoc meeting? > > Thanks. > > > > Eunsoo > > > > David A. Bryan wrote: > > > > >(cross posted to sipping and the new P2P SIP list in case interested > > >parties aren't subscribed yet...) > > > > > >At the P2P SIP informal BOF at IETF-63 in Paris, one item that came > > >out of the meeting was the desire for another, longer meeting to try > > >to discuss some of these topics. The general consensus was that we > > >should try to meet just prior to the next IETF in Vancouver. > > > > > >I wanted to go ahead and start to organize/coordinate this. Can people > > >please reply (either to me directly, or to the P2P SIP list -- try to > > >keep the traffic on SIPPING down) to let me know if they are > > >interested (head count), and any thoughts on structure for the > > >meeting. > > > > > >Currently, I am thinking a good plan is the Sunday before IETF-64 (the > > >6th of November), likely a longer session (4 or 8 hours) somewhere in > > >Vancouver that would be convenient for IETF attendees. Also, can > > >people start sending me a list of topics they are interested in, so > > >that I can start to organize an agenda of the topics people would like > > >discussed? > > > > > >For those that may have missed the announcement or haven't yet joined > > >the P2P list, but are interested in discussing this issue or any other > > >P2P SIP issue, the URL for the new mailing list Henning put together > > >(thank you Henning!) is here: > > > > > >http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > >I'm also assembling all the notes from the informal BOF and will put > > >them up at p2psip.org. > > > > > >Thanks, and looking forward to moving forward on this! > > > > > >David Bryan > > > > > > > > > > > > > > > > -- > David Bryan > Please continue to send me email at the address bryan@ethernot.org > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > From fluffy at cisco.com Fri Aug 12 15:14:54 2005 From: fluffy at cisco.com (Cullen Jennings) Date: Fri Aug 12 15:15:15 2005 Subject: [p2p-sip] Re: [Sipping] Pre-IETF meeting on P2P SIP in Vancouver In-Reply-To: <40qjma$34kg24@sj-inbound-e.cisco.com> Message-ID: I plan to attend. An 7 hour block would really give time to make progress vs. just summarize things. On 8/12/05 9:15 AM, "Henry Sinnreich" wrote: > I plan to attend the meeting prior to the next IETF in Vancouver and would > like to add to the agenda: > > 1 - Choice of P2P protocols, such as Chord vs. DNS > See for example http://ag-projects.com/SIPThor.html > > 2 - The pros and cons of SIP UAs or SIP proxy/registrar being P2P members. > > 3 - Generic list of P2P system choices, such as the above. > > Thanks, Henry > > > > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf > Of David A. Bryan > Sent: Friday, August 12, 2005 9:42 AM > To: p2p-sip@cs.columbia.edu; sipping@ietf.org > Cc: Bruce Lowekamp; Cullen Jennings; Henning Schulzrinne > Subject: [Sipping] Pre-IETF meeting on P2P SIP in Vancouver > > (cross posted to sipping and the new P2P SIP list in case interested > parties aren't subscribed yet...) > > At the P2P SIP informal BOF at IETF-63 in Paris, one item that came > out of the meeting was the desire for another, longer meeting to try > to discuss some of these topics. The general consensus was that we > should try to meet just prior to the next IETF in Vancouver. > > I wanted to go ahead and start to organize/coordinate this. Can people > please reply (either to me directly, or to the P2P SIP list -- try to > keep the traffic on SIPPING down) to let me know if they are > interested (head count), and any thoughts on structure for the > meeting. > > Currently, I am thinking a good plan is the Sunday before IETF-64 (the > 6th of November), likely a longer session (4 or 8 hours) somewhere in > Vancouver that would be convenient for IETF attendees. Also, can > people start sending me a list of topics they are interested in, so > that I can start to organize an agenda of the topics people would like > discussed? > > For those that may have missed the announcement or haven't yet joined > the P2P list, but are interested in discussing this issue or any other > P2P SIP issue, the URL for the new mailing list Henning put together > (thank you Henning!) is here: > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > I'm also assembling all the notes from the informal BOF and will put > them up at p2psip.org. > > Thanks, and looking forward to moving forward on this! > > David Bryan From davidbryan at gmail.com Fri Aug 12 15:38:15 2005 From: davidbryan at gmail.com (David A. Bryan) Date: Fri Aug 12 15:38:28 2005 Subject: [p2p-sip] Re: [Sipping] Pre-IETF meeting on P2P SIP in Vancouver In-Reply-To: References: <40qjma$34kg24@sj-inbound-e.cisco.com> Message-ID: <8b2769930508121238d9c3624@mail.gmail.com> Yes, I think a longer meeting is better. Several others have who have responded have made similar comments -- leaves time for a number of sessions. Henry already mentioned a number of important topics, and I am sure more will come up, so having time to discuss as many as possible makes good sense. David On 8/12/05, Cullen Jennings wrote: > > I plan to attend. > > An 7 hour block would really give time to make progress vs. just summarize > things. > > > On 8/12/05 9:15 AM, "Henry Sinnreich" wrote: > > > I plan to attend the meeting prior to the next IETF in Vancouver and would > > like to add to the agenda: > > > > 1 - Choice of P2P protocols, such as Chord vs. DNS > > See for example http://ag-projects.com/SIPThor.html > > > > 2 - The pros and cons of SIP UAs or SIP proxy/registrar being P2P members. > > > > 3 - Generic list of P2P system choices, such as the above. > > > > Thanks, Henry > > > > > > > > -----Original Message----- > > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf > > Of David A. Bryan > > Sent: Friday, August 12, 2005 9:42 AM > > To: p2p-sip@cs.columbia.edu; sipping@ietf.org > > Cc: Bruce Lowekamp; Cullen Jennings; Henning Schulzrinne > > Subject: [Sipping] Pre-IETF meeting on P2P SIP in Vancouver > > > > (cross posted to sipping and the new P2P SIP list in case interested > > parties aren't subscribed yet...) > > > > At the P2P SIP informal BOF at IETF-63 in Paris, one item that came > > out of the meeting was the desire for another, longer meeting to try > > to discuss some of these topics. The general consensus was that we > > should try to meet just prior to the next IETF in Vancouver. > > > > I wanted to go ahead and start to organize/coordinate this. Can people > > please reply (either to me directly, or to the P2P SIP list -- try to > > keep the traffic on SIPPING down) to let me know if they are > > interested (head count), and any thoughts on structure for the > > meeting. > > > > Currently, I am thinking a good plan is the Sunday before IETF-64 (the > > 6th of November), likely a longer session (4 or 8 hours) somewhere in > > Vancouver that would be convenient for IETF attendees. Also, can > > people start sending me a list of topics they are interested in, so > > that I can start to organize an agenda of the topics people would like > > discussed? > > > > For those that may have missed the announcement or haven't yet joined > > the P2P list, but are interested in discussing this issue or any other > > P2P SIP issue, the URL for the new mailing list Henning put together > > (thank you Henning!) is here: > > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > I'm also assembling all the notes from the informal BOF and will put > > them up at p2psip.org. > > > > Thanks, and looking forward to moving forward on this! > > > > David Bryan > -- David Bryan Please continue to send me email at the address bryan@ethernot.org From mahfuz at research.panasonic.com Fri Aug 12 15:45:32 2005 From: mahfuz at research.panasonic.com (Mahfuzur Rahman) Date: Fri Aug 12 15:48:28 2005 Subject: [p2p-sip] Re: [Sipping] Pre-IETF meeting on P2P SIP in Vancouver References: <40qjma$34kg24@sj-inbound-e.cisco.com> <8b2769930508121238d9c3624@mail.gmail.com> Message-ID: <005901c59f76$666d17b0$6a01a996@MAHFUZT12K> It might be a good idea to look into other implementations of DHT such as tapestry, CAN etc. A presentation on these and their pros and cons interms of P2P SIP design would be helpful. -Mahfuz ----- Original Message ----- From: "David A. Bryan" To: "Cullen Jennings" Cc: "P2P-SIP" ; Sent: Friday, August 12, 2005 3:38 PM Subject: [p2p-sip] Re: [Sipping] Pre-IETF meeting on P2P SIP in Vancouver > Yes, I think a longer meeting is better. Several others have who have > responded have made similar comments -- leaves time for a number of > sessions. Henry already mentioned a number of important topics, and I > am sure more will come up, so having time to discuss as many as > possible makes good sense. > > David > > On 8/12/05, Cullen Jennings wrote: > > > > I plan to attend. > > > > An 7 hour block would really give time to make progress vs. just summarize > > things. > > > > > > On 8/12/05 9:15 AM, "Henry Sinnreich" wrote: > > > > > I plan to attend the meeting prior to the next IETF in Vancouver and would > > > like to add to the agenda: > > > > > > 1 - Choice of P2P protocols, such as Chord vs. DNS > > > See for example http://ag-projects.com/SIPThor.html > > > > > > 2 - The pros and cons of SIP UAs or SIP proxy/registrar being P2P members. > > > > > > 3 - Generic list of P2P system choices, such as the above. > > > > > > Thanks, Henry > > > > > > > > > > > > -----Original Message----- > > > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf > > > Of David A. Bryan > > > Sent: Friday, August 12, 2005 9:42 AM > > > To: p2p-sip@cs.columbia.edu; sipping@ietf.org > > > Cc: Bruce Lowekamp; Cullen Jennings; Henning Schulzrinne > > > Subject: [Sipping] Pre-IETF meeting on P2P SIP in Vancouver > > > > > > (cross posted to sipping and the new P2P SIP list in case interested > > > parties aren't subscribed yet...) > > > > > > At the P2P SIP informal BOF at IETF-63 in Paris, one item that came > > > out of the meeting was the desire for another, longer meeting to try > > > to discuss some of these topics. The general consensus was that we > > > should try to meet just prior to the next IETF in Vancouver. > > > > > > I wanted to go ahead and start to organize/coordinate this. Can people > > > please reply (either to me directly, or to the P2P SIP list -- try to > > > keep the traffic on SIPPING down) to let me know if they are > > > interested (head count), and any thoughts on structure for the > > > meeting. > > > > > > Currently, I am thinking a good plan is the Sunday before IETF-64 (the > > > 6th of November), likely a longer session (4 or 8 hours) somewhere in > > > Vancouver that would be convenient for IETF attendees. Also, can > > > people start sending me a list of topics they are interested in, so > > > that I can start to organize an agenda of the topics people would like > > > discussed? > > > > > > For those that may have missed the announcement or haven't yet joined > > > the P2P list, but are interested in discussing this issue or any other > > > P2P SIP issue, the URL for the new mailing list Henning put together > > > (thank you Henning!) is here: > > > > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > I'm also assembling all the notes from the informal BOF and will put > > > them up at p2psip.org. > > > > > > Thanks, and looking forward to moving forward on this! > > > > > > David Bryan > > > > > -- > David Bryan > Please continue to send me email at the address bryan@ethernot.org > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > From fluffy at cisco.com Fri Aug 12 16:02:49 2005 From: fluffy at cisco.com (Cullen Jennings) Date: Fri Aug 12 16:03:20 2005 Subject: [p2p-sip] Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer In-Reply-To: <07a101c59f78$a41c09c0$01000001@Brijesh2K> Message-ID: Can we please move this discussion off the sipping list and over to the p2p-sip list. If you reply to this, please remove sipping from the cc line. Thanks, Cullen On 8/12/05 1:01 PM, "Brijesh Kumar" wrote: > ----- Original Message ----- > From: "Philip Patrick" > >> I believe emergency services should be within the scope of P2P SIP. As a > network operator enabling VoIP SPs to become custom telephone companies, we > at Pac West Telecom endorse the FCC Order requiring VoIP SPs to support > Enhanced 911 service for nomadic VoIP users. And, in order for P2P VoIP to > become a ubiquitous means of communication, the routing of calls to the > correct >PSAP and rendering of location information for use by a 911 > dispatcher is essential. > > > Philips: > > P2P SIP need not be designed with operators in mind and hence there is no > requirements for supporting every thing that SIP does. > > As Dean pointed, and I fully concur that E911 and FCC are definitely out of > the scope for P2P SIP. > > Many people may want to use P2P SIP only for applications within the > enterprise, and that sure should keep both FCC and most operators out. And, > it also makes lawful interception out of scope and irrelevant for such > users. > > regards, > > --bk > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Fri 8/12/2005 11:48 AM >> To: Brijesh Kumar >> Cc: Cullen Jennings; sipping; Richard Shockey >> Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer >> >> >> >> >> On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: >> >>> I think Sohel raised some interesting issues - >>> specially 1,3, 4, and 5 that the group needs to >>> include in any discussion. Task model is very important >>> for further development of P2P SIP otherwise you >>> won't be able to deploy P2P SIP for real life >>> applications. >> >> Discussing the task model probably makes sense. Reliability, DoS >> resistance, and privacy are key elements of any IETF protocol work. I'm >> not certain about access to emergency services -- this may well be >> outside the scope of P2P. >> >> However, I find it extremely unlikely that IETF work on P2P using SIP >> will address or consider lawful intercept. >> >> There are already mechanisms available for lawful intercept in the >> Internet in general (such as RFC 3924). >> >> Consideration of lawful intercept as a protocol requirement is >> generally outside the scope of the IETF. This position is documented in >> RFC 2804, which has as a summary: >> >> The IETF has decided not to consider requirements for wiretapping as >> part of the process for creating and maintaining IETF standards. >> >> Personally, I believe that if P2P SIP mechanisms prove to be >> particularly sensitive to intercept, then we've failed to correctly >> specify those mechanisms. I feel that this is consistent with the >> intent of RFC 1984. >> >> -- >> Dean >> >> >> _______________________________________________ >> 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 From Richard.Stastny at oefeg.at Fri Aug 12 19:19:04 2005 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Fri Aug 12 19:16:50 2005 Subject: [p2p-sip] Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0B7@oefeg-s04.oefeg.loc> I have a basic question regarding SIP P2P: A. Does true P2P SIP involve a service provider at all? B. Isn't routing to emergency calls dealt with in ecrit? -richard ________________________________ Von: sipping-bounces@ietf.org im Auftrag von Henry Sinnreich Gesendet: Fr 12.08.2005 22:46 An: 'Philip Patrick'; 'Dean Willis'; 'Brijesh Kumar' Cc: 'Cullen Jennings'; 'sipping'; 'Richard Shockey' Betreff: RE: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer The support of emergency calling (such as 911) by operators of a P2P SIP based service depends one how the service is sold. 1- If the P2P based service is sold as a PSTN telephone service replacement (example: Vonage), emergency calling support is a MUST IMHO. 2- If the P2P service is sold as something else, such as presence, IM, apps, etc. (example: Reuters Messenger), emergency calling may not be required. 3- A P2P based IP PBX MUST support 911 as any analyst will tell you. The above will constitute a long game between regulators, carriers, IPSs, and enterprises and the outcome is not sure. The correct approach is to move 911-style emergency calling from the PSTN to the Internet as proposed in http://www.iptel.org/info/players/ietf/emergency/draft-schulzrinne-sipping-s os-04.txt and more at http://www.cs.columbia.edu/sip/emergency.html Thanks, Henry -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Philip Patrick Sent: Friday, August 12, 2005 2:12 PM To: Dean Willis; Brijesh Kumar Cc: Cullen Jennings; sipping; Richard Shockey Subject: RE: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer I believe emergency services should be within the scope of P2P SIP. As a network operator enabling VoIP SPs to become custom telephone companies, we at Pac West Telecom endorse the FCC Order requiring VoIP SPs to support Enhanced 911 service for nomadic VoIP users. And, in order for P2P VoIP to become a ubiquitous means of communication, the routing of calls to the correct PSAP and rendering of location information for use by a 911 dispatcher is essential. Phil -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Fri 8/12/2005 11:48 AM To: Brijesh Kumar Cc: Cullen Jennings; sipping; Richard Shockey Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > I think Sohel raised some interesting issues - > specially 1,3, 4, and 5 that the group needs to > include in any discussion. Task model is very important > for further development of P2P SIP otherwise you > won't be able to deploy P2P SIP for real life > applications. Discussing the task model probably makes sense. Reliability, DoS resistance, and privacy are key elements of any IETF protocol work. I'm not certain about access to emergency services -- this may well be outside the scope of P2P. However, I find it extremely unlikely that IETF work on P2P using SIP will address or consider lawful intercept. There are already mechanisms available for lawful intercept in the Internet in general (such as RFC 3924). Consideration of lawful intercept as a protocol requirement is generally outside the scope of the IETF. This position is documented in RFC 2804, which has as a summary: The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards. Personally, I believe that if P2P SIP mechanisms prove to be particularly sensitive to intercept, then we've failed to correctly specify those mechanisms. I feel that this is consistent with the intent of RFC 1984. -- Dean _______________________________________________ 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 From davidbryan at gmail.com Fri Aug 12 21:32:25 2005 From: davidbryan at gmail.com (David A. Bryan) Date: Fri Aug 12 21:32:48 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: <07a101c59f78$a41c09c0$01000001@Brijesh2K> References: <07a101c59f78$a41c09c0$01000001@Brijesh2K> Message-ID: <8b27699305081218327edcbcb6@mail.gmail.com> I think it is possible that people may want to use p2p as an alternate mechanism for connectivity in the case of an emergency, and that might be a legitimate use (i.e., a node can reach another node, but not a gateway for some reason, and uses another phone to forward the request and media or something like that), but that many P2P systems will not support full e911 type services and it certainly shouldn't be a requirement, since as some pointed out, these are likely to be used for ephemeral or ad-hoc networks. I guess I would tend to think that adding full e911 support is out of scope (and if we design it right to be SIP compatible, should be addressed by work currently being done in the IETF), but that it is conceivable that using P2P sip to help achieve e911 is a possible application, although likely not something that would be explicitly dealt with in the design of such a system. --David On 8/12/05, Brijesh Kumar wrote: > ----- Original Message ----- > From: "Philip Patrick" > > > I believe emergency services should be within the scope of P2P SIP. As a > network operator enabling VoIP SPs to become custom telephone companies, we > at Pac West Telecom endorse the FCC Order requiring VoIP SPs to support > Enhanced 911 service for nomadic VoIP users. And, in order for P2P VoIP to > become a ubiquitous means of communication, the routing of calls to the > correct >PSAP and rendering of location information for use by a 911 > dispatcher is essential. > > > Philips: > > P2P SIP need not be designed with operators in mind and hence there is no > requirements for supporting every thing that SIP does. > > As Dean pointed, and I fully concur that E911 and FCC are definitely out of > the scope for P2P SIP. > > Many people may want to use P2P SIP only for applications within the > enterprise, and that sure should keep both FCC and most operators out. And, > it also makes lawful interception out of scope and irrelevant for such > users. > > regards, > > --bk > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Fri 8/12/2005 11:48 AM > > To: Brijesh Kumar > > Cc: Cullen Jennings; sipping; Richard Shockey > > Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > > > > > > > > > On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > > > > > I think Sohel raised some interesting issues - > > > specially 1,3, 4, and 5 that the group needs to > > > include in any discussion. Task model is very important > > > for further development of P2P SIP otherwise you > > > won't be able to deploy P2P SIP for real life > > > applications. > > > > Discussing the task model probably makes sense. Reliability, DoS > > resistance, and privacy are key elements of any IETF protocol work. I'm > > not certain about access to emergency services -- this may well be > > outside the scope of P2P. > > > > However, I find it extremely unlikely that IETF work on P2P using SIP > > will address or consider lawful intercept. > > > > There are already mechanisms available for lawful intercept in the > > Internet in general (such as RFC 3924). > > > > Consideration of lawful intercept as a protocol requirement is > > generally outside the scope of the IETF. This position is documented in > > RFC 2804, which has as a summary: > > > > The IETF has decided not to consider requirements for wiretapping as > > part of the process for creating and maintaining IETF standards. > > > > Personally, I believe that if P2P SIP mechanisms prove to be > > particularly sensitive to intercept, then we've failed to correctly > > specify those mechanisms. I feel that this is consistent with the > > intent of RFC 1984. > > > > -- > > Dean > > > > > > _______________________________________________ > > 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 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 > -- David Bryan Please continue to send me email at the address bryan@ethernot.org From Richard.Stastny at oefeg.at Sat Aug 13 12:23:24 2005 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Sat Aug 13 12:20:20 2005 Subject: [p2p-sip] P2P and 911 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0B8@oefeg-s04.oefeg.loc> Ecrit is currently working on means to allow calls to be routed to emergency services from any device connected to the Internet directly. No service provider is needed, be it a "normal" one or e P2P "service provider" (whatever that means) The only requirement i could see for P2P clients to recognize emergency calls as such, e.g. recognizing 911, 112 and national emergency numbers. Routing calls to "gateways" to the PSTN is definetely out-of-scope, because this is a national matter anyway and you cannot expect all P2P systems to recogize all national systems. Hint: there is more out on other planets than E911 and selective routers. -richard ________________________________ Von: p2p-sip-bounces@cs.columbia.edu im Auftrag von David A. Bryan Gesendet: Sa 13.08.2005 03:32 An: Brijesh Kumar Cc: p2p-sip@cs.columbia.edu; Richard Shockey Betreff: [p2p-sip] P2P and 911 I think it is possible that people may want to use p2p as an alternate mechanism for connectivity in the case of an emergency, and that might be a legitimate use (i.e., a node can reach another node, but not a gateway for some reason, and uses another phone to forward the request and media or something like that), but that many P2P systems will not support full e911 type services and it certainly shouldn't be a requirement, since as some pointed out, these are likely to be used for ephemeral or ad-hoc networks. I guess I would tend to think that adding full e911 support is out of scope (and if we design it right to be SIP compatible, should be addressed by work currently being done in the IETF), but that it is conceivable that using P2P sip to help achieve e911 is a possible application, although likely not something that would be explicitly dealt with in the design of such a system. --David On 8/12/05, Brijesh Kumar wrote: > ----- Original Message ----- > From: "Philip Patrick" > > > I believe emergency services should be within the scope of P2P SIP. As a > network operator enabling VoIP SPs to become custom telephone companies, we > at Pac West Telecom endorse the FCC Order requiring VoIP SPs to support > Enhanced 911 service for nomadic VoIP users. And, in order for P2P VoIP to > become a ubiquitous means of communication, the routing of calls to the > correct >PSAP and rendering of location information for use by a 911 > dispatcher is essential. > > > Philips: > > P2P SIP need not be designed with operators in mind and hence there is no > requirements for supporting every thing that SIP does. > > As Dean pointed, and I fully concur that E911 and FCC are definitely out of > the scope for P2P SIP. > > Many people may want to use P2P SIP only for applications within the > enterprise, and that sure should keep both FCC and most operators out. And, > it also makes lawful interception out of scope and irrelevant for such > users. > > regards, > > --bk > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Fri 8/12/2005 11:48 AM > > To: Brijesh Kumar > > Cc: Cullen Jennings; sipping; Richard Shockey > > Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > > > > > > > > > On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > > > > > I think Sohel raised some interesting issues - > > > specially 1,3, 4, and 5 that the group needs to > > > include in any discussion. Task model is very important > > > for further development of P2P SIP otherwise you > > > won't be able to deploy P2P SIP for real life > > > applications. > > > > Discussing the task model probably makes sense. Reliability, DoS > > resistance, and privacy are key elements of any IETF protocol work. I'm > > not certain about access to emergency services -- this may well be > > outside the scope of P2P. > > > > However, I find it extremely unlikely that IETF work on P2P using SIP > > will address or consider lawful intercept. > > > > There are already mechanisms available for lawful intercept in the > > Internet in general (such as RFC 3924). > > > > Consideration of lawful intercept as a protocol requirement is > > generally outside the scope of the IETF. This position is documented in > > RFC 2804, which has as a summary: > > > > The IETF has decided not to consider requirements for wiretapping as > > part of the process for creating and maintaining IETF standards. > > > > Personally, I believe that if P2P SIP mechanisms prove to be > > particularly sensitive to intercept, then we've failed to correctly > > specify those mechanisms. I feel that this is consistent with the > > intent of RFC 1984. > > > > -- > > Dean > > > > > > _______________________________________________ > > 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 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 > -- David Bryan Please continue to send me email at the address bryan@ethernot.org _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From hannes.tschofenig at siemens.com Sun Aug 14 10:05:36 2005 From: hannes.tschofenig at siemens.com (Tschofenig, Hannes) Date: Sun Aug 14 10:06:02 2005 Subject: AW: [p2p-sip] P2P and 911 Message-ID: hi david, thanks for raising this issue. we investigated this issue in ecrit, as richard already pointed out. as with many other p2p related topics there is a question of what type of infrastructure is available. we think that there is a need to interact with a psap (since the whole purpose of the location based routing is to determine a psap that is responsible for a particular geographical region). what assumptions do you make regarding infrastructure support for a p2p system (in the 911 case)? btw, what is 'full e911 support'? ciao hannes ps: the ecrit requirements draft can be found at: http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01.txt i copied additional drafts relevant for ecrit to this page: http://www.ietf-ecrit.org > -----Urspr?ngliche Nachricht----- > Von: p2p-sip-bounces@cs.columbia.edu > [mailto:p2p-sip-bounces@cs.columbia.edu] Im Auftrag von David A. Bryan > Gesendet: Samstag, 13. August 2005 03:32 > An: Brijesh Kumar > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > Betreff: [p2p-sip] P2P and 911 > > > > > I think it is possible that people may want to use p2p as an alternate > mechanism for connectivity in the case of an emergency, and that might > be a legitimate use (i.e., a node can reach another node, but not a > gateway for some reason, and uses another phone to forward the request > and media or something like that), but that many P2P systems will not > support full e911 type services and it certainly shouldn't be a > requirement, since as some pointed out, these are likely to be used > for ephemeral or ad-hoc networks. > > I guess I would tend to think that adding full e911 support is out of > scope (and if we design it right to be SIP compatible, should be > addressed by work currently being done in the IETF), but that it is > conceivable that using P2P sip to help achieve e911 is a possible > application, although likely not something that would be explicitly > dealt with in the design of such a system. > > --David > > On 8/12/05, Brijesh Kumar wrote: > > ----- Original Message ----- > > From: "Philip Patrick" > > > > > I believe emergency services should be within the scope > of P2P SIP. As a > > network operator enabling VoIP SPs to become custom > telephone companies, we > > at Pac West Telecom endorse the FCC Order requiring VoIP > SPs to support > > Enhanced 911 service for nomadic VoIP users. And, in order > for P2P VoIP to > > become a ubiquitous means of communication, the routing of > calls to the > > correct >PSAP and rendering of location information for use by a 911 > > dispatcher is essential. > > > > > > Philips: > > > > P2P SIP need not be designed with operators in mind and > hence there is no > > requirements for supporting every thing that SIP does. > > > > As Dean pointed, and I fully concur that E911 and FCC are > definitely out of > > the scope for P2P SIP. > > > > Many people may want to use P2P SIP only for applications within the > > enterprise, and that sure should keep both FCC and most > operators out. And, > > it also makes lawful interception out of scope and > irrelevant for such > > users. > > > > regards, > > > > --bk > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Fri 8/12/2005 11:48 AM > > > To: Brijesh Kumar > > > Cc: Cullen Jennings; sipping; Richard Shockey > > > Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > > > > > > > > > > > > > > On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > > > > > > > I think Sohel raised some interesting issues - > > > > specially 1,3, 4, and 5 that the group needs to > > > > include in any discussion. Task model is very important > > > > for further development of P2P SIP otherwise you > > > > won't be able to deploy P2P SIP for real life > > > > applications. > > > > > > Discussing the task model probably makes sense. Reliability, DoS > > > resistance, and privacy are key elements of any IETF > protocol work. I'm > > > not certain about access to emergency services -- this may well be > > > outside the scope of P2P. > > > > > > However, I find it extremely unlikely that IETF work on > P2P using SIP > > > will address or consider lawful intercept. > > > > > > There are already mechanisms available for lawful intercept in the > > > Internet in general (such as RFC 3924). > > > > > > Consideration of lawful intercept as a protocol requirement is > > > generally outside the scope of the IETF. This position is > documented in > > > RFC 2804, which has as a summary: > > > > > > The IETF has decided not to consider requirements for > wiretapping as > > > part of the process for creating and maintaining IETF > standards. > > > > > > Personally, I believe that if P2P SIP mechanisms prove to be > > > particularly sensitive to intercept, then we've failed to > correctly > > > specify those mechanisms. I feel that this is consistent with the > > > intent of RFC 1984. > > > > > > -- > > > Dean > > > > > > > > > _______________________________________________ > > > 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 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 > > > > > -- > David Bryan > Please continue to send me email at the address bryan@ethernot.org > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > From davidbryan at gmail.com Sun Aug 14 14:17:34 2005 From: davidbryan at gmail.com (David A. Bryan) Date: Sun Aug 14 14:18:03 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: References: Message-ID: <8b27699305081411174e34cddf@mail.gmail.com> I am definitely not at all familar with the ecrit work, so I don't want to comment too much. I guess I was more or less saying that I feel we are really early in the discussion of what P2P SIP is, and what it is good for, and I wanted to resist the urges from opposite sides to say you must include 911 in all cases or that P2P SIP is orthoginal to discussions on 911. I think we still have lots to learn and discuss, even on things as basic as what we might try to do with this technology, before we can answer any questions like that, so I was just trying to keep discussion open. --David On 8/14/05, Tschofenig, Hannes wrote: > hi david, > > thanks for raising this issue. we investigated this issue in ecrit, as richard already pointed out. > > as with many other p2p related topics there is a question of what type of infrastructure is available. > we think that there is a need to interact with a psap (since the whole purpose of the location based routing is to determine a psap that is responsible for a particular geographical region). what assumptions do you make regarding infrastructure support for a p2p system (in the 911 case)? > > btw, what is 'full e911 support'? > > ciao > hannes > > ps: the ecrit requirements draft can be found at: > http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01.txt > > i copied additional drafts relevant for ecrit to this page: > http://www.ietf-ecrit.org > > > -----Urspr?ngliche Nachricht----- > > Von: p2p-sip-bounces@cs.columbia.edu > > [mailto:p2p-sip-bounces@cs.columbia.edu] Im Auftrag von David A. Bryan > > Gesendet: Samstag, 13. August 2005 03:32 > > An: Brijesh Kumar > > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > > Betreff: [p2p-sip] P2P and 911 > > > > > > > > > > I think it is possible that people may want to use p2p as an alternate > > mechanism for connectivity in the case of an emergency, and that might > > be a legitimate use (i.e., a node can reach another node, but not a > > gateway for some reason, and uses another phone to forward the request > > and media or something like that), but that many P2P systems will not > > support full e911 type services and it certainly shouldn't be a > > requirement, since as some pointed out, these are likely to be used > > for ephemeral or ad-hoc networks. > > > > I guess I would tend to think that adding full e911 support is out of > > scope (and if we design it right to be SIP compatible, should be > > addressed by work currently being done in the IETF), but that it is > > conceivable that using P2P sip to help achieve e911 is a possible > > application, although likely not something that would be explicitly > > dealt with in the design of such a system. > > > > --David > > > > On 8/12/05, Brijesh Kumar wrote: > > > ----- Original Message ----- > > > From: "Philip Patrick" > > > > > > > I believe emergency services should be within the scope > > of P2P SIP. As a > > > network operator enabling VoIP SPs to become custom > > telephone companies, we > > > at Pac West Telecom endorse the FCC Order requiring VoIP > > SPs to support > > > Enhanced 911 service for nomadic VoIP users. And, in order > > for P2P VoIP to > > > become a ubiquitous means of communication, the routing of > > calls to the > > > correct >PSAP and rendering of location information for use by a 911 > > > dispatcher is essential. > > > > > > > > > Philips: > > > > > > P2P SIP need not be designed with operators in mind and > > hence there is no > > > requirements for supporting every thing that SIP does. > > > > > > As Dean pointed, and I fully concur that E911 and FCC are > > definitely out of > > > the scope for P2P SIP. > > > > > > Many people may want to use P2P SIP only for applications within the > > > enterprise, and that sure should keep both FCC and most > > operators out. And, > > > it also makes lawful interception out of scope and > > irrelevant for such > > > users. > > > > > > regards, > > > > > > --bk > > > > > > > -----Original Message----- > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > Sent: Fri 8/12/2005 11:48 AM > > > > To: Brijesh Kumar > > > > Cc: Cullen Jennings; sipping; Richard Shockey > > > > Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > > > > > > > > > > > > > > > > > > > On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > > > > > > > > > I think Sohel raised some interesting issues - > > > > > specially 1,3, 4, and 5 that the group needs to > > > > > include in any discussion. Task model is very important > > > > > for further development of P2P SIP otherwise you > > > > > won't be able to deploy P2P SIP for real life > > > > > applications. > > > > > > > > Discussing the task model probably makes sense. Reliability, DoS > > > > resistance, and privacy are key elements of any IETF > > protocol work. I'm > > > > not certain about access to emergency services -- this may well be > > > > outside the scope of P2P. > > > > > > > > However, I find it extremely unlikely that IETF work on > > P2P using SIP > > > > will address or consider lawful intercept. > > > > > > > > There are already mechanisms available for lawful intercept in the > > > > Internet in general (such as RFC 3924). > > > > > > > > Consideration of lawful intercept as a protocol requirement is > > > > generally outside the scope of the IETF. This position is > > documented in > > > > RFC 2804, which has as a summary: > > > > > > > > The IETF has decided not to consider requirements for > > wiretapping as > > > > part of the process for creating and maintaining IETF > > standards. > > > > > > > > Personally, I believe that if P2P SIP mechanisms prove to be > > > > particularly sensitive to intercept, then we've failed to > > correctly > > > > specify those mechanisms. I feel that this is consistent with the > > > > intent of RFC 1984. > > > > > > > > -- > > > > Dean > > > > > > > > > > > > _______________________________________________ > > > > 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 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 > > > > > > > > > -- > > David Bryan > > Please continue to send me email at the address bryan@ethernot.org > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > -- David Bryan Please continue to send me email at the address bryan@ethernot.org From henry at pulver.com Mon Aug 15 18:14:20 2005 From: henry at pulver.com (Henry Sinnreich) Date: Mon Aug 15 21:01:49 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: <8b27699305081411174e34cddf@mail.gmail.com> Message-ID: <200508160101.j7G11Dsw018806@cs.columbia.edu> If we exclude 911-like emergency services from P2P SIP, than both service providers and enterprise networks are excluded IMHO. What is left? :-) Henry -----Original Message----- From: David A. Bryan [mailto:davidbryan@gmail.com] Sent: Sunday, August 14, 2005 1:18 PM To: Tschofenig, Hannes Cc: p2p-sip@cs.columbia.edu; Richard Shockey Subject: Re: [p2p-sip] P2P and 911 I am definitely not at all familar with the ecrit work, so I don't want to comment too much. I guess I was more or less saying that I feel we are really early in the discussion of what P2P SIP is, and what it is good for, and I wanted to resist the urges from opposite sides to say you must include 911 in all cases or that P2P SIP is orthoginal to discussions on 911. I think we still have lots to learn and discuss, even on things as basic as what we might try to do with this technology, before we can answer any questions like that, so I was just trying to keep discussion open. --David On 8/14/05, Tschofenig, Hannes wrote: > hi david, > > thanks for raising this issue. we investigated this issue in ecrit, as richard already pointed out. > > as with many other p2p related topics there is a question of what type of infrastructure is available. > we think that there is a need to interact with a psap (since the whole purpose of the location based routing is to determine a psap that is responsible for a particular geographical region). what assumptions do you make regarding infrastructure support for a p2p system (in the 911 case)? > > btw, what is 'full e911 support'? > > ciao > hannes > > ps: the ecrit requirements draft can be found at: > http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01. txt > > i copied additional drafts relevant for ecrit to this page: > http://www.ietf-ecrit.org > > > -----Urspr?ngliche Nachricht----- > > Von: p2p-sip-bounces@cs.columbia.edu > > [mailto:p2p-sip-bounces@cs.columbia.edu] Im Auftrag von David A. Bryan > > Gesendet: Samstag, 13. August 2005 03:32 > > An: Brijesh Kumar > > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > > Betreff: [p2p-sip] P2P and 911 > > > > > > > > > > I think it is possible that people may want to use p2p as an alternate > > mechanism for connectivity in the case of an emergency, and that might > > be a legitimate use (i.e., a node can reach another node, but not a > > gateway for some reason, and uses another phone to forward the request > > and media or something like that), but that many P2P systems will not > > support full e911 type services and it certainly shouldn't be a > > requirement, since as some pointed out, these are likely to be used > > for ephemeral or ad-hoc networks. > > > > I guess I would tend to think that adding full e911 support is out of > > scope (and if we design it right to be SIP compatible, should be > > addressed by work currently being done in the IETF), but that it is > > conceivable that using P2P sip to help achieve e911 is a possible > > application, although likely not something that would be explicitly > > dealt with in the design of such a system. > > > > --David > > > > On 8/12/05, Brijesh Kumar wrote: > > > ----- Original Message ----- > > > From: "Philip Patrick" > > > > > > > I believe emergency services should be within the scope > > of P2P SIP. As a > > > network operator enabling VoIP SPs to become custom > > telephone companies, we > > > at Pac West Telecom endorse the FCC Order requiring VoIP > > SPs to support > > > Enhanced 911 service for nomadic VoIP users. And, in order > > for P2P VoIP to > > > become a ubiquitous means of communication, the routing of > > calls to the > > > correct >PSAP and rendering of location information for use by a 911 > > > dispatcher is essential. > > > > > > > > > Philips: > > > > > > P2P SIP need not be designed with operators in mind and > > hence there is no > > > requirements for supporting every thing that SIP does. > > > > > > As Dean pointed, and I fully concur that E911 and FCC are > > definitely out of > > > the scope for P2P SIP. > > > > > > Many people may want to use P2P SIP only for applications within the > > > enterprise, and that sure should keep both FCC and most > > operators out. And, > > > it also makes lawful interception out of scope and > > irrelevant for such > > > users. > > > > > > regards, > > > > > > --bk > > > > > > > -----Original Message----- > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > Sent: Fri 8/12/2005 11:48 AM > > > > To: Brijesh Kumar > > > > Cc: Cullen Jennings; sipping; Richard Shockey > > > > Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > > > > > > > > > > > > > > > > > > > On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > > > > > > > > > I think Sohel raised some interesting issues - > > > > > specially 1,3, 4, and 5 that the group needs to > > > > > include in any discussion. Task model is very important > > > > > for further development of P2P SIP otherwise you > > > > > won't be able to deploy P2P SIP for real life > > > > > applications. > > > > > > > > Discussing the task model probably makes sense. Reliability, DoS > > > > resistance, and privacy are key elements of any IETF > > protocol work. I'm > > > > not certain about access to emergency services -- this may well be > > > > outside the scope of P2P. > > > > > > > > However, I find it extremely unlikely that IETF work on > > P2P using SIP > > > > will address or consider lawful intercept. > > > > > > > > There are already mechanisms available for lawful intercept in the > > > > Internet in general (such as RFC 3924). > > > > > > > > Consideration of lawful intercept as a protocol requirement is > > > > generally outside the scope of the IETF. This position is > > documented in > > > > RFC 2804, which has as a summary: > > > > > > > > The IETF has decided not to consider requirements for > > wiretapping as > > > > part of the process for creating and maintaining IETF > > standards. > > > > > > > > Personally, I believe that if P2P SIP mechanisms prove to be > > > > particularly sensitive to intercept, then we've failed to > > correctly > > > > specify those mechanisms. I feel that this is consistent with the > > > > intent of RFC 1984. > > > > > > > > -- > > > > Dean > > > > > > > > > > > > _______________________________________________ > > > > 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 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 > > > > > > > > > -- > > David Bryan > > Please continue to send me email at the address bryan@ethernot.org > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > -- David Bryan Please continue to send me email at the address bryan@ethernot.org From arjunrc at gmail.com Tue Aug 16 09:06:44 2005 From: arjunrc at gmail.com (Arjun Roychowdhury) Date: Tue Aug 16 09:07:09 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: <200508160101.j7G11Dsw018806@cs.columbia.edu> References: <8b27699305081411174e34cddf@mail.gmail.com> <200508160101.j7G11Dsw018806@cs.columbia.edu> Message-ID: This is actually a very interesting point. I personally support thinking about providing 911 services in P2P but before that, it may be worth concentrating on refining the underlying architecture that will make P2P work well on SIP. What do existing P2P providers do ? Here is one: http://www.skypejournal.com/blog/archives/2005/05/skype_911_and_g.php regds arjun On 8/15/05, Henry Sinnreich wrote: > If we exclude 911-like emergency services from P2P SIP, than both service > providers and enterprise networks are excluded IMHO. What is left? :-) > > Henry > > > > -----Original Message----- > From: David A. Bryan [mailto:davidbryan@gmail.com] > Sent: Sunday, August 14, 2005 1:18 PM > To: Tschofenig, Hannes > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > Subject: Re: [p2p-sip] P2P and 911 > > I am definitely not at all familar with the ecrit work, so I don't > want to comment too much. I guess I was more or less saying that I > feel we are really early in the discussion of what P2P SIP is, and > what it is good for, and I wanted to resist the urges from opposite > sides to say you must include 911 in all cases or that P2P SIP is > orthoginal to discussions on 911. I think we still have lots to learn > and discuss, even on things as basic as what we might try to do with > this technology, before we can answer any questions like that, so I > was just trying to keep discussion open. > > --David > > On 8/14/05, Tschofenig, Hannes wrote: > > hi david, > > > > thanks for raising this issue. we investigated this issue in ecrit, as > richard already pointed out. > > > > as with many other p2p related topics there is a question of what type of > infrastructure is available. > > we think that there is a need to interact with a psap (since the whole > purpose of the location based routing is to determine a psap that is > responsible for a particular geographical region). what assumptions do you > make regarding infrastructure support for a p2p system (in the 911 case)? > > > > btw, what is 'full e911 support'? > > > > ciao > > hannes > > > > ps: the ecrit requirements draft can be found at: > > > http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01. > txt > > > > i copied additional drafts relevant for ecrit to this page: > > http://www.ietf-ecrit.org > > > > > -----Urspr?ngliche Nachricht----- > > > Von: p2p-sip-bounces@cs.columbia.edu > > > [mailto:p2p-sip-bounces@cs.columbia.edu] Im Auftrag von David A. Bryan > > > Gesendet: Samstag, 13. August 2005 03:32 > > > An: Brijesh Kumar > > > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > > > Betreff: [p2p-sip] P2P and 911 > > > > > > > > > > > > > > > I think it is possible that people may want to use p2p as an alternate > > > mechanism for connectivity in the case of an emergency, and that might > > > be a legitimate use (i.e., a node can reach another node, but not a > > > gateway for some reason, and uses another phone to forward the request > > > and media or something like that), but that many P2P systems will not > > > support full e911 type services and it certainly shouldn't be a > > > requirement, since as some pointed out, these are likely to be used > > > for ephemeral or ad-hoc networks. > > > > > > I guess I would tend to think that adding full e911 support is out of > > > scope (and if we design it right to be SIP compatible, should be > > > addressed by work currently being done in the IETF), but that it is > > > conceivable that using P2P sip to help achieve e911 is a possible > > > application, although likely not something that would be explicitly > > > dealt with in the design of such a system. > > > > > > --David > > > > > > On 8/12/05, Brijesh Kumar wrote: > > > > ----- Original Message ----- > > > > From: "Philip Patrick" > > > > > > > > > I believe emergency services should be within the scope > > > of P2P SIP. As a > > > > network operator enabling VoIP SPs to become custom > > > telephone companies, we > > > > at Pac West Telecom endorse the FCC Order requiring VoIP > > > SPs to support > > > > Enhanced 911 service for nomadic VoIP users. And, in order > > > for P2P VoIP to > > > > become a ubiquitous means of communication, the routing of > > > calls to the > > > > correct >PSAP and rendering of location information for use by a 911 > > > > dispatcher is essential. > > > > > > > > > > > > Philips: > > > > > > > > P2P SIP need not be designed with operators in mind and > > > hence there is no > > > > requirements for supporting every thing that SIP does. > > > > > > > > As Dean pointed, and I fully concur that E911 and FCC are > > > definitely out of > > > > the scope for P2P SIP. > > > > > > > > Many people may want to use P2P SIP only for applications within the > > > > enterprise, and that sure should keep both FCC and most > > > operators out. And, > > > > it also makes lawful interception out of scope and > > > irrelevant for such > > > > users. > > > > > > > > regards, > > > > > > > > --bk > > > > > > > > > -----Original Message----- > > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > > Sent: Fri 8/12/2005 11:48 AM > > > > > To: Brijesh Kumar > > > > > Cc: Cullen Jennings; sipping; Richard Shockey > > > > > Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > > > > > > > > > > > I think Sohel raised some interesting issues - > > > > > > specially 1,3, 4, and 5 that the group needs to > > > > > > include in any discussion. Task model is very important > > > > > > for further development of P2P SIP otherwise you > > > > > > won't be able to deploy P2P SIP for real life > > > > > > applications. > > > > > > > > > > Discussing the task model probably makes sense. Reliability, DoS > > > > > resistance, and privacy are key elements of any IETF > > > protocol work. I'm > > > > > not certain about access to emergency services -- this may well be > > > > > outside the scope of P2P. > > > > > > > > > > However, I find it extremely unlikely that IETF work on > > > P2P using SIP > > > > > will address or consider lawful intercept. > > > > > > > > > > There are already mechanisms available for lawful intercept in the > > > > > Internet in general (such as RFC 3924). > > > > > > > > > > Consideration of lawful intercept as a protocol requirement is > > > > > generally outside the scope of the IETF. This position is > > > documented in > > > > > RFC 2804, which has as a summary: > > > > > > > > > > The IETF has decided not to consider requirements for > > > wiretapping as > > > > > part of the process for creating and maintaining IETF > > > standards. > > > > > > > > > > Personally, I believe that if P2P SIP mechanisms prove to be > > > > > particularly sensitive to intercept, then we've failed to > > > correctly > > > > > specify those mechanisms. I feel that this is consistent with the > > > > > intent of RFC 1984. > > > > > > > > > > -- > > > > > Dean > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 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 > > > > > > > > > > > > > -- > > > David Bryan > > > Please continue to send me email at the address bryan@ethernot.org > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > > > -- > David Bryan > Please continue to send me email at the address bryan@ethernot.org > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > -- Arjun Roychowdhury From dworley at pingtel.com Tue Aug 16 10:35:50 2005 From: dworley at pingtel.com (Dale Worley) Date: Tue Aug 16 10:38:29 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: Message-ID: <03bb01c5a26f$ccca80a0$6a01010a@keywest> It's rather tempting to suggest that P2P SIP doesn't need to have any sort of emergency facilities, but I suspect that is counterproductive. The ability of a device to summon emergency assistance is a benefit to the public, not just the person who owns the device. Certainly, if we want to get P2P SIP widely adopted, being able to say "It provides full support for 911" will be a significant aid. SIP is starting to play in the big leagues, and public impacts are starting to be important features. Dale From slavitch at gmail.com Tue Aug 16 11:17:28 2005 From: slavitch at gmail.com (Michael Slavitch) Date: Tue Aug 16 11:17:51 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: <03bb01c5a26f$ccca80a0$6a01010a@keywest> References: <03bb01c5a26f$ccca80a0$6a01010a@keywest> Message-ID: <1fc32c8f050816081741c4296e@mail.gmail.com> Do not forget looming regulatory requirements. Not being prepared in advance is only one way to lose the game to ancient yet well-understood technology. Every excuse in the book will be waged against SIP, from E911 to national security, by the existing players. A question to answer is this: While P2P SIP (or SIP in general) may have the ability to talk E911, it doesn't matter one whit if the local municipalities aren't capable of or willing to take 911 calls from a source that is not the PSTN. SIP-based E911 will have to respect and accept this. >Routing calls to "gateways" to the PSTN is definetely out-of-scope, because this is a national matter anyway and you cannot expect all P2P systems to recogize all national systems.< Not a good enough answer in the real world. On 16/08/05, Dale Worley wrote: > > It's rather tempting to suggest that P2P SIP doesn't need to have any sort > of emergency facilities, but I suspect that is counterproductive. The > ability of a device to summon emergency assistance is a benefit to the > public, not just the person who owns the device. Certainly, if we want to > get P2P SIP widely adopted, being able to say "It provides full support > for > 911" will be a significant aid. > > SIP is starting to play in the big leagues, and public impacts are > starting > to be important features. > > Dale > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20050816/ec17cffe/attachment-0001.html From henry at pulver.com Tue Aug 16 09:40:10 2005 From: henry at pulver.com (Henry Sinnreich) Date: Tue Aug 16 11:28:25 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: Message-ID: <200508161526.j7GFQpsw009663@cs.columbia.edu> Arjun, Yes, P2P networks like Skype provide 911, though not using SIP. Here is however a commercial SIP P2P network technology that has received too little attention, since a big advertising buget may be missing: http://www.intertex.se/index2.asp?iMenuID=347&iItemID=291 - It works very well (I have one), - You don't need a service provider and enterprise for a private and SIP standards compliant P2P SIP network. Including PSTN gateway service! P2P SIP compliant networks may however be soon used by enlightened service providers and enterprise networks. What we don't know at present is if/when new protocols need to be deployed or such as the existing will work just fine in many/most cases: http://ag-projects.com/SIPThor.html http://www.intertex.se/products/list.asp?iMenuID=110&t=33 This brings us back to the agenda on P2P SIP for the proposed pre-IETF meeting in November: - What are the options for designing P2P SIP networks? Thanks, Henry -----Original Message----- From: Arjun Roychowdhury [mailto:arjunrc@gmail.com] Sent: Tuesday, August 16, 2005 8:07 AM To: henry@pulver.com Cc: bryan@ethernot.org; Tschofenig, Hannes; p2p-sip@cs.columbia.edu; Richard Shockey Subject: Re: [p2p-sip] P2P and 911 This is actually a very interesting point. I personally support thinking about providing 911 services in P2P but before that, it may be worth concentrating on refining the underlying architecture that will make P2P work well on SIP. What do existing P2P providers do ? Here is one: http://www.skypejournal.com/blog/archives/2005/05/skype_911_and_g.php regds arjun On 8/15/05, Henry Sinnreich wrote: > If we exclude 911-like emergency services from P2P SIP, than both service > providers and enterprise networks are excluded IMHO. What is left? :-) > > Henry > > > > -----Original Message----- > From: David A. Bryan [mailto:davidbryan@gmail.com] > Sent: Sunday, August 14, 2005 1:18 PM > To: Tschofenig, Hannes > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > Subject: Re: [p2p-sip] P2P and 911 > > I am definitely not at all familar with the ecrit work, so I don't > want to comment too much. I guess I was more or less saying that I > feel we are really early in the discussion of what P2P SIP is, and > what it is good for, and I wanted to resist the urges from opposite > sides to say you must include 911 in all cases or that P2P SIP is > orthoginal to discussions on 911. I think we still have lots to learn > and discuss, even on things as basic as what we might try to do with > this technology, before we can answer any questions like that, so I > was just trying to keep discussion open. > > --David > > On 8/14/05, Tschofenig, Hannes wrote: > > hi david, > > > > thanks for raising this issue. we investigated this issue in ecrit, as > richard already pointed out. > > > > as with many other p2p related topics there is a question of what type of > infrastructure is available. > > we think that there is a need to interact with a psap (since the whole > purpose of the location based routing is to determine a psap that is > responsible for a particular geographical region). what assumptions do you > make regarding infrastructure support for a p2p system (in the 911 case)? > > > > btw, what is 'full e911 support'? > > > > ciao > > hannes > > > > ps: the ecrit requirements draft can be found at: > > > http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01. > txt > > > > i copied additional drafts relevant for ecrit to this page: > > http://www.ietf-ecrit.org > > > > > -----Urspr?ngliche Nachricht----- > > > Von: p2p-sip-bounces@cs.columbia.edu > > > [mailto:p2p-sip-bounces@cs.columbia.edu] Im Auftrag von David A. Bryan > > > Gesendet: Samstag, 13. August 2005 03:32 > > > An: Brijesh Kumar > > > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > > > Betreff: [p2p-sip] P2P and 911 > > > > > > > > > > > > > > > I think it is possible that people may want to use p2p as an alternate > > > mechanism for connectivity in the case of an emergency, and that might > > > be a legitimate use (i.e., a node can reach another node, but not a > > > gateway for some reason, and uses another phone to forward the request > > > and media or something like that), but that many P2P systems will not > > > support full e911 type services and it certainly shouldn't be a > > > requirement, since as some pointed out, these are likely to be used > > > for ephemeral or ad-hoc networks. > > > > > > I guess I would tend to think that adding full e911 support is out of > > > scope (and if we design it right to be SIP compatible, should be > > > addressed by work currently being done in the IETF), but that it is > > > conceivable that using P2P sip to help achieve e911 is a possible > > > application, although likely not something that would be explicitly > > > dealt with in the design of such a system. > > > > > > --David > > > > > > On 8/12/05, Brijesh Kumar wrote: > > > > ----- Original Message ----- > > > > From: "Philip Patrick" > > > > > > > > > I believe emergency services should be within the scope > > > of P2P SIP. As a > > > > network operator enabling VoIP SPs to become custom > > > telephone companies, we > > > > at Pac West Telecom endorse the FCC Order requiring VoIP > > > SPs to support > > > > Enhanced 911 service for nomadic VoIP users. And, in order > > > for P2P VoIP to > > > > become a ubiquitous means of communication, the routing of > > > calls to the > > > > correct >PSAP and rendering of location information for use by a 911 > > > > dispatcher is essential. > > > > > > > > > > > > Philips: > > > > > > > > P2P SIP need not be designed with operators in mind and > > > hence there is no > > > > requirements for supporting every thing that SIP does. > > > > > > > > As Dean pointed, and I fully concur that E911 and FCC are > > > definitely out of > > > > the scope for P2P SIP. > > > > > > > > Many people may want to use P2P SIP only for applications within the > > > > enterprise, and that sure should keep both FCC and most > > > operators out. And, > > > > it also makes lawful interception out of scope and > > > irrelevant for such > > > > users. > > > > > > > > regards, > > > > > > > > --bk > > > > > > > > > -----Original Message----- > > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > > Sent: Fri 8/12/2005 11:48 AM > > > > > To: Brijesh Kumar > > > > > Cc: Cullen Jennings; sipping; Richard Shockey > > > > > Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > > > > > > > > > > > I think Sohel raised some interesting issues - > > > > > > specially 1,3, 4, and 5 that the group needs to > > > > > > include in any discussion. Task model is very important > > > > > > for further development of P2P SIP otherwise you > > > > > > won't be able to deploy P2P SIP for real life > > > > > > applications. > > > > > > > > > > Discussing the task model probably makes sense. Reliability, DoS > > > > > resistance, and privacy are key elements of any IETF > > > protocol work. I'm > > > > > not certain about access to emergency services -- this may well be > > > > > outside the scope of P2P. > > > > > > > > > > However, I find it extremely unlikely that IETF work on > > > P2P using SIP > > > > > will address or consider lawful intercept. > > > > > > > > > > There are already mechanisms available for lawful intercept in the > > > > > Internet in general (such as RFC 3924). > > > > > > > > > > Consideration of lawful intercept as a protocol requirement is > > > > > generally outside the scope of the IETF. This position is > > > documented in > > > > > RFC 2804, which has as a summary: > > > > > > > > > > The IETF has decided not to consider requirements for > > > wiretapping as > > > > > part of the process for creating and maintaining IETF > > > standards. > > > > > > > > > > Personally, I believe that if P2P SIP mechanisms prove to be > > > > > particularly sensitive to intercept, then we've failed to > > > correctly > > > > > specify those mechanisms. I feel that this is consistent with the > > > > > intent of RFC 1984. > > > > > > > > > > -- > > > > > Dean > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 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 > > > > > > > > > > > > > -- > > > David Bryan > > > Please continue to send me email at the address bryan@ethernot.org > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > > > -- > David Bryan > Please continue to send me email at the address bryan@ethernot.org > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > -- Arjun Roychowdhury From dean.willis at softarmor.com Tue Aug 16 12:46:15 2005 From: dean.willis at softarmor.com (Dean Willis) Date: Tue Aug 16 12:46:49 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: <03bb01c5a26f$ccca80a0$6a01010a@keywest> References: <03bb01c5a26f$ccca80a0$6a01010a@keywest> Message-ID: On Aug 16, 2005, at 9:35 AM, Dale Worley wrote: > It's rather tempting to suggest that P2P SIP doesn't need to have any > sort > of emergency facilities, but I suspect that is counterproductive. The > ability of a device to summon emergency assistance is a benefit to the > public, not just the person who owns the device. Certainly, if we > want to > get P2P SIP widely adopted, being able to say "It provides full > support for > 911" will be a significant aid. > > SIP is starting to play in the big leagues, and public impacts are > starting > to be important features. > Regulation is all about liability, and answering the question "Who gets fined or imprisoned for failure to meet regulatory requirements?" The problem is that E911 regulatory requirements don't say useful things like "you must be able to make an emergency call" -- they say things like "the network service provided by an operator must allow end users to place emergency calls to existing PSAPs under contractual relationships between the PSAPs and the operator". The regulations are written under the assumption of operators providing centralized control of a service infrastructure and having localized relationships with PSAP providers. SIP, as deployed by a centralized service provider, will clearly have to meet E911 regulatory requirements in nation-states having those requirements, and the centralized service provider will face the liability of meeting those requirements. But P2P, by definition, lacks the concept of a centralized service provider who can be controlled by regulation and who can maintain contracts with PSAPs and nation-states. Similar conditions apply to CALEA, which requires that a minimum set of supervisory personnel at a service provider implement a surveillance order. How can a P2P system, which lacks both supervisory personnel and centralized access to the media path (remember, we use shortest-path end-to-end crypto) be consistent with CALEA? It can't -- and a surveillance order would therefore have to be served against the ISPs providing internet service to the end-points, not against the P2P system. So I think it's a very good idea to exclude consideration of emergency services and lawful intercept, in general, from the discussion of SIP P2P. -- Dean From ppatrick at pacwest.com Tue Aug 16 13:03:02 2005 From: ppatrick at pacwest.com (Philip Patrick) Date: Tue Aug 16 13:03:46 2005 Subject: [p2p-sip] P2P and 911 Message-ID: <73FAF24321CE9E419AD5747A215472730101BAEF@exchange.adpw.pacwest.com> >From a next gen network service provider perspective, I see potential for substantial cost reduction from P2P SIP-based technologies. I view P2P SIP networks as an alternative technology to deploy - in enterprises and service provider networks. As end devices get more and more powerful, P2P SIP-based technologies become a realistic deployment alternative to traditional, centralized softswitch technology. I would like this working group to please keep in mind that while a service provider is not needed for P2P SIP networks, it is quite likely that service providers will adopt this technology and deploy end devices supporting P2P SIP once a appropriate level of maturity is reached. -----Original Message----- From: Henry Sinnreich [mailto:henry@pulver.com] Sent: Tuesday, August 16, 2005 6:40 AM To: 'Arjun Roychowdhury' Cc: bryan@ethernot.org; 'Tschofenig, Hannes'; 'Richard Shockey'; 'Johnston,Alan'; p2p-sip@cs.columbia.edu; Karl Stahl Subject: RE: [p2p-sip] P2P and 911 Arjun, Yes, P2P networks like Skype provide 911, though not using SIP. Here is however a commercial SIP P2P network technology that has received too little attention, since a big advertising buget may be missing: http://www.intertex.se/index2.asp?iMenuID=347&iItemID=291 - It works very well (I have one), - You don't need a service provider and enterprise for a private and SIP standards compliant P2P SIP network. Including PSTN gateway service! P2P SIP compliant networks may however be soon used by enlightened service providers and enterprise networks. What we don't know at present is if/when new protocols need to be deployed or such as the existing will work just fine in many/most cases: http://ag-projects.com/SIPThor.html http://www.intertex.se/products/list.asp?iMenuID=110&t=33 This brings us back to the agenda on P2P SIP for the proposed pre-IETF meeting in November: - What are the options for designing P2P SIP networks? Thanks, Henry -----Original Message----- From: Arjun Roychowdhury [mailto:arjunrc@gmail.com] Sent: Tuesday, August 16, 2005 8:07 AM To: henry@pulver.com Cc: bryan@ethernot.org; Tschofenig, Hannes; p2p-sip@cs.columbia.edu; Richard Shockey Subject: Re: [p2p-sip] P2P and 911 This is actually a very interesting point. I personally support thinking about providing 911 services in P2P but before that, it may be worth concentrating on refining the underlying architecture that will make P2P work well on SIP. What do existing P2P providers do ? Here is one: http://www.skypejournal.com/blog/archives/2005/05/skype_911_and_g.php regds arjun On 8/15/05, Henry Sinnreich wrote: > If we exclude 911-like emergency services from P2P SIP, than both service > providers and enterprise networks are excluded IMHO. What is left? :-) > > Henry > > > > -----Original Message----- > From: David A. Bryan [mailto:davidbryan@gmail.com] > Sent: Sunday, August 14, 2005 1:18 PM > To: Tschofenig, Hannes > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > Subject: Re: [p2p-sip] P2P and 911 > > I am definitely not at all familar with the ecrit work, so I don't > want to comment too much. I guess I was more or less saying that I > feel we are really early in the discussion of what P2P SIP is, and > what it is good for, and I wanted to resist the urges from opposite > sides to say you must include 911 in all cases or that P2P SIP is > orthoginal to discussions on 911. I think we still have lots to learn > and discuss, even on things as basic as what we might try to do with > this technology, before we can answer any questions like that, so I > was just trying to keep discussion open. > > --David > > On 8/14/05, Tschofenig, Hannes wrote: > > hi david, > > > > thanks for raising this issue. we investigated this issue in ecrit, as > richard already pointed out. > > > > as with many other p2p related topics there is a question of what type of > infrastructure is available. > > we think that there is a need to interact with a psap (since the whole > purpose of the location based routing is to determine a psap that is > responsible for a particular geographical region). what assumptions do you > make regarding infrastructure support for a p2p system (in the 911 case)? > > > > btw, what is 'full e911 support'? > > > > ciao > > hannes > > > > ps: the ecrit requirements draft can be found at: > > > http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01. > txt > > > > i copied additional drafts relevant for ecrit to this page: > > http://www.ietf-ecrit.org > > > > > -----Urspr?ngliche Nachricht----- > > > Von: p2p-sip-bounces@cs.columbia.edu > > > [mailto:p2p-sip-bounces@cs.columbia.edu] Im Auftrag von David A. Bryan > > > Gesendet: Samstag, 13. August 2005 03:32 > > > An: Brijesh Kumar > > > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > > > Betreff: [p2p-sip] P2P and 911 > > > > > > > > > > > > > > > I think it is possible that people may want to use p2p as an alternate > > > mechanism for connectivity in the case of an emergency, and that might > > > be a legitimate use (i.e., a node can reach another node, but not a > > > gateway for some reason, and uses another phone to forward the request > > > and media or something like that), but that many P2P systems will not > > > support full e911 type services and it certainly shouldn't be a > > > requirement, since as some pointed out, these are likely to be used > > > for ephemeral or ad-hoc networks. > > > > > > I guess I would tend to think that adding full e911 support is out of > > > scope (and if we design it right to be SIP compatible, should be > > > addressed by work currently being done in the IETF), but that it is > > > conceivable that using P2P sip to help achieve e911 is a possible > > > application, although likely not something that would be explicitly > > > dealt with in the design of such a system. > > > > > > --David > > > > > > On 8/12/05, Brijesh Kumar wrote: > > > > ----- Original Message ----- > > > > From: "Philip Patrick" > > > > > > > > > I believe emergency services should be within the scope > > > of P2P SIP. As a > > > > network operator enabling VoIP SPs to become custom > > > telephone companies, we > > > > at Pac West Telecom endorse the FCC Order requiring VoIP > > > SPs to support > > > > Enhanced 911 service for nomadic VoIP users. And, in order > > > for P2P VoIP to > > > > become a ubiquitous means of communication, the routing of > > > calls to the > > > > correct >PSAP and rendering of location information for use by a 911 > > > > dispatcher is essential. > > > > > > > > > > > > Philips: > > > > > > > > P2P SIP need not be designed with operators in mind and > > > hence there is no > > > > requirements for supporting every thing that SIP does. > > > > > > > > As Dean pointed, and I fully concur that E911 and FCC are > > > definitely out of > > > > the scope for P2P SIP. > > > > > > > > Many people may want to use P2P SIP only for applications within the > > > > enterprise, and that sure should keep both FCC and most > > > operators out. And, > > > > it also makes lawful interception out of scope and > > > irrelevant for such > > > > users. > > > > > > > > regards, > > > > > > > > --bk > > > > > > > > > -----Original Message----- > > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > > Sent: Fri 8/12/2005 11:48 AM > > > > > To: Brijesh Kumar > > > > > Cc: Cullen Jennings; sipping; Richard Shockey > > > > > Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP peer-to-peer > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > > > > > > > > > > > I think Sohel raised some interesting issues - > > > > > > specially 1,3, 4, and 5 that the group needs to > > > > > > include in any discussion. Task model is very important > > > > > > for further development of P2P SIP otherwise you > > > > > > won't be able to deploy P2P SIP for real life > > > > > > applications. > > > > > > > > > > Discussing the task model probably makes sense. Reliability, DoS > > > > > resistance, and privacy are key elements of any IETF > > > protocol work. I'm > > > > > not certain about access to emergency services -- this may well be > > > > > outside the scope of P2P. > > > > > > > > > > However, I find it extremely unlikely that IETF work on > > > P2P using SIP > > > > > will address or consider lawful intercept. > > > > > > > > > > There are already mechanisms available for lawful intercept in the > > > > > Internet in general (such as RFC 3924). > > > > > > > > > > Consideration of lawful intercept as a protocol requirement is > > > > > generally outside the scope of the IETF. This position is > > > documented in > > > > > RFC 2804, which has as a summary: > > > > > > > > > > The IETF has decided not to consider requirements for > > > wiretapping as > > > > > part of the process for creating and maintaining IETF > > > standards. > > > > > > > > > > Personally, I believe that if P2P SIP mechanisms prove to be > > > > > particularly sensitive to intercept, then we've failed to > > > correctly > > > > > specify those mechanisms. I feel that this is consistent with the > > > > > intent of RFC 1984. > > > > > > > > > > -- > > > > > Dean > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 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 > > > > > > > > > > > > > -- > > > David Bryan > > > Please continue to send me email at the address bryan@ethernot.org > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > > > -- > David Bryan > Please continue to send me email at the address bryan@ethernot.org > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > -- Arjun Roychowdhury _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From slavitch at gmail.com Tue Aug 16 13:20:03 2005 From: slavitch at gmail.com (Michael Slavitch) Date: Tue Aug 16 13:20:36 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: <73FAF24321CE9E419AD5747A215472730101BAEF@exchange.adpw.pacwest.com> References: <73FAF24321CE9E419AD5747A215472730101BAEF@exchange.adpw.pacwest.com> Message-ID: <1fc32c8f050816102044143fb7@mail.gmail.com> Another question for the sip P2P group to answer is "what is a peer"? Is a peer a uninary scalar user agent for one individual or is it a proxy frontend for a more complex system that represents many subgroups and individuals? For example, P2P systems such as Skype are just fine for consumers and individuals, but once you get into organizations how does P2P work? How do I get a P2P system to navigate to, say, tech support or legal or accounts receivable, or other groups within complex ever-changing organizations? How do you handle advertise such organizational structure to others within peer-to-peer systems? If that is ignored then what results is an interesting scalar consumer system, which is a great shame. On 16/08/05, Philip Patrick wrote: > > >From a next gen network service provider perspective, I see potential for > substantial cost reduction from P2P SIP-based technologies. I view P2P SIP > networks as an alternative technology to deploy - in enterprises and service > provider networks. As end devices get more and more powerful, P2P SIP-based > technologies become a realistic deployment alternative to traditional, > centralized softswitch technology. I would like this working group to please > keep in mind that while a service provider is not needed for P2P SIP > networks, it is quite likely that service providers will adopt this > technology and deploy end devices supporting P2P SIP once a appropriate > level of maturity is reached. > > > -----Original Message----- > From: Henry Sinnreich [mailto:henry@pulver.com] > Sent: Tuesday, August 16, 2005 6:40 AM > To: 'Arjun Roychowdhury' > Cc: bryan@ethernot.org; 'Tschofenig, Hannes'; 'Richard Shockey'; > 'Johnston,Alan'; p2p-sip@cs.columbia.edu; Karl Stahl > Subject: RE: [p2p-sip] P2P and 911 > > > Arjun, > > Yes, P2P networks like Skype provide 911, though not using SIP. > > Here is however a commercial SIP P2P network technology that has received > too little attention, since a big advertising buget may be missing: > http://www.intertex.se/index2.asp?iMenuID=347&iItemID=291 > > - It works very well (I have one), > - You don't need a service provider and enterprise for a private and SIP > standards compliant P2P SIP network. Including PSTN gateway service! > > P2P SIP compliant networks may however be soon used by enlightened service > providers and enterprise networks. What we don't know at present is > if/when > new protocols need to be deployed or such as the existing will work just > fine in many/most cases: > > http://ag-projects.com/SIPThor.html > http://www.intertex.se/products/list.asp?iMenuID=110&t=33 > > This brings us back to the agenda on P2P SIP for the proposed pre-IETF > meeting in November: > > - What are the options for designing P2P SIP networks? > > Thanks, Henry > > -----Original Message----- > From: Arjun Roychowdhury [mailto:arjunrc@gmail.com] > Sent: Tuesday, August 16, 2005 8:07 AM > To: henry@pulver.com > Cc: bryan@ethernot.org; Tschofenig, Hannes; p2p-sip@cs.columbia.edu; > Richard > Shockey > Subject: Re: [p2p-sip] P2P and 911 > > This is actually a very interesting point. I personally support > thinking about providing 911 services in P2P but before that, it may > be worth concentrating on refining the underlying architecture that > will make P2P work well on SIP. > > What do existing P2P providers do ? Here is one: > http://www.skypejournal.com/blog/archives/2005/05/skype_911_and_g.php > > regds > arjun > > > On 8/15/05, Henry Sinnreich wrote: > > If we exclude 911-like emergency services from P2P SIP, than both > service > > providers and enterprise networks are excluded IMHO. What is left? :-) > > > > Henry > > > > > > > > -----Original Message----- > > From: David A. Bryan [mailto:davidbryan@gmail.com] > > Sent: Sunday, August 14, 2005 1:18 PM > > To: Tschofenig, Hannes > > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > > Subject: Re: [p2p-sip] P2P and 911 > > > > I am definitely not at all familar with the ecrit work, so I don't > > want to comment too much. I guess I was more or less saying that I > > feel we are really early in the discussion of what P2P SIP is, and > > what it is good for, and I wanted to resist the urges from opposite > > sides to say you must include 911 in all cases or that P2P SIP is > > orthoginal to discussions on 911. I think we still have lots to learn > > and discuss, even on things as basic as what we might try to do with > > this technology, before we can answer any questions like that, so I > > was just trying to keep discussion open. > > > > --David > > > > On 8/14/05, Tschofenig, Hannes wrote: > > > hi david, > > > > > > thanks for raising this issue. we investigated this issue in ecrit, as > > richard already pointed out. > > > > > > as with many other p2p related topics there is a question of what type > of > > infrastructure is available. > > > we think that there is a need to interact with a psap (since the whole > > purpose of the location based routing is to determine a psap that is > > responsible for a particular geographical region). what assumptions do > you > > make regarding infrastructure support for a p2p system (in the 911 > case)? > > > > > > btw, what is 'full e911 support'? > > > > > > ciao > > > hannes > > > > > > ps: the ecrit requirements draft can be found at: > > > > > > > http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01 > . > > txt > > > > > > i copied additional drafts relevant for ecrit to this page: > > > http://www.ietf-ecrit.org > > > > > > > -----Urspr?ngliche Nachricht----- > > > > Von: p2p-sip-bounces@cs.columbia.edu > > > > [mailto:p2p-sip-bounces@cs.columbia.edu] Im Auftrag von David A. > Bryan > > > > Gesendet: Samstag, 13. August 2005 03:32 > > > > An: Brijesh Kumar > > > > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > > > > Betreff: [p2p-sip] P2P and 911 > > > > > > > > > > > > > > > > > > > > I think it is possible that people may want to use p2p as an > alternate > > > > mechanism for connectivity in the case of an emergency, and that > might > > > > be a legitimate use (i.e., a node can reach another node, but not a > > > > gateway for some reason, and uses another phone to forward the > request > > > > and media or something like that), but that many P2P systems will > not > > > > support full e911 type services and it certainly shouldn't be a > > > > requirement, since as some pointed out, these are likely to be used > > > > for ephemeral or ad-hoc networks. > > > > > > > > I guess I would tend to think that adding full e911 support is out > of > > > > scope (and if we design it right to be SIP compatible, should be > > > > addressed by work currently being done in the IETF), but that it is > > > > conceivable that using P2P sip to help achieve e911 is a possible > > > > application, although likely not something that would be explicitly > > > > dealt with in the design of such a system. > > > > > > > > --David > > > > > > > > On 8/12/05, Brijesh Kumar wrote: > > > > > ----- Original Message ----- > > > > > From: "Philip Patrick" > > > > > > > > > > > I believe emergency services should be within the scope > > > > of P2P SIP. As a > > > > > network operator enabling VoIP SPs to become custom > > > > telephone companies, we > > > > > at Pac West Telecom endorse the FCC Order requiring VoIP > > > > SPs to support > > > > > Enhanced 911 service for nomadic VoIP users. And, in order > > > > for P2P VoIP to > > > > > become a ubiquitous means of communication, the routing of > > > > calls to the > > > > > correct >PSAP and rendering of location information for use by a > 911 > > > > > dispatcher is essential. > > > > > > > > > > > > > > > Philips: > > > > > > > > > > P2P SIP need not be designed with operators in mind and > > > > hence there is no > > > > > requirements for supporting every thing that SIP does. > > > > > > > > > > As Dean pointed, and I fully concur that E911 and FCC are > > > > definitely out of > > > > > the scope for P2P SIP. > > > > > > > > > > Many people may want to use P2P SIP only for applications within > the > > > > > enterprise, and that sure should keep both FCC and most > > > > operators out. And, > > > > > it also makes lawful interception out of scope and > > > > irrelevant for such > > > > > users. > > > > > > > > > > regards, > > > > > > > > > > --bk > > > > > > > > > > > -----Original Message----- > > > > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > > > Sent: Fri 8/12/2005 11:48 AM > > > > > > To: Brijesh Kumar > > > > > > Cc: Cullen Jennings; sipping; Richard Shockey > > > > > > Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP > peer-to-peer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > > > > > > > > > > > > > I think Sohel raised some interesting issues - > > > > > > > specially 1,3, 4, and 5 that the group needs to > > > > > > > include in any discussion. Task model is very important > > > > > > > for further development of P2P SIP otherwise you > > > > > > > won't be able to deploy P2P SIP for real life > > > > > > > applications. > > > > > > > > > > > > Discussing the task model probably makes sense. Reliability, DoS > > > > > > resistance, and privacy are key elements of any IETF > > > > protocol work. I'm > > > > > > not certain about access to emergency services -- this may well > be > > > > > > outside the scope of P2P. > > > > > > > > > > > > However, I find it extremely unlikely that IETF work on > > > > P2P using SIP > > > > > > will address or consider lawful intercept. > > > > > > > > > > > > There are already mechanisms available for lawful intercept in > the > > > > > > Internet in general (such as RFC 3924). > > > > > > > > > > > > Consideration of lawful intercept as a protocol requirement is > > > > > > generally outside the scope of the IETF. This position is > > > > documented in > > > > > > RFC 2804, which has as a summary: > > > > > > > > > > > > The IETF has decided not to consider requirements for > > > > wiretapping as > > > > > > part of the process for creating and maintaining IETF > > > > standards. > > > > > > > > > > > > Personally, I believe that if P2P SIP mechanisms prove to be > > > > > > particularly sensitive to intercept, then we've failed to > > > > correctly > > > > > > specify those mechanisms. I feel that this is consistent with > the > > > > > > intent of RFC 1984. > > > > > > > > > > > > -- > > > > > > Dean > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 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 > > > > > > > > > > > > > > > > > -- > > > > David Bryan > > > > Please continue to send me email at the address bryan@ethernot.org > > > > > > > > _______________________________________________ > > > > p2p-sip mailing list > > > > p2p-sip@cs.columbia.edu > > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > > > > > > > > -- > > David Bryan > > Please continue to send me email at the address bryan@ethernot.org > > > > > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > -- > Arjun Roychowdhury > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20050816/38da205f/attachment-0001.html From davidbryan at gmail.com Tue Aug 16 13:29:58 2005 From: davidbryan at gmail.com (David A. Bryan) Date: Tue Aug 16 13:30:22 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: <1fc32c8f050816102044143fb7@mail.gmail.com> References: <73FAF24321CE9E419AD5747A215472730101BAEF@exchange.adpw.pacwest.com> <1fc32c8f050816102044143fb7@mail.gmail.com> Message-ID: <8b27699305081610297de32361@mail.gmail.com> I definitely am also interested in discussing what peers are. The scenarios you mention sound interesting. I particularly am interested in both the notion of having proxies that are P2P enabled (I talk about the idea of "adapter nodes" in my draft, which I know Henning has also discussed, and which is kind of along those lines), and also using P2P technology to handle back end clustering (think about normal client/server, but a farm of servers on the back end connected to each other P2P -- possibly for replication/reliability/redundancy reasons). --David On 8/16/05, Michael Slavitch wrote: > Another question for the sip P2P group to answer is "what is a peer"? Is a > peer a uninary scalar user agent for one individual or is it a proxy > frontend for a more complex system that represents many subgroups and > individuals? > > For example, P2P systems such as Skype are just fine for consumers and > individuals, but once you get into organizations how does P2P work? How do > I get a P2P system to navigate to, say, tech support or legal or accounts > receivable, or other groups within complex ever-changing organizations? How > do you handle advertise such organizational structure to others within > peer-to-peer systems? > > If that is ignored then what results is an interesting scalar consumer > system, which is a great shame. > > > > On 16/08/05, Philip Patrick wrote: > > > > >From a next gen network service provider perspective, I see potential for > substantial cost reduction from P2P SIP-based technologies. I view P2P SIP > networks as an alternative technology to deploy - in enterprises and service > provider networks. As end devices get more and more powerful, P2P SIP-based > technologies become a realistic deployment alternative to traditional, > centralized softswitch technology. I would like this working group to > please keep in mind that while a service provider is not needed for P2P SIP > networks, it is quite likely that service providers will adopt this > technology and deploy end devices supporting P2P SIP once a appropriate > level of maturity is reached. > > > > > > -----Original Message----- > > From: Henry Sinnreich [mailto:henry@pulver.com] > > Sent: Tuesday, August 16, 2005 6:40 AM > > To: 'Arjun Roychowdhury' > > Cc: bryan@ethernot.org; 'Tschofenig, Hannes'; 'Richard Shockey'; > > 'Johnston,Alan'; p2p-sip@cs.columbia.edu ; Karl Stahl > > Subject: RE: [p2p-sip] P2P and 911 > > > > > > Arjun, > > > > Yes, P2P networks like Skype provide 911, though not using SIP. > > > > Here is however a commercial SIP P2P network technology that has received > > too little attention, since a big advertising buget may be missing: > > http://www.intertex.se/index2.asp?iMenuID=347&iItemID=291 > > > > - It works very well (I have one), > > - You don't need a service provider and enterprise for a private and SIP > > standards compliant P2P SIP network. Including PSTN gateway service! > > > > P2P SIP compliant networks may however be soon used by enlightened service > > providers and enterprise networks. What we don't know at present is > if/when > > new protocols need to be deployed or such as the existing will work just > > fine in many/most cases: > > > > http://ag-projects.com/SIPThor.html > > http://www.intertex.se/products/list.asp?iMenuID=110&t=33 > > > > This brings us back to the agenda on P2P SIP for the proposed pre-IETF > > meeting in November: > > > > - What are the options for designing P2P SIP networks? > > > > Thanks, Henry > > > > -----Original Message----- > > From: Arjun Roychowdhury [mailto:arjunrc@gmail.com ] > > Sent: Tuesday, August 16, 2005 8:07 AM > > To: henry@pulver.com > > Cc: bryan@ethernot.org; Tschofenig, Hannes; p2p-sip@cs.columbia.edu; > Richard > > Shockey > > Subject: Re: [p2p-sip] P2P and 911 > > > > This is actually a very interesting point. I personally support > > thinking about providing 911 services in P2P but before that, it may > > be worth concentrating on refining the underlying architecture that > > will make P2P work well on SIP. > > > > What do existing P2P providers do ? Here is one: > > > http://www.skypejournal.com/blog/archives/2005/05/skype_911_and_g.php > > > > regds > > arjun > > > > > > On 8/15/05, Henry Sinnreich wrote: > > > If we exclude 911-like emergency services from P2P SIP, than both > service > > > providers and enterprise networks are excluded IMHO. What is left? :-) > > > > > > Henry > > > > > > > > > > > > -----Original Message----- > > > From: David A. Bryan [mailto: davidbryan@gmail.com] > > > Sent: Sunday, August 14, 2005 1:18 PM > > > To: Tschofenig, Hannes > > > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > > > Subject: Re: [p2p-sip] P2P and 911 > > > > > > I am definitely not at all familar with the ecrit work, so I don't > > > want to comment too much. I guess I was more or less saying that I > > > feel we are really early in the discussion of what P2P SIP is, and > > > what it is good for, and I wanted to resist the urges from opposite > > > sides to say you must include 911 in all cases or that P2P SIP is > > > orthoginal to discussions on 911. I think we still have lots to learn > > > and discuss, even on things as basic as what we might try to do with > > > this technology, before we can answer any questions like that, so I > > > was just trying to keep discussion open. > > > > > > --David > > > > > > On 8/14/05, Tschofenig, Hannes wrote: > > > > hi david, > > > > > > > > thanks for raising this issue. we investigated this issue in ecrit, as > > > richard already pointed out. > > > > > > > > as with many other p2p related topics there is a question of what type > > of > > > infrastructure is available. > > > > we think that there is a need to interact with a psap (since the whole > > > purpose of the location based routing is to determine a psap that is > > > responsible for a particular geographical region). what assumptions do > you > > > make regarding infrastructure support for a p2p system (in the 911 > case)? > > > > > > > > btw, what is 'full e911 support'? > > > > > > > > ciao > > > > hannes > > > > > > > > ps: the ecrit requirements draft can be found at: > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01. > > > txt > > > > > > > > i copied additional drafts relevant for ecrit to this page: > > > > http://www.ietf-ecrit.org > > > > > > > > > -----Urspr?ngliche Nachricht----- > > > > > Von: p2p-sip-bounces@cs.columbia.edu > > > > > [mailto: p2p-sip-bounces@cs.columbia.edu] Im Auftrag von David A. > Bryan > > > > > Gesendet: Samstag, 13. August 2005 03:32 > > > > > An: Brijesh Kumar > > > > > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > > > > > Betreff: [p2p-sip] P2P and 911 > > > > > > > > > > > > > > > > > > > > > > > > > I think it is possible that people may want to use p2p as an > alternate > > > > > mechanism for connectivity in the case of an emergency, and that > might > > > > > be a legitimate use ( i.e., a node can reach another node, but not a > > > > > gateway for some reason, and uses another phone to forward the > request > > > > > and media or something like that), but that many P2P systems will > not > > > > > support full e911 type services and it certainly shouldn't be a > > > > > requirement, since as some pointed out, these are likely to be used > > > > > for ephemeral or ad-hoc networks. > > > > > > > > > > I guess I would tend to think that adding full e911 support is out > of > > > > > scope (and if we design it right to be SIP compatible, should be > > > > > addressed by work currently being done in the IETF), but that it is > > > > > conceivable that using P2P sip to help achieve e911 is a possible > > > > > application, although likely not something that would be explicitly > > > > > dealt with in the design of such a system. > > > > > > > > > > --David > > > > > > > > > > On 8/12/05, Brijesh Kumar wrote: > > > > > > ----- Original Message ----- > > > > > > From: "Philip Patrick" > > > > > > > > > > > > > I believe emergency services should be within the scope > > > > > of P2P SIP. As a > > > > > > network operator enabling VoIP SPs to become custom > > > > > telephone companies, we > > > > > > at Pac West Telecom endorse the FCC Order requiring VoIP > > > > > SPs to support > > > > > > Enhanced 911 service for nomadic VoIP users. And, in order > > > > > for P2P VoIP to > > > > > > become a ubiquitous means of communication, the routing of > > > > > calls to the > > > > > > correct >PSAP and rendering of location information for use by a > 911 > > > > > > dispatcher is essential. > > > > > > > > > > > > > > > > > > Philips: > > > > > > > > > > > > P2P SIP need not be designed with operators in mind and > > > > > hence there is no > > > > > > requirements for supporting every thing that SIP does. > > > > > > > > > > > > As Dean pointed, and I fully concur that E911 and FCC are > > > > > definitely out of > > > > > > the scope for P2P SIP. > > > > > > > > > > > > Many people may want to use P2P SIP only for applications within > the > > > > > > enterprise, and that sure should keep both FCC and most > > > > > operators out. And, > > > > > > it also makes lawful interception out of scope and > > > > > irrelevant for such > > > > > > users. > > > > > > > > > > > > regards, > > > > > > > > > > > > --bk > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dean Willis [mailto: dean.willis@softarmor.com] > > > > > > > Sent: Fri 8/12/2005 11:48 AM > > > > > > > To: Brijesh Kumar > > > > > > > Cc: Cullen Jennings; sipping; Richard Shockey > > > > > > > Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP > peer-to-peer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > > > > > > > > > > > > > > > I think Sohel raised some interesting issues - > > > > > > > > specially 1,3, 4, and 5 that the group needs to > > > > > > > > include in any discussion. Task model is very important > > > > > > > > for further development of P2P SIP otherwise you > > > > > > > > won't be able to deploy P2P SIP for real life > > > > > > > > applications. > > > > > > > > > > > > > > Discussing the task model probably makes sense. Reliability, DoS > > > > > > > resistance, and privacy are key elements of any IETF > > > > > protocol work. I'm > > > > > > > not certain about access to emergency services -- this may well > be > > > > > > > outside the scope of P2P. > > > > > > > > > > > > > > However, I find it extremely unlikely that IETF work on > > > > > P2P using SIP > > > > > > > will address or consider lawful intercept. > > > > > > > > > > > > > > There are already mechanisms available for lawful intercept in > the > > > > > > > Internet in general (such as RFC 3924). > > > > > > > > > > > > > > Consideration of lawful intercept as a protocol requirement is > > > > > > > generally outside the scope of the IETF. This position is > > > > > documented in > > > > > > > RFC 2804, which has as a summary: > > > > > > > > > > > > > > The IETF has decided not to consider requirements for > > > > > wiretapping as > > > > > > > part of the process for creating and maintaining IETF > > > > > standards. > > > > > > > > > > > > > > Personally, I believe that if P2P SIP mechanisms prove to be > > > > > > > particularly sensitive to intercept, then we've failed to > > > > > correctly > > > > > > > specify those mechanisms. I feel that this is consistent with > the > > > > > > > intent of RFC 1984. > > > > > > > > > > > > > > -- > > > > > > > Dean > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 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 > > > > > > > > > > > > > > > > > > > > > -- > > > > > David Bryan > > > > > Please continue to send me email at the address bryan@ethernot.org > > > > > > > > > > _______________________________________________ > > > > > p2p-sip mailing list > > > > > p2p-sip@cs.columbia.edu > > > > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > > > > > > > > > > > > > -- > > > David Bryan > > > Please continue to send me email at the address bryan@ethernot.org > > > > > > > > > > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > > > > -- > > Arjun Roychowdhury > > > > > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > -- > > Michael Slavitch > Ottawa, Ontario Canada > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > -- David Bryan Please continue to send me email at the address bryan@ethernot.org From slavitch at gmail.com Tue Aug 16 13:48:24 2005 From: slavitch at gmail.com (Michael Slavitch) Date: Tue Aug 16 13:48:48 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: <8b27699305081610297de32361@mail.gmail.com> References: <73FAF24321CE9E419AD5747A215472730101BAEF@exchange.adpw.pacwest.com> <1fc32c8f050816102044143fb7@mail.gmail.com> <8b27699305081610297de32361@mail.gmail.com> Message-ID: <1fc32c8f05081610485102c5f9@mail.gmail.com> Yes indeed this is where things get interesting, because P2P, as it stands now, is "unstructured individual communicating to another unstructured individual" in every aspect. It works fine in the individual to individual world of file swapping and for individuals doing toll bypass, but it assumes the world is but a drop of water populated by single-celled organisms who occasionally need to connect to one another. But, if it was "Complicated organism A communicating to Complicated organism B, each ever changing its spots and being able to self-advertise fins, then over time claws and eventually fingers and toes" and things get far more interesting. Other implications, as you suggest, just naturally happen. A form of hyper-redundancy can take hold using a peer-to-peer model similar to what Google has done by turning thousands of individual cpus into a supercomputer. In such cases specific issues such as E911 connectivity become just specialized functions of peer organisms providing such a service, be they a carrier or a municipality or even, say, a free consortium. Still a peer, only a rather complex one. If we're going to replace a steam-engine era technology we can't replace old steam engines with new ones. On 16/08/05, David A. Bryan wrote: > > I definitely am also interested in discussing what peers are. The > scenarios you mention sound interesting. > > I particularly am interested in both the notion of having proxies that > are P2P enabled (I talk about the idea of "adapter nodes" in my draft, > which I know Henning has also discussed, and which is kind of along > those lines), and also using P2P technology to handle back end > clustering (think about normal client/server, but a farm of servers on > the back end connected to each other P2P -- possibly for > replication/reliability/redundancy reasons). > > --David > > On 8/16/05, Michael Slavitch wrote: > > Another question for the sip P2P group to answer is "what is a peer"? Is > a > > peer a uninary scalar user agent for one individual or is it a proxy > > frontend for a more complex system that represents many subgroups and > > individuals? > > > > For example, P2P systems such as Skype are just fine for consumers and > > individuals, but once you get into organizations how does P2P work? How > do > > I get a P2P system to navigate to, say, tech support or legal or > accounts > > receivable, or other groups within complex ever-changing organizations? > How > > do you handle advertise such organizational structure to others within > > peer-to-peer systems? > > > > If that is ignored then what results is an interesting scalar consumer > > system, which is a great shame. > > > > > > > > On 16/08/05, Philip Patrick wrote: > > > > > > >From a next gen network service provider perspective, I see potential > for > > substantial cost reduction from P2P SIP-based technologies. I view P2P > SIP > > networks as an alternative technology to deploy - in enterprises and > service > > provider networks. As end devices get more and more powerful, P2P > SIP-based > > technologies become a realistic deployment alternative to traditional, > > centralized softswitch technology. I would like this working group to > > please keep in mind that while a service provider is not needed for P2P > SIP > > networks, it is quite likely that service providers will adopt this > > technology and deploy end devices supporting P2P SIP once a appropriate > > level of maturity is reached. > > > > > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:henry@pulver.com] > > > Sent: Tuesday, August 16, 2005 6:40 AM > > > To: 'Arjun Roychowdhury' > > > Cc: bryan@ethernot.org; 'Tschofenig, Hannes'; 'Richard Shockey'; > > > 'Johnston,Alan'; p2p-sip@cs.columbia.edu ; Karl Stahl > > > Subject: RE: [p2p-sip] P2P and 911 > > > > > > > > > Arjun, > > > > > > Yes, P2P networks like Skype provide 911, though not using SIP. > > > > > > Here is however a commercial SIP P2P network technology that has > received > > > too little attention, since a big advertising buget may be missing: > > > http://www.intertex.se/index2.asp?iMenuID=347&iItemID=291 > > > > > > - It works very well (I have one), > > > - You don't need a service provider and enterprise for a private and > SIP > > > standards compliant P2P SIP network. Including PSTN gateway service! > > > > > > P2P SIP compliant networks may however be soon used by enlightened > service > > > providers and enterprise networks. What we don't know at present is > > if/when > > > new protocols need to be deployed or such as the existing will work > just > > > fine in many/most cases: > > > > > > http://ag-projects.com/SIPThor.html > > > http://www.intertex.se/products/list.asp?iMenuID=110&t=33 > > > > > > This brings us back to the agenda on P2P SIP for the proposed pre-IETF > > > meeting in November: > > > > > > - What are the options for designing P2P SIP networks? > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: Arjun Roychowdhury [mailto:arjunrc@gmail.com ] > > > Sent: Tuesday, August 16, 2005 8:07 AM > > > To: henry@pulver.com > > > Cc: bryan@ethernot.org; Tschofenig, Hannes; p2p-sip@cs.columbia.edu; > > Richard > > > Shockey > > > Subject: Re: [p2p-sip] P2P and 911 > > > > > > This is actually a very interesting point. I personally support > > > thinking about providing 911 services in P2P but before that, it may > > > be worth concentrating on refining the underlying architecture that > > > will make P2P work well on SIP. > > > > > > What do existing P2P providers do ? Here is one: > > > > > http://www.skypejournal.com/blog/archives/2005/05/skype_911_and_g.php > > > > > > regds > > > arjun > > > > > > > > > On 8/15/05, Henry Sinnreich wrote: > > > > If we exclude 911-like emergency services from P2P SIP, than both > > service > > > > providers and enterprise networks are excluded IMHO. What is left? > :-) > > > > > > > > Henry > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: David A. Bryan [mailto: davidbryan@gmail.com] > > > > Sent: Sunday, August 14, 2005 1:18 PM > > > > To: Tschofenig, Hannes > > > > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > > > > Subject: Re: [p2p-sip] P2P and 911 > > > > > > > > I am definitely not at all familar with the ecrit work, so I don't > > > > want to comment too much. I guess I was more or less saying that I > > > > feel we are really early in the discussion of what P2P SIP is, and > > > > what it is good for, and I wanted to resist the urges from opposite > > > > sides to say you must include 911 in all cases or that P2P SIP is > > > > orthoginal to discussions on 911. I think we still have lots to > learn > > > > and discuss, even on things as basic as what we might try to do with > > > > this technology, before we can answer any questions like that, so I > > > > was just trying to keep discussion open. > > > > > > > > --David > > > > > > > > On 8/14/05, Tschofenig, Hannes > wrote: > > > > > hi david, > > > > > > > > > > thanks for raising this issue. we investigated this issue in > ecrit, as > > > > richard already pointed out. > > > > > > > > > > as with many other p2p related topics there is a question of what > type > > > of > > > > infrastructure is available. > > > > > we think that there is a need to interact with a psap (since the > whole > > > > purpose of the location based routing is to determine a psap that is > > > > responsible for a particular geographical region). what assumptions > do > > you > > > > make regarding infrastructure support for a p2p system (in the 911 > > case)? > > > > > > > > > > btw, what is 'full e911 support'? > > > > > > > > > > ciao > > > > > hannes > > > > > > > > > > ps: the ecrit requirements draft can be found at: > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01 > . > > > > txt > > > > > > > > > > i copied additional drafts relevant for ecrit to this page: > > > > > http://www.ietf-ecrit.org > > > > > > > > > > > -----Urspr?ngliche Nachricht----- > > > > > > Von: p2p-sip-bounces@cs.columbia.edu > > > > > > [mailto: p2p-sip-bounces@cs.columbia.edu] Im Auftrag von David > A. > > Bryan > > > > > > Gesendet: Samstag, 13. August 2005 03:32 > > > > > > An: Brijesh Kumar > > > > > > Cc: p2p-sip@cs.columbia.edu; Richard Shockey > > > > > > Betreff: [p2p-sip] P2P and 911 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think it is possible that people may want to use p2p as an > > alternate > > > > > > mechanism for connectivity in the case of an emergency, and that > > might > > > > > > be a legitimate use ( i.e., a node can reach another node, but > not a > > > > > > gateway for some reason, and uses another phone to forward the > > request > > > > > > and media or something like that), but that many P2P systems > will > > not > > > > > > support full e911 type services and it certainly shouldn't be a > > > > > > requirement, since as some pointed out, these are likely to be > used > > > > > > for ephemeral or ad-hoc networks. > > > > > > > > > > > > I guess I would tend to think that adding full e911 support is > out > > of > > > > > > scope (and if we design it right to be SIP compatible, should be > > > > > > addressed by work currently being done in the IETF), but that it > is > > > > > > conceivable that using P2P sip to help achieve e911 is a > possible > > > > > > application, although likely not something that would be > explicitly > > > > > > dealt with in the design of such a system. > > > > > > > > > > > > --David > > > > > > > > > > > > On 8/12/05, Brijesh Kumar wrote: > > > > > > > ----- Original Message ----- > > > > > > > From: "Philip Patrick" > > > > > > > > > > > > > > > I believe emergency services should be within the scope > > > > > > of P2P SIP. As a > > > > > > > network operator enabling VoIP SPs to become custom > > > > > > telephone companies, we > > > > > > > at Pac West Telecom endorse the FCC Order requiring VoIP > > > > > > SPs to support > > > > > > > Enhanced 911 service for nomadic VoIP users. And, in order > > > > > > for P2P VoIP to > > > > > > > become a ubiquitous means of communication, the routing of > > > > > > calls to the > > > > > > > correct >PSAP and rendering of location information for use by > a > > 911 > > > > > > > dispatcher is essential. > > > > > > > > > > > > > > > > > > > > > Philips: > > > > > > > > > > > > > > P2P SIP need not be designed with operators in mind and > > > > > > hence there is no > > > > > > > requirements for supporting every thing that SIP does. > > > > > > > > > > > > > > As Dean pointed, and I fully concur that E911 and FCC are > > > > > > definitely out of > > > > > > > the scope for P2P SIP. > > > > > > > > > > > > > > Many people may want to use P2P SIP only for applications > within > > the > > > > > > > enterprise, and that sure should keep both FCC and most > > > > > > operators out. And, > > > > > > > it also makes lawful interception out of scope and > > > > > > irrelevant for such > > > > > > > users. > > > > > > > > > > > > > > regards, > > > > > > > > > > > > > > --bk > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dean Willis [mailto: dean.willis@softarmor.com] > > > > > > > > Sent: Fri 8/12/2005 11:48 AM > > > > > > > > To: Brijesh Kumar > > > > > > > > Cc: Cullen Jennings; sipping; Richard Shockey > > > > > > > > Subject: Re: [Sipping] Draft Notes from Ad-hoc on SIP > > peer-to-peer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 12, 2005, at 11:30 AM, Brijesh Kumar wrote: > > > > > > > > > > > > > > > > > I think Sohel raised some interesting issues - > > > > > > > > > specially 1,3, 4, and 5 that the group needs to > > > > > > > > > include in any discussion. Task model is very important > > > > > > > > > for further development of P2P SIP otherwise you > > > > > > > > > won't be able to deploy P2P SIP for real life > > > > > > > > > applications. > > > > > > > > > > > > > > > > Discussing the task model probably makes sense. Reliability, > DoS > > > > > > > > resistance, and privacy are key elements of any IETF > > > > > > protocol work. I'm > > > > > > > > not certain about access to emergency services -- this may > well > > be > > > > > > > > outside the scope of P2P. > > > > > > > > > > > > > > > > However, I find it extremely unlikely that IETF work on > > > > > > P2P using SIP > > > > > > > > will address or consider lawful intercept. > > > > > > > > > > > > > > > > There are already mechanisms available for lawful intercept > in > > the > > > > > > > > Internet in general (such as RFC 3924). > > > > > > > > > > > > > > > > Consideration of lawful intercept as a protocol requirement > is > > > > > > > > generally outside the scope of the IETF. This position is > > > > > > documented in > > > > > > > > RFC 2804, which has as a summary: > > > > > > > > > > > > > > > > The IETF has decided not to consider requirements for > > > > > > wiretapping as > > > > > > > > part of the process for creating and maintaining IETF > > > > > > standards. > > > > > > > > > > > > > > > > Personally, I believe that if P2P SIP mechanisms prove to be > > > > > > > > particularly sensitive to intercept, then we've failed to > > > > > > correctly > > > > > > > > specify those mechanisms. I feel that this is consistent > with > > the > > > > > > > > intent of RFC 1984. > > > > > > > > > > > > > > > > -- > > > > > > > > Dean > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 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 > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > David Bryan > > > > > > Please continue to send me email at the address > bryan@ethernot.org > > > > > > > > > > > > _______________________________________________ > > > > > > p2p-sip mailing list > > > > > > p2p-sip@cs.columbia.edu > > > > > > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > > > > > > > > > > > > > > > > > > -- > > > > David Bryan > > > > Please continue to send me email at the address bryan@ethernot.org > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > p2p-sip mailing list > > > > p2p-sip@cs.columbia.edu > > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > > > > > > > > -- > > > Arjun Roychowdhury > > > > > > > > > > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > > > > > > -- > > > > Michael Slavitch > > Ottawa, Ontario Canada > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > > > > -- > David Bryan > Please continue to send me email at the address bryan@ethernot.org > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20050816/48b0c791/attachment-0001.html From erik at sipthat.com Tue Aug 16 14:17:41 2005 From: erik at sipthat.com (Erik Lagerway) Date: Tue Aug 16 14:17:59 2005 Subject: [p2p-sip] P2P and 911 Message-ID: <21105935-1124216240-cardhu_blackberry.rim.net-14329-@engine08-cell06> I agree with Dean for the most part, although I am sure some of us are wondering how one using P2P SIP, on a mobile device for instance, will make a 911 call. Even if the response is "via an interconect to a traditional SIP network" we might want to work it through a bit. - Erik Erik Lagerway erik@sipthat.com ph.604.562.VoIP [8647] Sent from my Blackberry From ppatrick at pacwest.com Tue Aug 16 14:32:00 2005 From: ppatrick at pacwest.com (Philip Patrick) Date: Tue Aug 16 14:32:30 2005 Subject: [p2p-sip] P2P and 911 Message-ID: <73FAF24321CE9E419AD5747A215472730101BAF0@exchange.adpw.pacwest.com> I agree with Dale, I couldn't disagree more with Dean. Emergency services are one of the best things telecommunications has to offer society. Take emergency services away and you suffer in the realm of public opinion and ultimately serious deployment. Service providers and equipment suppliers are already investigating P2P SIP as a replacement technology, so it is important to distinguish P2P from P2P SIP which more and more centralized service providers will definitely closely consider deploying. Many PSAPs will remain in the PSTN world for years and existing contracts and trunking to ILECS and PSAPs will remain. Specialized P2P SIP end devices deployed by a service provider will need to be able to operate in both worlds and technical feasibility is there. Network equipment designed to send multiple RTP streams to support CALEA can be expected as well. Phil -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, August 16, 2005 9:46 AM To: Dale Worley Cc: p2p-sip@cs.columbia.edu Subject: Re: [p2p-sip] P2P and 911 On Aug 16, 2005, at 9:35 AM, Dale Worley wrote: > It's rather tempting to suggest that P2P SIP doesn't need to have any > sort > of emergency facilities, but I suspect that is counterproductive. The > ability of a device to summon emergency assistance is a benefit to the > public, not just the person who owns the device. Certainly, if we > want to > get P2P SIP widely adopted, being able to say "It provides full > support for > 911" will be a significant aid. > > SIP is starting to play in the big leagues, and public impacts are > starting > to be important features. > Regulation is all about liability, and answering the question "Who gets fined or imprisoned for failure to meet regulatory requirements?" The problem is that E911 regulatory requirements don't say useful things like "you must be able to make an emergency call" -- they say things like "the network service provided by an operator must allow end users to place emergency calls to existing PSAPs under contractual relationships between the PSAPs and the operator". The regulations are written under the assumption of operators providing centralized control of a service infrastructure and having localized relationships with PSAP providers. SIP, as deployed by a centralized service provider, will clearly have to meet E911 regulatory requirements in nation-states having those requirements, and the centralized service provider will face the liability of meeting those requirements. But P2P, by definition, lacks the concept of a centralized service provider who can be controlled by regulation and who can maintain contracts with PSAPs and nation-states. Similar conditions apply to CALEA, which requires that a minimum set of supervisory personnel at a service provider implement a surveillance order. How can a P2P system, which lacks both supervisory personnel and centralized access to the media path (remember, we use shortest-path end-to-end crypto) be consistent with CALEA? It can't -- and a surveillance order would therefore have to be served against the ISPs providing internet service to the end-points, not against the P2P system. So I think it's a very good idea to exclude consideration of emergency services and lawful intercept, in general, from the discussion of SIP P2P. -- Dean _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From jh at tutpro.com Wed Aug 17 08:27:17 2005 From: jh at tutpro.com (Juha Heinanen) Date: Wed Aug 17 08:27:53 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: <1fc32c8f050816081741c4296e@mail.gmail.com> References: <03bb01c5a26f$ccca80a0$6a01010a@keywest> <1fc32c8f050816081741c4296e@mail.gmail.com> Message-ID: <17155.11557.244559.813603@rautu.tutpro.com> Michael Slavitch writes: > Do not forget looming regulatory requirements. emergency call related regulatory requirements apply to service providers, not to individuals using end-to-end p2p applications. it may still be useful to be able to make emergency call using a p2p sip application, but in order to do that, emergency center needs to support this application or there needs to be a b2b ua somewhere in the network that does the protocol translation. -- juha From hannes.tschofenig at siemens.com Wed Aug 17 09:22:37 2005 From: hannes.tschofenig at siemens.com (Tschofenig, Hannes) Date: Wed Aug 17 09:23:17 2005 Subject: [p2p-sip] P2P and 911 (again) Message-ID: hi all, in ecrit working group we spoke about the impact of p2p on emergency handling. there are a few issues to consider: 1) the end host is able to use a mapping protocol to locate the psap. the uri of the psap is determined based on the location of the end host. 2) the location must be available to the end host. various means can provide you location information, such as gps, dhcp extensions, manual configuration, etc. as such, it is necessary that the following infrastucture is available: a) psaps (and the emergency staff) b) a distributed database (location -> psap uri) that can be queried by the mapping protocol c) protocols / protocol extensions to delivery location information to the end host is required (unless you assume that everyone is able to obtain location information by other means) (a) and (b) are always required (regardless whether you use p2p or not). with (a) you need to consider that end host contact the psaps directly rather than indirectly via sip proxies. with (b) the difference is only that the mapping protocol is initiated by the end host (rather than a sip proxy or so). someone has to setup and maintain this infrastructure (=cost issue). this is probably the most difficult part of the game but certainly not a protocol question. now, one might argue that it is not really p2p because infrastructure support is required. ciao hannes From jh at tutpro.com Wed Aug 17 09:37:15 2005 From: jh at tutpro.com (Juha Heinanen) Date: Wed Aug 17 09:38:24 2005 Subject: [p2p-sip] P2P and 911 (again) In-Reply-To: References: Message-ID: <17155.15755.942210.722717@rautu.tutpro.com> Tschofenig, Hannes writes: > 1) the end host is able to use a mapping protocol to locate the psap. > the uri of the psap is determined based on the location of the end > host. if p2p sip client is in gsm/3g device, it could calculate its own location provided that it knows coordinates of available gsm/3g base stations. i once suggested to authorities in finland that every mobile operator is mandated to publish coordinates of their base stations on the internet. this was rejected due to desire of mobile operators to hide such information. this is yet another example of the walled garden philosophy of mobile operators. they don't want to give control to intelligent p2p end devices. perhaps fcc in the u.s., if, as they claim, take emergency calling seriously, could publish such ruling as an example to european regulators. if not, the only conclusion one can make, is that all this fuzz about emergency calling is nothing but joke and in the end the only thing that really matters is commercial interests of walled garden operators. -- juha From dworley at pingtel.com Wed Aug 17 11:53:01 2005 From: dworley at pingtel.com (Dale Worley) Date: Wed Aug 17 11:55:44 2005 Subject: [p2p-sip] P2P and 911 In-Reply-To: Message-ID: <044001c5a343$c02df1e0$6a01010a@keywest> > From: Dean Willis [mailto:dean.willis@softarmor.com] > > But P2P, by definition, lacks the concept of a centralized service > provider who can be controlled by regulation and who can maintain > contracts with PSAPs and nation-states. This is very true, but I think that the implications are more subtle than they first appear. I think that a more careful consideration leads toward what the proper "attitude" should be in regard to P2P SIP and Emergency Services. Regulation comes in many flavors, and one should not be blinkered by assuming that all regulation must be of the PSTN variety, a massive contract between centralized service providers and the government. As an alternative, in US Citizens' Band radio, the users are required to purchase commercially-made transmitters, and the manufacturers are required to meet a long list of technical requirements. The Citizens' Band also has a frequency reserved for emergency services. But the operation of CB is highly P2P. US Amateur radio is operated similarly, but the operators must meet some fairly strict licensing requirements, and in return are allowed to build and adjust their own equipment. Even in US PSTN, some regulatory requirements are placed on the users, not service providers -- users must only attach telephones that have been certified by the FCC. In practice, these regulations work with minimal policing because the expense of meeting them is relatively low and commercial sellers of radios/telephones are exposed to some responsibility to not sell non-licensed equipment. In regard to P2P, if we desire it to be seen sociologically as "telephony" rather than just a toy for teenagers like AIM, P2P will have to support reasonable emergency services. It is outside the scope of the IETF to arrange for the regulatory structure, but it is inside the scope of the IETF to ensure that the protocols permit implementations of emergency services that are capable of being organized by suitable regulatory structures. (Being aware that the regulatory structure might be substantially different from the current one.) We can take advantage of the fact that 99.9% of the users will be using packaged applications (commercial or not), so there is a natural point for application of a regulatory requirement to support certain emergency services functions. We also have the advantage that P2P SIP is likely be very inexpensive, and so there will likely be no need for a chargeback-and-subsidy system to pay for the infrastructure, which would make everything more difficult. The biggest task is likely to be having a way to mark emergency communications so as to disable any intermediate service provider's accounting restrictions (and ensuring that users can't exploit such marking to cheat). Of course, the incumbent service providers will use emergency services support as a lever to try to inhibit the use of P2P and other economical SIP services, but if we (the broader SIP community) have well-thought-out proposals that address the public's concerns, that shouldn't be too difficult to overcome, only time-consuming. In regard to supporting CALEA, any sort of technological support would be much more difficult, and people's philosophical objections will be more intense. But conveniently, law enforcement already does intercepting at the IP layer with the cooperation of ISPs, and it seems to me that we can argue quite honestly that no further CALEA support is needed in P2P SIP. Dale From Richard.Stastny at oefeg.at Wed Aug 17 18:10:02 2005 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Wed Aug 17 18:07:43 2005 Subject: [p2p-sip] P2P and 911 (again) Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0CD@oefeg-s04.oefeg.loc> Juha, you are at the point. Emergency services in future requires the provision of location information to the end-users device by the access providers as an obligation. there will be no obligations anymore to the application service providers, because in this case the device may access the PSAP directly. A gsm/3g provider is nothing else than just an access provider like a DSL or cable provider, a WiFi hot spot or WiMAX. This message has to be conveyed to the regulators, especially in Europe. so the whole discussion if p2p provider have to provide access to emergency services is needless, they will not be they one haveing obligations -richard ________________________________ Von: p2p-sip-bounces@cs.columbia.edu im Auftrag von Juha Heinanen Gesendet: Mi 17.08.2005 15:37 An: Tschofenig, Hannes Cc: p2p-sip@cs.columbia.edu Betreff: [p2p-sip] P2P and 911 (again) Tschofenig, Hannes writes: > 1) the end host is able to use a mapping protocol to locate the psap. > the uri of the psap is determined based on the location of the end > host. if p2p sip client is in gsm/3g device, it could calculate its own location provided that it knows coordinates of available gsm/3g base stations. i once suggested to authorities in finland that every mobile operator is mandated to publish coordinates of their base stations on the internet. this was rejected due to desire of mobile operators to hide such information. this is yet another example of the walled garden philosophy of mobile operators. they don't want to give control to intelligent p2p end devices. perhaps fcc in the u.s., if, as they claim, take emergency calling seriously, could publish such ruling as an example to european regulators. if not, the only conclusion one can make, is that all this fuzz about emergency calling is nothing but joke and in the end the only thing that really matters is commercial interests of walled garden operators. -- juha _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From ppatrick at pacwest.com Wed Aug 17 18:30:09 2005 From: ppatrick at pacwest.com (Philip Patrick) Date: Wed Aug 17 18:30:55 2005 Subject: [p2p-sip] P2P and 911 (again) Message-ID: <73FAF24321CE9E419AD5747A21547273011A85D4@exchange.adpw.pacwest.com> Richard, Remember that many PSAPs will continue with POTS service for some time perhaps for long time depending on their funding. During the interim, the p2p provider needs to provide a means of locating the appropriate PSAP and routing P2P VoIP 911 calls to the PSAP via the PSTN. So P2P provider access to emergency services will likely be a real issue and for how long no one knows. Phil -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, August 17, 2005 3:10 PM To: Juha Heinanen; Tschofenig, Hannes Cc: p2p-sip@cs.columbia.edu Subject: Re: [p2p-sip] P2P and 911 (again) Juha, you are at the point. Emergency services in future requires the provision of location information to the end-users device by the access providers as an obligation. there will be no obligations anymore to the application service providers, because in this case the device may access the PSAP directly. A gsm/3g provider is nothing else than just an access provider like a DSL or cable provider, a WiFi hot spot or WiMAX. This message has to be conveyed to the regulators, especially in Europe. so the whole discussion if p2p provider have to provide access to emergency services is needless, they will not be they one haveing obligations -richard ________________________________ Von: p2p-sip-bounces@cs.columbia.edu im Auftrag von Juha Heinanen Gesendet: Mi 17.08.2005 15:37 An: Tschofenig, Hannes Cc: p2p-sip@cs.columbia.edu Betreff: [p2p-sip] P2P and 911 (again) Tschofenig, Hannes writes: > 1) the end host is able to use a mapping protocol to locate the psap. > the uri of the psap is determined based on the location of the end > host. if p2p sip client is in gsm/3g device, it could calculate its own location provided that it knows coordinates of available gsm/3g base stations. i once suggested to authorities in finland that every mobile operator is mandated to publish coordinates of their base stations on the internet. this was rejected due to desire of mobile operators to hide such information. this is yet another example of the walled garden philosophy of mobile operators. they don't want to give control to intelligent p2p end devices. perhaps fcc in the u.s., if, as they claim, take emergency calling seriously, could publish such ruling as an example to european regulators. if not, the only conclusion one can make, is that all this fuzz about emergency calling is nothing but joke and in the end the only thing that really matters is commercial interests of walled garden operators. -- juha _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From Richard.Stastny at oefeg.at Wed Aug 17 19:06:50 2005 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Wed Aug 17 19:03:36 2005 Subject: [p2p-sip] P2P and 911 (again) Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C0CE@oefeg-s04.oefeg.loc> Phil wrote: >Remember that many PSAPs will continue with POTS service for some time perhaps for long time depending on their funding. During the >interim, the p2p provider needs to provide a means of locating the appropriate PSAP and routing P2P VoIP 911 calls to the PSAP via the >PSTN. So P2P provider access to emergency services will likely be a real issue and for how long no one knows. If the requirement exists to provide access to emergency services from all Internet devices seriously; the emergency organisatons need to provide access via emergency service routing proxies (ESRP) and gateways feeding the emergency calls into the existing national PSTN system and PSAPs. If I am travelling to the US with my WiFi phone I also expect 911 to work, with or without my local provider. The FCC requirement that only "interconnected" VoIP SP need to provide access to emergency services within the US iwhere E911 is available is very short-sighted. It also requires effort and investments from certain VoIP providers for a short period of time. And one last statement. I have no idea why everybode is assuming that the PSAPs will be on the PSTN for a LONG time. A PSAP is nothing else than a call center and a call center should be converted to VoIP a soon as possible anyway to save operational cost. And in the long term we are all dead (Hayek) -richard From hannes.tschofenig at siemens.com Thu Aug 18 07:40:58 2005 From: hannes.tschofenig at siemens.com (Tschofenig, Hannes) Date: Thu Aug 18 07:42:20 2005 Subject: AW: [p2p-sip] P2P and 911 (again) Message-ID: hi patrick > Richard, > > Remember that many PSAPs will continue with POTS service for > some time perhaps for long time depending on their funding. > During the interim, the p2p provider 'p2p provider' sounds like a strange term to me. > needs to provide a means > of locating the appropriate PSAP there needs to be a way to determine the psap based on location information. if the psap is an ip based device then it will be directly contact by the emergency caller. > and routing P2P VoIP 911 > calls to the PSAP via the PSTN. the interworking with pstn is certainly an issue for a transition period. there are certainly some interesting issues there that need to be considered: - if you participate in a p2p network and you do not have a connectivity to the pstn then obviously you cannot route emergency calls to the pstn. done. - if you support pstn interworking then you might route emergency calls there. here is the difficult part: you need to make this fact available to the mapping database, i.e., 'here is my sip uri and i am responsible for this particular geographical area'. in a p2p network every end host might have the capability to support pstn interworking. two issues arise: * security problems: someone uses your host to place bogus emergency calls. how do you convince the policy that it wasn't you. * authorization problems: you cannot arbitrarily add, removed and update entries in the mapping database > So P2P provider access to > emergency services will likely be a real issue and for how > long no one knows. > ciao hannes > Phil > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, August 17, 2005 3:10 PM > To: Juha Heinanen; Tschofenig, Hannes > Cc: p2p-sip@cs.columbia.edu > Subject: Re: [p2p-sip] P2P and 911 (again) > > > Juha, > > you are at the point. Emergency services in future requires the > provision of location information to the end-users device by the > access providers as an obligation. there will be no obligations > anymore to the application service providers, because in this case > the device may access the PSAP directly. > > A gsm/3g provider is nothing else than just an access provider > like a DSL or cable provider, a WiFi hot spot or WiMAX. > This message has to be conveyed to the regulators, especially > in Europe. > > so the whole discussion if p2p provider have to provide access > to emergency services is needless, they will not be they one > haveing obligations > > -richard > > ________________________________ > > Von: p2p-sip-bounces@cs.columbia.edu im Auftrag von Juha Heinanen > Gesendet: Mi 17.08.2005 15:37 > An: Tschofenig, Hannes > Cc: p2p-sip@cs.columbia.edu > Betreff: [p2p-sip] P2P and 911 (again) > > > > Tschofenig, Hannes writes: > > > 1) the end host is able to use a mapping protocol to > locate the psap. > > the uri of the psap is determined based on the location of the end > > host. > > if p2p sip client is in gsm/3g device, it could calculate its own > location provided that it knows coordinates of available gsm/3g base > stations. > > i once suggested to authorities in finland that every mobile > operator is > mandated to publish coordinates of their base stations on the > internet. > this was rejected due to desire of mobile operators to hide such > information. > > this is yet another example of the walled garden philosophy of mobile > operators. they don't want to give control to intelligent p2p end > devices. > > perhaps fcc in the u.s., if, as they claim, take emergency calling > seriously, could publish such ruling as an example to european > regulators. if not, the only conclusion one can make, is > that all this > fuzz about emergency calling is nothing but joke and in the > end the only > thing that really matters is commercial interests of walled garden > operators. > > -- juha > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > From kumarb at research.panasonic.com Thu Aug 18 10:16:41 2005 From: kumarb at research.panasonic.com (Brijesh Kumar) Date: Thu Aug 18 10:14:08 2005 Subject: [p2p-sip] P2P and 911 (again) References: <32755D354E6B65498C3BD9FD496C7D4613C0CD@oefeg-s04.oefeg.loc> Message-ID: <025101c5a3ff$7dc0ea30$01000001@Brijesh2K> Hi Guys: Isn't all discussion very assumptive as to what P2P SIP should be used? Yes - for some people E911 may be a required service, but it is n't clear why they would like to use P2P SIP for it rather than using standard SIP. After all providing any kind of service guarantee with P2P is nearly impossible unless provider controls all the peer nodes which form the overlay, and their performance. Moreover, you have issues of trust between peers and all related problems of security in a pure p2p environment. Given that all future mobile devices are likely to have GPS location or some other means of getting their own location (i.e., BTS triangulations), I see psap and location mapping more of logistic issue than a technology issue. Any decent DHT implementation can store any kind of data, replicate it so that you can get it any time you search for it. Having said this, I have no idea why some people are thinking P2P SIP has to replace SIP. I can see many applications and environment that do not require E911, and have nothing to do with any kind of provider (including "p2p" provider - whoever it means). All I want to do is use P2P SIP between my hand-held devices in a PAN with no need of any additional baggage of any kind (like E911, legal interception and whatever else "dangerous stuff" is there ...) cheers, --bk ----- Original Message ----- From: "Stastny Richard" To: "Juha Heinanen" ; "Tschofenig, Hannes" Cc: Sent: Wednesday, August 17, 2005 6:10 PM Subject: Re: [p2p-sip] P2P and 911 (again) Juha, you are at the point. Emergency services in future requires the provision of location information to the end-users device by the access providers as an obligation. there will be no obligations anymore to the application service providers, because in this case the device may access the PSAP directly. A gsm/3g provider is nothing else than just an access provider like a DSL or cable provider, a WiFi hot spot or WiMAX. This message has to be conveyed to the regulators, especially in Europe. so the whole discussion if p2p provider have to provide access to emergency services is needless, they will not be they one haveing obligations -richard ________________________________ Von: p2p-sip-bounces@cs.columbia.edu im Auftrag von Juha Heinanen Gesendet: Mi 17.08.2005 15:37 An: Tschofenig, Hannes Cc: p2p-sip@cs.columbia.edu Betreff: [p2p-sip] P2P and 911 (again) Tschofenig, Hannes writes: > 1) the end host is able to use a mapping protocol to locate the psap. > the uri of the psap is determined based on the location of the end > host. if p2p sip client is in gsm/3g device, it could calculate its own location provided that it knows coordinates of available gsm/3g base stations. i once suggested to authorities in finland that every mobile operator is mandated to publish coordinates of their base stations on the internet. this was rejected due to desire of mobile operators to hide such information. this is yet another example of the walled garden philosophy of mobile operators. they don't want to give control to intelligent p2p end devices. perhaps fcc in the u.s., if, as they claim, take emergency calling seriously, could publish such ruling as an example to european regulators. if not, the only conclusion one can make, is that all this fuzz about emergency calling is nothing but joke and in the end the only thing that really matters is commercial interests of walled garden operators. -- juha _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From Richard.Stastny at oefeg.at Thu Aug 18 10:24:00 2005 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Thu Aug 18 10:20:37 2005 Subject: [p2p-sip] P2P and 911 (again) Message-ID: <32755D354E6B65498C3BD9FD496C7D461B20B9@oefeg-s04.oefeg.loc> Finally somebody came up with a use case for SIP P2P Congratulations ;-) With all these discussions on SIP P2P service providers, E911 and not to mention CALEA I had basically no idea what SIP P2P can provide what pure SIP cannot provide Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com > -----Original Message----- > From: Brijesh Kumar [mailto:kumarb@research.panasonic.com] > Sent: Thursday, August 18, 2005 4:17 PM > To: Stastny Richard; Juha Heinanen; Tschofenig, Hannes > Cc: p2p-sip@cs.columbia.edu > Subject: Re: [p2p-sip] P2P and 911 (again) > > Hi Guys: > > Isn't all discussion very assumptive as to what P2P SIP > should be used? > > Yes - for some people E911 may be a required service, but it > is n't clear why they would like to use P2P SIP for it rather than using > standard SIP. After all providing any kind of service guarantee with > P2P is nearly impossible unless provider controls all the peer nodes which > form the overlay, and their performance. Moreover, you have issues > of trust between peers and all related problems of security in a pure > p2p environment. Given that all future mobile devices are likely to have > GPS location or some other means of getting their own location (i.e., BTS > triangulations), I see psap and location mapping more of logistic > issue than a technology issue. Any decent DHT implementation can store any > kind of data, replicate it so that you can get it any time you search > for > it. > > Having said this, I have no idea why some people are thinking P2P SIP > has to replace SIP. I can see many applications and environment that > do not require E911, and have nothing to do with any kind of provider > (including "p2p" provider - whoever it means). > > All I want to do is use P2P SIP between my hand-held devices in a PAN > with no need of any additional baggage of any kind (like E911, legal > interception and whatever else "dangerous stuff" is there ...) > > cheers, > > --bk > > > > > > > ----- Original Message ----- > From: "Stastny Richard" > To: "Juha Heinanen" ; "Tschofenig, Hannes" > > Cc: > Sent: Wednesday, August 17, 2005 6:10 PM > Subject: Re: [p2p-sip] P2P and 911 (again) > > > Juha, > > you are at the point. Emergency services in future requires the > provision of location information to the end-users device by the > access providers as an obligation. there will be no obligations > anymore to the application service providers, because in this case > the device may access the PSAP directly. > > A gsm/3g provider is nothing else than just an access provider > like a DSL or cable provider, a WiFi hot spot or WiMAX. > This message has to be conveyed to the regulators, especially > in Europe. > > so the whole discussion if p2p provider have to provide access > to emergency services is needless, they will not be they one > haveing obligations > > -richard > > ________________________________ > > Von: p2p-sip-bounces@cs.columbia.edu im Auftrag von Juha Heinanen > Gesendet: Mi 17.08.2005 15:37 > An: Tschofenig, Hannes > Cc: p2p-sip@cs.columbia.edu > Betreff: [p2p-sip] P2P and 911 (again) > > > > Tschofenig, Hannes writes: > > > 1) the end host is able to use a mapping protocol to locate the psap. > > the uri of the psap is determined based on the location of the end > > host. > > if p2p sip client is in gsm/3g device, it could calculate its own > location provided that it knows coordinates of available gsm/3g base > stations. > > i once suggested to authorities in finland that every mobile operator is > mandated to publish coordinates of their base stations on the internet. > this was rejected due to desire of mobile operators to hide such > information. > > this is yet another example of the walled garden philosophy of mobile > operators. they don't want to give control to intelligent p2p end > devices. > > perhaps fcc in the u.s., if, as they claim, take emergency calling > seriously, could publish such ruling as an example to european > regulators. if not, the only conclusion one can make, is that all this > fuzz about emergency calling is nothing but joke and in the end the only > thing that really matters is commercial interests of walled garden > operators. > > -- juha > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From slavitch at gmail.com Thu Aug 18 10:55:56 2005 From: slavitch at gmail.com (Michael Slavitch) Date: Thu Aug 18 10:56:53 2005 Subject: [p2p-sip] P2P and 911 (again) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B20B9@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D461B20B9@oefeg-s04.oefeg.loc> Message-ID: <1fc32c8f050818075527881929@mail.gmail.com> What P2P SIP does is move SIP completely to the edge and eliminate the need for softswitches, or in fact any infrastructure at all in the core. Registration and validation, which being peer-to-peer becomes easily and automatically scaleable, redundant and sharable between organizations, and there is no 'god' picking winners. In this model you don't need the permission of a provider to add a service to a realm, you just need to validate yourself as a member and exist and let other endpoints choose. That is incredibly powerful stuff, in essense an automatic dynamic communications network without barriers to entry as different from the current PSTN as the web is from, say, television. M On 18/08/05, Stastny Richard wrote: > > Finally somebody came up with a use case for SIP P2P > Congratulations ;-) > > With all these discussions on SIP P2P service providers, > E911 and not to mention CALEA I had basically no idea > what SIP P2P can provide what pure SIP cannot provide > > Richard > > Richard Stastny > OeFEG > tel:+43 664 420 4100 > enum:+43 780 203 211 > callto://fordprefect > http://voipandenum.blogspot.com > > > > -----Original Message----- > > From: Brijesh Kumar [mailto:kumarb@research.panasonic.com] > > Sent: Thursday, August 18, 2005 4:17 PM > > To: Stastny Richard; Juha Heinanen; Tschofenig, Hannes > > Cc: p2p-sip@cs.columbia.edu > > Subject: Re: [p2p-sip] P2P and 911 (again) > > > > Hi Guys: > > > > Isn't all discussion very assumptive as to what P2P SIP > > should be used? > > > > Yes - for some people E911 may be a required service, but it > > is n't clear why they would like to use P2P SIP for it rather than > using > > standard SIP. After all providing any kind of service guarantee with > > P2P is nearly impossible unless provider controls all the peer nodes > which > > form the overlay, and their performance. Moreover, you have issues > > of trust between peers and all related problems of security in a pure > > p2p environment. Given that all future mobile devices are likely to > have > > GPS location or some other means of getting their own location (i.e., > BTS > > triangulations), I see psap and location mapping more of logistic > > issue than a technology issue. Any decent DHT implementation can store > any > > kind of data, replicate it so that you can get it any time you > search > > for > > it. > > > > Having said this, I have no idea why some people are thinking P2P SIP > > has to replace SIP. I can see many applications and environment that > > do not require E911, and have nothing to do with any kind of provider > > (including "p2p" provider - whoever it means). > > > > All I want to do is use P2P SIP between my hand-held devices in a PAN > > with no need of any additional baggage of any kind (like E911, legal > > interception and whatever else "dangerous stuff" is there ...) > > > > cheers, > > > > --bk > > > > > > > > > > > > > > ----- Original Message ----- > > From: "Stastny Richard" > > To: "Juha Heinanen" ; "Tschofenig, Hannes" > > > > Cc: > > Sent: Wednesday, August 17, 2005 6:10 PM > > Subject: Re: [p2p-sip] P2P and 911 (again) > > > > > > Juha, > > > > you are at the point. Emergency services in future requires the > > provision of location information to the end-users device by the > > access providers as an obligation. there will be no obligations > > anymore to the application service providers, because in this case > > the device may access the PSAP directly. > > > > A gsm/3g provider is nothing else than just an access provider > > like a DSL or cable provider, a WiFi hot spot or WiMAX. > > This message has to be conveyed to the regulators, especially > > in Europe. > > > > so the whole discussion if p2p provider have to provide access > > to emergency services is needless, they will not be they one > > haveing obligations > > > > -richard > > > > ________________________________ > > > > Von: p2p-sip-bounces@cs.columbia.edu im Auftrag von Juha Heinanen > > Gesendet: Mi 17.08.2005 15:37 > > An: Tschofenig, Hannes > > Cc: p2p-sip@cs.columbia.edu > > Betreff: [p2p-sip] P2P and 911 (again) > > > > > > > > Tschofenig, Hannes writes: > > > > > 1) the end host is able to use a mapping protocol to locate the > psap. > > > the uri of the psap is determined based on the location of the end > > > host. > > > > if p2p sip client is in gsm/3g device, it could calculate its own > > location provided that it knows coordinates of available gsm/3g base > > stations. > > > > i once suggested to authorities in finland that every mobile operator > is > > mandated to publish coordinates of their base stations on the > internet. > > this was rejected due to desire of mobile operators to hide such > > information. > > > > this is yet another example of the walled garden philosophy of mobile > > operators. they don't want to give control to intelligent p2p end > > devices. > > > > perhaps fcc in the u.s., if, as they claim, take emergency calling > > seriously, could publish such ruling as an example to european > > regulators. if not, the only conclusion one can make, is that all > this > > fuzz about emergency calling is nothing but joke and in the end the > only > > thing that really matters is commercial interests of walled garden > > operators. > > > > -- juha > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20050818/1acf0e9f/attachment.html From hannes.tschofenig at siemens.com Thu Aug 18 10:56:12 2005 From: hannes.tschofenig at siemens.com (Tschofenig, Hannes) Date: Thu Aug 18 10:56:58 2005 Subject: AW: [p2p-sip] P2P and 911 (again) Message-ID: hi brijesh, > Hi Guys: > > Isn't all discussion very assumptive as to what P2P SIP > should be used? > > Yes - for some people E911 may be a required service, but it > is n't clear why they would like to use P2P SIP for it rather > than using > standard SIP. i guess there is a question of how large the difference between p2p sip and "standard sip" is for you. reading your mail you seem to point more to the architectural differences between p2p as a paradigm and sip as used in the 3gpp, for example. > After all providing any kind of service guarantee with > P2P is nearly impossible unless provider controls all the > peer nodes which > form the overlay, and their performance. > Moreover, you have issues > of trust between peers and all related problems of security in a pure > p2p environment. you certainly need to be a bit more specific about this statement. > Given that all future mobile devices are > likely to have > GPS location or some other means of getting their own > location (i.e., BTS > triangulations), as i noted in my original mail support for gps might be there and it might be possible to use it in certain environments. however, it is also reasonable to think about cases where it does not work or where it is not available. > I see psap and location mapping more of logistic > issue than a technology issue. in order for the mapping protocol to be useful there needs to be a distributed database that stores the location to uri mappings. there are protocol, security and operational issues that need to be considered. > Any decent DHT implementation > can store any > kind of data, replicate it so that you can get it any time > you search for > it. it might be possible to store the mapping there but i see some difficulties. search capabilities, as far as i know, are pretty limited with many p2p systems. > > Having said this, I have no idea why some people are thinking P2P SIP > has to replace SIP. i guess nobody said that. > I can see many applications and environment that > do not require E911, and have nothing to do with any kind of provider > (including "p2p" provider - whoever it means). > > All I want to do is use P2P SIP between my hand-held devices in a PAN > with no need of any additional baggage of any kind (like E911, legal > interception and whatever else "dangerous stuff" is there ...) we started with an attempt to better understand the impact of a p2p sip alike environment for emergency support. this seems to be an issue many people worry about. there are certainly some aspects (including security issues) that deserve a closer look. if you are interested in controlling light bulbs using sip, for example, then is likely no reason to deal with emergency cases or lawful interception. ciao hannes > > cheers, > > --bk > > > > > > > ----- Original Message ----- > From: "Stastny Richard" > To: "Juha Heinanen" ; "Tschofenig, Hannes" > > Cc: > Sent: Wednesday, August 17, 2005 6:10 PM > Subject: Re: [p2p-sip] P2P and 911 (again) > > > Juha, > > you are at the point. Emergency services in future requires the > provision of location information to the end-users device by the > access providers as an obligation. there will be no obligations > anymore to the application service providers, because in this case > the device may access the PSAP directly. > > A gsm/3g provider is nothing else than just an access provider > like a DSL or cable provider, a WiFi hot spot or WiMAX. > This message has to be conveyed to the regulators, especially > in Europe. > > so the whole discussion if p2p provider have to provide access > to emergency services is needless, they will not be they one > haveing obligations > > -richard > > ________________________________ > > Von: p2p-sip-bounces@cs.columbia.edu im Auftrag von Juha Heinanen > Gesendet: Mi 17.08.2005 15:37 > An: Tschofenig, Hannes > Cc: p2p-sip@cs.columbia.edu > Betreff: [p2p-sip] P2P and 911 (again) > > > > Tschofenig, Hannes writes: > > > 1) the end host is able to use a mapping protocol to > locate the psap. > > the uri of the psap is determined based on the location of the end > > host. > > if p2p sip client is in gsm/3g device, it could calculate its own > location provided that it knows coordinates of available gsm/3g base > stations. > > i once suggested to authorities in finland that every mobile > operator is > mandated to publish coordinates of their base stations on the > internet. > this was rejected due to desire of mobile operators to hide such > information. > > this is yet another example of the walled garden philosophy of mobile > operators. they don't want to give control to intelligent p2p end > devices. > > perhaps fcc in the u.s., if, as they claim, take emergency calling > seriously, could publish such ruling as an example to european > regulators. if not, the only conclusion one can make, is > that all this > fuzz about emergency calling is nothing but joke and in the > end the only > thing that really matters is commercial interests of walled garden > operators. > > -- juha > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > > From davidbryan at gmail.com Fri Aug 26 13:56:07 2005 From: davidbryan at gmail.com (David A. Bryan) Date: Fri Aug 26 13:56:17 2005 Subject: [p2p-sip] IETF informal BOF minutes/slides at www.p2psip.org Message-ID: <8b2769930508261056575a0247@mail.gmail.com> Sorry for the delay on this, but I've gathered the various slides and notes from a couple of people related to the IETF informal P2P SIP BOF in Paris and put them together in a section of www.p2psip.org. I've also restructured the www.p2psip.org site (there was getting to be too much for the simple, one page design it had), so if you see anything that is broken or it doesn't render properly on your browser, or have content suggestions, let me know. I'm going to condense all the suggestions I've had for topics for the next meeting in the next few days, and will post it shortly. David Bryan -- David Bryan Please continue to send me email at the address bryan@ethernot.org From kumarb at research.panasonic.com Mon Aug 29 11:43:05 2005 From: kumarb at research.panasonic.com (Brijesh Kumar) Date: Mon Aug 29 11:36:41 2005 Subject: [p2p-sip] FCC on VOIP and SIP References: <03bb01c5a26f$ccca80a0$6a01010a@keywest> Message-ID: <00d601c5acb0$58c25700$01000001@Brijesh2K> We recently concluded a very engrossing discussion on P2P SIP and some needs of wiretapping and E911 features on this list. I think it will be important to understand the official position from the FCC specially for those who are trying to use VoIP in network operator environment (whether based on SIP or P2P SIP or any thing else like Skype). The FCC specified in an August 5 release that VOIP providers that interconnect with the PSTN must facilitate wire taps within 18 months of the release of the order. So at least the PSTN-connected "SkypeOut" portion of Skype's business appears to be on the hook for compliance under the CALEA laws. The FCC had similarly ruled a few months ago that VOIP providers that connect callers to the publicly switched telephone network (PSTN) must be able to provide full E911 service. That is, they must have the access and systems in place to route emergency calls that automatically generate the caller's location information for the 911 operator. I hope the above will give people a chance to re-look their positions with regards to above areas. It is important for the non-US participants to note that the FCC only provides policies only for operator controlled networks. Cheers, --brijesh From henry at pulver.com Mon Aug 29 12:28:05 2005 From: henry at pulver.com (Henry Sinnreich) Date: Mon Aug 29 12:28:32 2005 Subject: [p2p-sip] FCC on VOIP and SIP In-Reply-To: <00d601c5acb0$58c25700$01000001@Brijesh2K> Message-ID: <200508291628.j7TGSCsw009917@cs.columbia.edu> See RFC 3924 ftp://ftp.rfc-editor.org/in-notes/rfc3924.txt Legal intercept had to be effective for all media, not only voice. Thanks, Henry Henry Sinnreich CTO pulver.com 115 Broadhollow Rd Suite 225 Melville, NY 11747 USA -----Original Message----- From: Brijesh Kumar [mailto:kumarb@research.panasonic.com] Sent: Monday, August 29, 2005 10:43 AM To: p2p-sip@cs.columbia.edu Subject: [p2p-sip] FCC on VOIP and SIP We recently concluded a very engrossing discussion on P2P SIP and some needs of wiretapping and E911 features on this list. I think it will be important to understand the official position from the FCC specially for those who are trying to use VoIP in network operator environment (whether based on SIP or P2P SIP or any thing else like Skype). The FCC specified in an August 5 release that VOIP providers that interconnect with the PSTN must facilitate wire taps within 18 months of the release of the order. So at least the PSTN-connected "SkypeOut" portion of Skype's business appears to be on the hook for compliance under the CALEA laws. The FCC had similarly ruled a few months ago that VOIP providers that connect callers to the publicly switched telephone network (PSTN) must be able to provide full E911 service. That is, they must have the access and systems in place to route emergency calls that automatically generate the caller's location information for the 911 operator. I hope the above will give people a chance to re-look their positions with regards to above areas. It is important for the non-US participants to note that the FCC only provides policies only for operator controlled networks. Cheers, --brijesh From jh at tutpro.com Mon Aug 29 12:52:29 2005 From: jh at tutpro.com (Juha Heinanen) Date: Mon Aug 29 12:52:42 2005 Subject: [p2p-sip] FCC on VOIP and SIP In-Reply-To: <200508291628.j7TGSCsw009917@cs.columbia.edu> References: <00d601c5acb0$58c25700$01000001@Brijesh2K> <200508291628.j7TGSCsw009917@cs.columbia.edu> Message-ID: <17171.15693.93319.618751@rautu.tutpro.com> Henry Sinnreich writes: > I hope the above will give people a chance to re-look their positions with > regards to above areas. It is important for the non-US participants to note > that the FCC only provides policies only for operator controlled > networks. so far, but considering the recent past history, i would not be surprised if fcc or some other u.s. agency would issue regulation that makes it illegal to have ANY KIND of communication over the internet unless the parties positively identify themselves and route all signalling and media traffic via a government proxy. the next step is that every u.s. citizen must record all conversations they have at home, at office, on the street, etc. and submit the data once per day to a government agency unless they arrange a direct feed from their home or via mobile on the road. you see, once you start to obey these kind of fcc or other agency rules and start building protocols to support them, there is no limit on how far they go. there is always the next requirement on their list once they have gotten the previous one. so it is a high time to act now or your privacy is lost forever. -- juha From jh at tutpro.com Mon Aug 29 14:48:50 2005 From: jh at tutpro.com (Juha Heinanen) Date: Mon Aug 29 14:48:45 2005 Subject: [p2p-sip] FCC on VOIP and SIP In-Reply-To: <200508291842.j7TIgMgc028375@rautu.tutpro.com> References: <17171.15693.93319.618751@rautu.tutpro.com> <200508291842.j7TIgMgc028375@rautu.tutpro.com> Message-ID: <17171.22674.383350.380940@rautu.tutpro.com> Henry Sinnreich writes: > I did not write the attached and besides, what are SBC for? :-) sorry henry, i knew that you didn't write it. i just replied to earlier message my copying it from the message you wrote. my mistake. -- juha From Richard.Stastny at oefeg.at Mon Aug 29 16:33:52 2005 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Mon Aug 29 16:32:29 2005 Subject: [p2p-sip] FCC on VOIP and SIP Message-ID: <32755D354E6B65498C3BD9FD496C7D4613C106@oefeg-s04.oefeg.loc> One can also interpret the NEW FCC that ANY communication on IP has to be routed via the PSTN to get intercepted ;-) The FCC is getting weirder and weirder -richard ________________________________ Von: p2p-sip-bounces@cs.columbia.edu im Auftrag von Juha Heinanen Gesendet: Mo 29.08.2005 18:52 An: henry@pulver.com Cc: p2p-sip@cs.columbia.edu Betreff: RE: [p2p-sip] FCC on VOIP and SIP Henry Sinnreich writes: > I hope the above will give people a chance to re-look their positions with > regards to above areas. It is important for the non-US participants to note > that the FCC only provides policies only for operator controlled > networks. so far, but considering the recent past history, i would not be surprised if fcc or some other u.s. agency would issue regulation that makes it illegal to have ANY KIND of communication over the internet unless the parties positively identify themselves and route all signalling and media traffic via a government proxy. the next step is that every u.s. citizen must record all conversations they have at home, at office, on the street, etc. and submit the data once per day to a government agency unless they arrange a direct feed from their home or via mobile on the road. you see, once you start to obey these kind of fcc or other agency rules and start building protocols to support them, there is no limit on how far they go. there is always the next requirement on their list once they have gotten the previous one. so it is a high time to act now or your privacy is lost forever. -- juha _______________________________________________ p2p-sip mailing list p2p-sip@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip From RoyR at saic-abingdon.com Fri Aug 19 15:05:00 2005 From: RoyR at saic-abingdon.com (Roy, Radhika (AEAD)) Date: Sat Sep 3 08:40:55 2005 Subject: [p2p-sip] P2P and 911 (again) Message-ID: <2FE23D25B7292B489A217D1965CDA866726453@bh-exchange02.saic-abingdon.com> Hi, all: Is it not the case that SIP P2P BOF is supposed to explain why we need to establish a new SIP P2P WG because it requires new P2P protocol developments what SIP WG cannot do? Best regards, Radhika ________________________________ From: p2p-sip-bounces@cs.columbia.edu on behalf of Stastny Richard Sent: Thu 8/18/2005 10:24 AM To: Brijesh Kumar; Juha Heinanen; Tschofenig, Hannes Cc: p2p-sip@cs.columbia.edu Subject: RE: [p2p-sip] P2P and 911 (again) Finally somebody came up with a use case for SIP P2P Congratulations ;-) With all these discussions on SIP P2P service providers, E911 and not to mention CALEA I had basically no idea what SIP P2P can provide what pure SIP cannot provide Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com > -----Original Message----- > From: Brijesh Kumar [mailto:kumarb@research.panasonic.com] > Sent: Thursday, August 18, 2005 4:17 PM > To: Stastny Richard; Juha Heinanen; Tschofenig, Hannes > Cc: p2p-sip@cs.columbia.edu > Subject: Re: [p2p-sip] P2P and 911 (again) > > Hi Guys: > > Isn't all discussion very assumptive as to what P2P SIP > should be used? > > Yes - for some people E911 may be a required service, but it > is n't clear why they would like to use P2P SIP for it rather than using > standard SIP. After all providing any kind of service guarantee with > P2P is nearly impossible unless provider controls all the peer nodes which > form the overlay, and their performance. Moreover, you have issues > of trust between peers and all related problems of security in a pure > p2p environment. Given that all future mobile devices are likely to have > GPS location or some other means of getting their own location (i.e., BTS > triangulations), I see psap and location mapping more of logistic > issue than a technology issue. Any decent DHT implementation can store any > kind of data, replicate it so that you can get it any time you search > for > it. > > Having said this, I have no idea why some people are thinking P2P SIP > has to replace SIP. I can see many applications and environment that > do not require E911, and have nothing to do with any kind of provider > (including "p2p" provider - whoever it means). > > All I want to do is use P2P SIP between my hand-held devices in a PAN > with no need of any additional baggage of any kind (like E911, legal > interception and whatever else "dangerous stuff" is there ...) > > cheers, > > --bk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20050819/6b98e9e5/attachment.html