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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Dec 2003 09:18:42 -0500

Tom

It's always hard to work in a situation where politics intrudes.  
This is one of them.  As engineers, all we can do is sit down with our 
counterparts and try to work through the engineering issues.  
In the IETF, this usually works pretty well.  Some countries chose 
to try to assert more control over the entities that they can regulate.  
That's going to happen.  However, I think our history shows that our 
process works pretty well, and we are able to build systems that are 
universally applicable, scale well, and perform to user's satisfaction.  
I believe that it is possible to do so here, and I'm going to be working 
hard to make it happen.

So far, most of the people I've been able to talk to have come around
to the idea that regulation won't work with VoIP but cooperative standards
will.  Your Mileage May Vary.

Brian

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]]
Sent: Friday, December 19, 2003 9:11 AM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: RE : [sipping] comment on
draft-polk-sipping-location-require ments -01.txt

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.

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Dec 2003 10:23:23 -0500

Tyler

You are leaping pretty far, and I think you are pushing beyond anyone's
comfort zone.
The world of emergency calling is pretty limited in how far they are willing
to change paradigms.  I'm having a LOT of trouble just getting them to
understand
that they really do have to deal with scenarios like I described.  They are
readily able to understand, and appreciate, that calls to emergency services
will be multimedia.  When you have a mobile phone with a camera, and there
is hazardous materials, people will want to see the images.  IM will be a
way to
communicate, as TTY users already do, and the list goes on.

However, to get off the notion that its a "call" to the psap is over the top
I think.  SIP is pretty good here; you can have any kind of media in the
call,
but its still a call.  So, at least now, I'm not interested in extracting
emergency call from SIP.  One reality is that the emergency centers really
want to communicate human to human in real time because their experience
with
anything automatic is pretty poor.  They take the call, but they don't like
it,
because the automatic mechanisms frequently cause the wrong response.  They
like pendants, but they want them to have a microphone and a speaker at
least.
"Help I've fallen and I can't get up" is followed by a lot of questions that
determine what help to send.  They really want a callback identifier, a
location
and all the rest of the things that sip gives you.

Brian

-----Original Message-----
From: Tyler Johnson [mailto:[email-masked]]
Sent: Friday, December 19, 2003 9:38 AM
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.

for
the
assert
whether 

it?

late?
conflicting
to
meters?

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 19 Dec 2003 11:00:06 -0500

Richard

I believe you are confusing the issue of how you determine location from the
issue
of how you connect to an emergency center.  I think Tyler was addressing the
latter,
while your comments appear to deal with the former.

Actually, I think we see the way forward with location determination.
There will be devices that know where they are via GPS or other mechanisms
There will be devices that learn their location from mechanisms that are
	either proprietary or out of scope for any IETF working group
For devices that need standardized ways of being told where they are,
  there are two cases:
	The device is fixed (doesn't move from boot to call for help)
		This is addressed with DHCP, and works regardless of VPNs.  
		The original DHCP probe (hotspot for example) will supply 
		location, not the interior DHCP (within the VPN).
	The device moves
		This is the subject of the present thread.  

I sent a message on the subject of separating signalling from sip.

I believe that there is nothing simple about emergency calling, and you
require the kinds of things that SIP provides.  Inventing a new session
initiation protocol for emergency sessions is not reasonable, I think.
You have a session with the psap, you pass media, bidirectionaly.  
SIP is very appropriate.

Also, please note that considered opinion is that buttons labled 
"emergency" generally are a bad idea; they get pushed inappropriately 
much too often.  Most experts prefer a multibutton sequence.  
There are some amusing stories (right Dick?) about how often various 
3 digit combinations are accidentally "pressed" on mobiles.  
Your intuition might very well be wrong here.

Brian

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]]
Sent: Friday, December 19, 2003 10:36 AM
To: [email-masked]; 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

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

> Sent: Friday, December 19, 2003 3:38 PM
> To: Rosen, Brian
> [email-masked]; [email-masked]; Henning Schulzrinne; 
> Jonathan Rosenberg
> > 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.
> > 
> > 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
> > organizations in other parts of the world.  It has not been 
> decided whether 
> > It doesn't say you can't provide more than one type of measurement, 
> > does it?
> > 
> > 
> > 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.
> > 
> > requirements are (in the US). It is silly and hopeless for 
> the IETF to 
> > try to agree on "requirements".
> > 
> > Mike
> > 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Michael Hammer <[email-masked]>
Date: Fri, 19 Dec 2003 13:40:53 -0500

Would such an application-independent solution require a mapping from host 
network IP pre-fix to an associated Public Service Access Point (PSAP) or 
911, 112, or whatever center?

I am imagining that a DNS record would have a selection of application types:
sip, im, or whatever to enable all covered modes of communication to be 
redirected to that PSAP.  For example, VPN tunneled call to PBX in 
Washington from Paris causes the PBX to do a look-up and redirect a sip 
call to the local Paris emergency center closest to that Internet cafe.  If 
it is a two-way pager using IM, then the IM is looked up and forwarded, etc.

Mike

At 04:36 PM 12/19/2003 +0100, Stastny Richard wrote:
>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
>To put the necessary parameters in the access device and get access from 
>any device cannot be too complicated.
>