Subject: AW: [p2p-sip] P2P and 911

From: hannes.tschofenig at siemens.com (Tschofenig, Hannes)
Date: Sun Aug 14 10:06:02 2005

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
>

---

From: davidbryan at gmail.com (David A. Bryan)
Date: Sun Aug 14 14:18:03 2005

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

---

From: henry at pulver.com (Henry Sinnreich)
Date: Mon Aug 15 21:01:49 2005

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

--David

On 8/14/05, Tschofenig, Hannes <[email-masked]> wrote:
> 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)?
> ps: the ecrit requirements draft can be found at:
http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-01.
txt

---

From: arjunrc at gmail.com (Arjun Roychowdhury)
Date: Tue Aug 16 09:07:09 2005

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

-- 
Arjun Roychowdhury

---

From: dworley at pingtel.com (Dale Worley)
Date: Tue Aug 16 10:38:29 2005

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 (Michael Slavitch)
Date: Tue Aug 16 11:17:51 2005

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.

-- 
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 (Henry Sinnreich)
Date: Tue Aug 16 11:28:25 2005

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

regds
arjun

On 8/15/05, Henry Sinnreich <[email-masked]> wrote:
> > as with many other p2p related topics there is a question of what type
of
> infrastructure is available.

-- 
Arjun Roychowdhury

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue Aug 16 12:46:49 2005

> 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: jh at tutpro.com (Juha Heinanen)
Date: Wed Aug 17 08:27:53 2005

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: dworley at pingtel.com (Dale Worley)
Date: Wed Aug 17 11:55:44 2005

> 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: kumarb at research.panasonic.com (Brijesh Kumar)
Date: Mon Aug 29 11:36:41 2005

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 (Henry Sinnreich)
Date: Mon Aug 29 12:28:32 2005

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:[email-masked]] 
Sent: Monday, August 29, 2005 10:43 AM
To: [email-masked]
Subject: [p2p-sip] FCC on VOIP and SIP 

Cheers,

--brijesh

---

From: jh at tutpro.com (Juha Heinanen)
Date: Mon Aug 29 12:52:42 2005

> that the FCC only provides policies only for operator controlled

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 (Juha Heinanen)
Date: Mon Aug 29 14:48:45 2005

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