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

From: "Stastny Richard" <[email-masked]>
Date: Fri, 19 Dec 2003 16:36:11 +0100

I fully agree.

I also was following this and previous discussions with interest, because this issue
pops up periodicly over and over again and always dies away because no solution
on the application layer is possible in mobile environments (at least non has been found yet).
GPS does not work, user entry does not work, DHCP does not work because of VPNs, 
User profile does not work, etc.

So the only possiblity is a very simple basic protocol on layer 2, lets
call it SEP (Simple Emergency Protocol).

If this protocol is simple enough, it may be mandated by regulators to be implemented
in every IP access environment and also in any IP access device and it should also
work like 112 in mobiles without login to the environment.

The required SW could be made mandatory and part of all IP-enabled operating systems.
In its simplest varity it could work with a simple click on a (soft)button, it could also use
existing applications (e-mail, chat, SIP, etc.) if available, but this is out of scope.

To put the necessary parameters in the access device and get access from any device cannot be too complicated.

I propose to set up an own WG to deal with this asap.

best regards
Richard

> -----Original Message-----
> From: Tyler Johnson [mailto:[email-masked]] 
> Sent: Friday, December 19, 2003 3:38 PM
> To: Rosen, Brian
> Cc: 'PROUVOST Sébastien FTRD/DAC/ISS'; [email-masked]; 
> [email-masked]; [email-masked]; Henning Schulzrinne; 
> Jonathan Rosenberg
> Subject: Re: RE : [sipping] comment on 
> draft-polk-sipping-location-require ments -01.txt
> 
> 
> 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.
> 
> Rosen, Brian wrote:
> > 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
> 
> 
> 
> _______________________________________________
> 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: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Dec 2003 18:27:50 -0500

We have been building and advocating location beacons, for example using 
BlueTooth or the wireless AP. Low cost and not subject to VPN issues. 
This is very similar to the Cisco Discovery Protocol (CDP), which could 
be readily extended to handle this functionality. Unfortunately, that 
protocol is proprietary.

However, this has very little to do with the signaling and session 
setup. After all, we don't care about getting IP packets to a PSAP, but 
rather applications, since the PSAP only cares about a finite set of 
applications.

Clearly, there are components (such as location objects and DNS or other 
directory lookups) that are useful across application protocols. Brian 
and I (and I'm sure, others) have been thinking of various approaches 
along these lines.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Dec 2003 01:35:28 -0500

> and I (and I'm sure, others) have been thinking of various approaches 

I think IETF as a whole has been thinking along these lines, and IMHO, 
done a pretty good job of separating concerns.

One issue is how an entity determines the location of a device; things 
like GPS, bluetooth, provisioning, etc. will be used here, all of 
these are outside of IETF scope and there will be many, many solutions 
for a long time.

Once determined, there is a need for a standardized representation. We 
have that through geopriv.

Once you have a standardized representation, you may need various 
application entities to obtain the information in this representation. 
Thats the role of the using protocol in geopriv. We have one so far, 
SIMPLE.

Once an application element has location information (either because 
it knows it itself, or it obtained it from a using protocol), from 
there what you do with it depends on the application. For SIP, one 
piece of the problem is routing a call to an emergency center and 
providing the center with the location of the caller. That is exactly 
what we are discussing here - encapsulating the location information 
into the request to achieve that.

Thus, I think we have neatly divided the problem about as well as you 
possibly can.

-Jonathan R.

>> GPS does not work, user entry does not work, DHCP does not work 
>> because of VPNs, User profile does not work, etc.
>>
>> To put the necessary parameters in the access device and get access 
>> from any device cannot be too complicated.
>>
>>> From: Tyler Johnson [mailto:[email-masked]] Sent: Friday, 
>>> December 19, 2003 3:38 PM
>>> To: Rosen, Brian
>>> [email-masked]; [email-masked]; Henning Schulzrinne; Jonathan 
>>> Rosenberg
>>> 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.
>>>
>>> Rosen, Brian wrote:
>>>
>>>> Sébastien
>>>>
>>>> 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,
>>>> 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,
>>>
>>> Use [email-masked] for questions on current sip Use 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com