Subject: RE: RE : [sipping] comment on draft-polk-sipping-location-require ments -01.txt

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Dec 2003 08:47:39 -0500

Sébastien

There will HAVE to be a single worldwide set of requirements for
emergency services, because the Internet does not respect national 
boundaries, and we ALREADY see the effect of this on calls to 
emergency services.

My usual example would be a patron of a Paris cafe using a WiFi 
hotspot with a VPN tunnel open to her employers network, in which 
she is running a sip softclient.  If an accident occurs outside 
the cafe, and she uses her softclient to call for help, how does 
the employer, which could be located in another continent, 
and using its local VoIP carrier, be subject to any 
laws/specifications of France?  It cannot.  And the hotspot 
operator, which might be subject to some regulation, is unaware 
that there is a VoIP call, let alone a call to the emergency system,
and in fact there is likely encryption on the tunnel making it
impossible for it to figure it out.

However, if there is an international standard, such as we produce 
here in the IETF, then it is VERY likely that the softclient, 
the employer's PBX, and the VoIP carrier are able to correctly 
handle the call, routing it to the correct emergency answering point, 
and including call-back information as well as location information.  
It is only an international standard that will work as the Internet 
joins fixed, mobile and roaming users with a variety of devices, 
proxies and carriers operating over multiple continents.

The IETF has a history of not sanctioning regional variations in
its specifications, and, as the above example illustrates, it is
not feasible to implement regional or national variations.  The
reality of the situation is that regulating emergency calls is
not possible with VoIP (unless there was an international treaty
that had universal applicability), but a single, effective
international standard is very possible.

Such a standard needs an agreed set of requirements, of course.

I've stated my views on the proxy insertion of location.  

Brian

-----Original Message-----
From: PROUVOST Sébastien FTRD/DAC/ISS
[mailto:[email-masked]]
Sent: Friday, December 19, 2003 6:32 AM
To: Rosen, Brian; [email-masked]; [email-masked]
Cc: [email-masked]; Henning Schulzrinne; Jonathan Rosenberg
Subject: RE : [sipping] comment on
draft-polk-sipping-location-requirements -01.txt

Two points here :
 
First I doubt that there will be a single world wide set of requirements for
emergency calls.

Second, a requirement listed in the original draft was for a proxy to be
able to give its idea of the terminal location (originally by asserting the
location given by the terminal). However, it may be easier for a proxy to
insert its own info about the location of the terminal rather than to assert
the info given by the terminal. It also let the possibility to the called
party to get both pieces of information which is useful information as
pointed out by Jonathan. Both pieces of information shall be passed on.

Sébastien Prouvost
France Télécom R&D/DAC/CAR

-----Message d'origine-----
De : Rosen, Brian [mailto:[email-masked]] 
Envoyé : jeudi 18 décembre 2003 22:48
À : [email-masked]'; [email-masked]
Cc : [email-masked]
Objet : RE: [sipping] comment on draft-polk-sipping-location-requirements
-01.txt

And NENA is working on such requirements, and is starting to engage other 
organizations in other parts of the world.  It has not been decided whether 
there will be multiple, possibly conflicting requirements sent in from 
different organizations, or whether an effort will be mounted to negotiate 
a single set of requirements.  I favor the latter, because we don't have 
the expertise in the IETF to deal with conflicts if they were to arise.  

I'd ask that anyone who knows people who should be involved (NENA 
equivalents in other parts of the world), please contact me. 

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 18, 2003 3:47 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sipping] comment on draft-polk-sipping-location-requirements
-01.txt

In a message dated 12/18/2003 3:05:36 PM Eastern Standard Time,
[email-masked] writes: 

It doesn't say you can't provide more than one type of measurement, does it?

What liability would a carrier assume if the handset using GPS provided a 
location to 10 meters, and that got over-ridden by a carrier network using 
TOA providing an accuracy of 100 meters, and the ambulance arrives too late?

More than one type of location is not the problem. I believe all the past
discussion was that the "handset" and the "carrier" came up with conflicting
information. If they were not conflicting, then why have two. If they are
conflicting, that is a problem. If the handset gives a physical location to
10 meters, why would the carrier network bother to include a value of 100
meters accuracy, if the value from the end user were within that 100 meters?
If it isn't, what should the PSAP do, send an ambulance to both? 

If the handset gave a value within 10 meters and the carrier overwrote it
with a value accurate to only 100 meters, there would be serious liability
issues, especially if the requirement were for an accuracy of 50 feet. 

Like I said, NENA (or some such organization) needs to say what the
requirements are (in the US). It is silly and hopeless for the IETF to try
to agree on "requirements". 

Mike 

_______________________________________________
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

---

From: Tom Taylor <[email-masked]>
Date: Fri, 19 Dec 2003 09:10:40 -0500

It's nice to think we might put together a solution that works for all 
situations, but my own analysis suggested that may not be possible.  It 
depends amongst other things on the administrative arrangements within a 
given country.  The sensible thing for the the VPN tunneler is to use 
alternate means -- i.e. yell for help.

---

From: Tyler Johnson <[email-masked]>
Date: Fri, 19 Dec 2003 09:37:54 -0500

All,

I have been following this discussion with some interest. It seems to me 
that in trying to create a 911 service for VoIP, we are applying an old 
paradigm to a new technology.

I think that emergency services are important for many applications, and 
VoIP is just one. For example, I should be able to summon help from my 
email, IM device, Blackberry, etc. Further, I can see a 'Help I've 
fallen and I can't get up' 802.11b panic pendant for grandmothers. As IP 
is deployed, it will become increasingly important to provide these 
services, and municipalities will mandate it.

Because of this, I very much agree with Brian's notion that the physical 
(or layer 2) network should provide the emergency service signalling. 
However, it strikes me that it is not appropriate to build this 
functionality into SIP or the VoIP application. Rather, it should be 
developed as a standalone generic service (outside of SIPPING) that can 
be accessed by any application. Then, SIPPING could point to it as the 
emergency services method of choice.

I am concerned that if we build emergency services into VoIP, then VoIP 
emergency services will quickly become obsolete as the pace of other IP 
applications requiring emergency services quickens.