Subject: [p2p-sip] P2P and 911

From: ppatrick at pacwest.com (Philip Patrick)
Date: Tue Aug 16 13:03:46 2005

>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:[email-masked]]
Sent: Tuesday, August 16, 2005 6:40 AM
To: 'Arjun Roychowdhury'
Cc: [email-masked]; 'Tschofenig, Hannes'; 'Richard Shockey';
'Johnston,Alan'; [email-masked]; 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:[email-masked]] 
Sent: Tuesday, August 16, 2005 8:07 AM
To: [email-masked]
Cc: [email-masked]; Tschofenig, Hannes; [email-masked]; 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 <[email-masked]> 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:[email-masked]]
> Sent: Sunday, August 14, 2005 1:18 PM
> To: Tschofenig, Hannes
> Cc: [email-masked]; 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 <[email-masked]> 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: [email-masked]
> > > [mailto:[email-masked]] Im Auftrag von David A. Bryan
> > > Gesendet: Samstag, 13. August 2005 03:32
> > > An: Brijesh Kumar
> > > Cc: [email-masked]; Richard Shockey
> > > Betreff: [p2p-sip] P2P and 911
> > >
> > >
> > > <moved this thread over from the sipping list to here>
> > >
> > > 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 <[email-masked]> wrote:
> > > > ----- Original Message -----
> > > > From: "Philip Patrick" <[email-masked]>
> > > >
> > > > > 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:[email-masked]]
> > > > > 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 [email-masked] for questions on current sip
> > > > > Use [email-masked] 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 [email-masked] for questions on current sip
> > > > > Use [email-masked] 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 [email-masked] for questions on current sip
> > > > Use [email-masked] for new developments of core SIP
> > > >
> > >
> > >
> > > --
> > > David Bryan
> > > Please continue to send me email at the address [email-masked]
> > >
> > > _______________________________________________
> > > p2p-sip mailing list
> > > [email-masked]
> > > http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
> > >
> >
> 
> 
> --
> David Bryan
> Please continue to send me email at the address [email-masked]
> 
> 
> 
> 
> _______________________________________________
> p2p-sip mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
> 

-- 
Arjun Roychowdhury

_______________________________________________
p2p-sip mailing list
[email-masked]
http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue Aug 16 13:20:36 2005

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 <[email-masked]> 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.
> 
> 

-- 
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 (David A. Bryan)
Date: Tue Aug 16 13:30:22 2005

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 <[email-masked]> wrote:
> 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
> 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
> > 'Johnston,Alan'; [email-masked] ; Karl Stahl
> > From: Arjun Roychowdhury [mailto:[email-masked] ]
> > > From: David A. Bryan [mailto: [email-masked]]
> > > > > [mailto: [email-masked]] Im Auftrag von David A.
> Bryan
> > > > > be a legitimate use ( i.e., a node can reach another node, but not a
> > > > > > > From: Dean Willis [mailto: [email-masked]]

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue Aug 16 13:48:48 2005

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 <[email-masked]> wrote:
> > > > responsible for a particular geographical region). what assumptions 
> do
> > you
> > > > > > and media or something like that), but that many P2P systems 
> will
> > not
> > > > > > I guess I would tend to think that adding full e911 support is 
> out
> > of
> > > > > > > correct >PSAP and rendering of location information for use by 
> a
> > 911
> > > > > > > dispatcher is essential.
> > > > > > >
> > > > > > >
> > > > > > > Philips:
> > > > > > >
> > > > > > > Many people may want to use P2P SIP only for applications 
> within
> > the
> > > > > > > > not certain about access to emergency services -- this may 
> well
> > be
> > > > > > > > There are already mechanisms available for lawful intercept 
> in
> > the
> > > > > > > > specify those mechanisms. I feel that this is consistent 
> with
> > the
> > > > > > > > intent of RFC 1984.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Dean
> > > > > > > >
> > > > > > > >

-- 
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