Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 16 Apr 2007 11:09:47 -0500

All very true I think. Providing location, in my view, is likely to go
through the usual stages:

* Pay to play
* Free as a competitive differentiator
* Lowest common denominator and assumed as part of the access

I think the first phase is likely to prove quite short, to non-existent,
because of the cost of putting the billing overlay in.

Telephone companies didn't go into business to provide connectivity to
emergency services but, eventually, they did it because it's a social
service and society enforced the obligation - emergency calling,
including location, became an assumed part of the bundle.

Similarly, the physics of the situation dictates it's the providers of
broadband Internet access who can work out location (it's not like it's
a business conspiracy) and, eventually, this will become an assumed part
of the access bundle.

In cellular networks, the location request associated with initiating an
emergency call is called a "network initiated" request because the
mobile switching center makes the request to the location server.
However, most networks also support a form of request called
"mobile-originated". It's quite likely that any suitably capable handset
can request location, unhindered, from those mobile networks. That's
control plane - but SUPL permits SET-initated requests as well.

Providing location in cellular networks is probably the most network
resource intensive form of this service. The precedent is in, really,
that users will be able to get their location for free.

The business strategists that you refer to still need to go through
their own processes and come to their own conclusions but I don't think
you'll be suffering stock option envy on this count Henning.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Sunday, 15 April 2007 12:52 AM
To: Rosen, Brian
Cc: [email-masked]; [email-masked]
Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do
endpointcentric LCP without giving away the store

[This is partially an editorial, but I'll get to solutions in the  
next message...]

My prediction is that the dream of untold riches to be mined from  
location information is largely just that.

In particular, I believe that the value of non-emergency location  
information for stationary devices in a residential setting is pretty  
close to zero. After all, users already know their home address and  
for pizza delivery and similar tasks, it doesn't much matter whether  
the address validates. Users will fix their address after the first  
cold pizza arrives.

As a practical matter, monetizing this information is going to be  
very difficult, particularly in European Union countries with strong  
privacy laws. A VSP is very unlikely to pay for location information,  
as it has no direct need for it. The local pizza parlor might find  
the information to be of interest, but the logistics are pretty  
daunting. Since you can't easily do per-use approval, as you can do  
with end system location, the pizza parlor would have to contact the  
various access providers and negotiate an arrangement. In addition,  
and most onerously, the pizza parlor would probably need to get  
individual approval from each potential customer to release this  
information to them. As a customer, why would I agree to release  
location information to every business, known and unknown, for  
purposes unknown? This can be fixed by uploading GEOPRIV policy to  
the access provider, but this requires heavy-duty machinery, as  
customers have to figure out which domains to include in that list.  
The likelihood that users will remember to add the pizza parlor's  
domain name to that list before calling for delivery is pretty slim.  
For a second delivery, the restaurant already has the correct and  
verified address, so it has limited additional value.

Let's assume for a moment that stationary-device location is indeed  
tremendously valuable. If so, we'll very quickly get a budding  
entrepreneur that will get the location from the access provider and  
then sell it, once, to the customer, for free use henceforth until  
the customer changes ISPs. Heck, depending on pricing, the customer  
might do it himself. I'd look forward to the having the access  
provider sue this enterprise for handing a customer their own street  
address. ("Yes, your honor, we don't allow this company to tell our  
customer where they live.")

Maybe Domino's will advertise "Get your free serving of location with  
our extra large pepperoni pizza!".

Thus, this whole hide-location-from-customer thing has the distinct  
feeling of cutting off your nose to spite your face or, more to the  
topic, of "I can't make VoIP pay for me, so I'm going to make it  
difficult for everybody else to offer services, too".

Location information is obviously valuable for mobile users, but I  
suspect that the consequence of making it difficult to get will  
simply increase the use of (unassisted) GPS and SkyHook, or BlueTooth  
on in-car navigation devices. (As navigation functionality gets  
integrated into mobile phones, this has to work even when there is no  
cell coverage.)

While I doubt that this argument will suddenly convince the brilliant  
strategists in telecom companies, at least I'll have a convenient  
place to point to for an "I told you so" five years from now, or  
maybe a good place to be proven wrong while others cash in their  
stock options.

Henning

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 16 Apr 2007 12:14:26 -0400

Right.  Good summary.

However, because at least some networks have to get through Pay to Play,
we need to provide mechanisms that work.  

The proposal (access networks that want pay to play must provide LbyR,
PSAP URI and dialstrings seems a workable solution to those networks.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Monday, April 16, 2007 12:10 PM
> To: Henning Schulzrinne; Rosen, Brian
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
do
> maybe a good place to be proven wrong while others cash in their
------------------------------------------------------------------------
--
> ----------------------
------------------------------------------------------------------------
--
> ----------------------

---

From: Andrew Newton <[email-masked]>
Date: Mon, 16 Apr 2007 12:46:01 -0400

Using Martin's nice email to perhaps bring this thread back around to  
GEOPRIV and to quit dancing around the issue, has anyone actually  
asked us as part of requirements to hide location from the target?   
If so, who?  If not, why are we considering it?

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 12:54:11 -0400

Well, there was the note from DT, for example.

It raised this very issue.

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Monday, April 16, 2007 12:46 PM
> To: GEOPRIV WG
> Cc: ECRIT
> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
> doendpointcentric LCP without giving away the store
> 
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 12:53:46 -0400

> PSAP URI and dialstrings seems a workable solution to those networks.

This only works for stationary devices, barely, unless there's an  
event notification mechanism that updates that information,  
particularly the PSAP URL.

Otherwise, you have to rely on call-time queries, which significantly  
degrade reliability and performance. In that case, you're not  
providing a service that is equivalent and the customer pays for the  
provider's pay-to-play dreams with their life and property.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 16 Apr 2007 12:08:44 -0500

I really can't buy into the "significantly degrades
performance/reliability" argument.

Actually, I think that not doing it at call-initiation may cause the
more significant degradation.

It can't be assumed that the device "knows" that it's not mobile. As
Brian mentioned, using Ethernet on a mobile platform (camper, train,
plane...) make mobility invisible to the device.

I can't imagine any sensibly implemented wireline access location
technology that would impose anything more significant than sub-second
response for maximal accuracy. For mobile networks, it may take longer -
but it's exactly for mobile networks that it's preferable to determine
location as close as possible to call origination time (just as is done
in cellular today).

I suppose that BCP could state that, in the absence of an updated
location at the time of the call within the time required, the device
may use the last-known location. That is an optimization and not a
fundamental principle. A well defined fallback procedure should always
be in place.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, 17 April 2007 2:54 AM
To: Rosen, Brian
Cc: Dawson, Martin; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 16 Apr 2007 12:00:32 -0500

Absolutely - agreed. Now I've finally reached the top of the thread.
Here's my perspective:

* Devices and VSPs should be assumed to have *no* knowledge of the
emergency jurisdiction or the access networks - that includes their
preferred form of location presentation, whether signing is required,
and what rights/rules exist if dereferencing is to occur.

* The access network should be assumed to know what the local
jurisdiction expects, is able to do, and of course what the access
provider wants to do viz restricting availability of the location
information.

The corollary is that most of the responsibility for ensuring
interoperability of emergency services at the local level lies with the
access provider and the local emergency services provider(s). The device
needs to know how to find the LIS, ask for location suitable for
emergency use, get it to the LoST server and initiate the call with the
location information included.

While the LoST server could be part of the access, it certainly doesn't
have to be. There's nothing in LoST that makes the access provider the
most suitable entity to administer the server. I also agree that
conflating the emergency routing service with the location service is
unnecessary and would only reduce flexibility for different
jurisdictions. So let's try to avoid turning HELD into anything more
than a location protocol. (Somebody mentioned that adding configuration
information to a location protocol would be counter-productive. I
heartily agree, and think the converse applies. Sorry - I couldn't
resist that).

Implied in what I said above is the need for the LCP to support an
explicit request for the "emergency form" of location. HELD does have
that currently but in discussions with Martin T and James W, we think
this needs beefing up due to the "richness of the permutations" that can
be expected in different jurisdictions.

There are two other things that I would really appreciate being
considered and discussed:

* Re-evaluating the support of LbyR in the LoST query (since the device
cannot assume the form in which the access will provide location).

* Defining a method (BCP or otherwise) by which a VSP can determine at a
high level of granularity (I'd be happy with country code) what
jurisdiction the call is coming from. This is purely to support i2 type
architectures where it is the VSP responsibility to identify the correct
VPC. Without some kind of jurisdiction-indication, particularly when
location is provided as a reference, it will be difficult to support
global roaming for subscribers. As above, a VSP cannot be assumed to
have the right to do a dereference - the LIS may be in a completely
different country. For example, can a BCP for reference construction
include this consideration?

Cheers,
Martin

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Tuesday, 17 April 2007 2:14 AM
To: Dawson, Martin; Henning Schulzrinne
Cc: [email-masked]; [email-masked]
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do

Right.  Good summary.

Brian

do

---

From: Andrew Newton <[email-masked]>
Date: Mon, 16 Apr 2007 13:13:24 -0400

> Well, there was the note from DT, for example.

Refresh my caffeine-starved brain.  DT?

> It raised this very issue.

I'm getting the sense from this email thread that people do not  
believe it is a reasonable requirement for various reasons.  We are  
not obliged to accept everything thrown at us.

-andy

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 16 Apr 2007 13:19:22 -0400

If the LCP guys don't want to include a location URI and dialstring in a
response, then I think we need a new protocol to combine the LCP + LoST
response in a single query to the access network.

I don't have a problem with that, although it's just one more thing the
endpoint has to implement.

I don't want to revisit LoST dereference of LbyR.  As we said, the LoST
server may be operated by lots of different entities and I don't want to
have to tie them into an authorization mechanism for dereferencing.  In
fact, I really want to make sure that operationally, whether it's the
endpoint, the access network or the VSP that is doing the LoST dip, I
want it to work everywhere.  

I do think having country code visible is a good thing.  I have two
reasons (validation and disputed territory).  You add a third.  I think
we need to make sure country code is visible.  That is a change.

It's true that the access network has more of a responsibility to
support emergency calling in next generation networks.  The VSP (or its
equivalent, for example, an IM service provider), has to have a very low
level of responsibility, namely, routing a call to the PSAP.  We want
that to be true primarily because of the difficulty in regulating
services providers across the Internet.  Access networks, after all, are
always local.  IM service providers and VSPs are not necessarily local,
but we want them to support emergency calling anyway.  We need to make
it as lightweight on them.

I recall asking a founder of Skype if the access network supplied
location, the route database was publically available on the Internet,
and the PSAP accepted SIP calls from the Internet if free Skype service
would support emergency calling.  His answer was very illustrative: "why
not?"  Not just "probably yes", not even just "yes" but "why not?".
That's the reaction we want.

I think most access networks will provide location for emergency calling
for the reason listed.  They really do think it is part of their
responsibility as a common carrier.  Local networks will support the
local emergency services.  That is as it should be.  The problem is that
we need ALL access networks to support local emergency calling.  The
"ALL" inevitably implies regulation.  In the IETF, we don't have to deal
with those issues, but our architecture is dependent on ALL.

Brian 

> Sent: Monday, April 16, 2007 1:01 PM
> To: Rosen, Brian; Henning Schulzrinne
do
do
> > In cellular networks, the location request associated with
initiating
> an

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 13:25:09 -0400

http://www1.ietf.org/mail-archive/web/ecrit/current/msg03352.html

> Sent: Monday, April 16, 2007 1:13 PM
> To: Brian Rosen
> Cc: 'GEOPRIV WG'; 'ECRIT'

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 16 Apr 2007 13:32:03 -0400

> It raised this very issue.

And they stated they have a solution.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 13:35:05 -0400

Location determination is not likely to be the major delaying factor,  
although it can be under the wrong circumstances. If there's even  
modest packet loss, any TCP connection establishment can be delayed  
significantly, due to the exponential backoff retry. We'd have to do  
2 such lookups (L7 and LoST), plus DNS to resolve the LoST-returned  
URL. Thus, we're talking roughly 10 round trip times (2 handshakes  
for TCP, 2 query/response for LoST and L7, plus one round trip for  
DNS). The initial TCP timeout is 500 ms, if I recall correctly and so  
is the DNS timeout, both with exponential backoff.)

I'm particularly concerned with mass casualty events, where the  
infrastructure is under duress.  Most of the time, none of this will  
be problem; however,  even with modest packet loss rates, there will  
be a significant fraction of calls experiencing delays of one or more  
seconds, which are indeed significant based on the performance  
requirements we were given by the PSAP community.

The critical timing is determining rough location and the URL lookup;  
this can all be done ahead of the call with no loss of accuracy.  
Thus, delaying PSAP URI determination until call time will indeed  
degrade the timeliness of emergency calls.

Henning

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 16 Apr 2007 13:35:27 -0400

I asked for it. I believe Otmar asked for it, also. I don't think I can
get my company to support this architecture if hiding location from
endpoints isn't an option.
Barbara

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 12:46 PM
To: GEOPRIV WG
Cc: ECRIT
Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to

-andy

> I think the first phase is likely to prove quite short, to non- 
> existent, because of the cost of putting the billing overlay in.
>

> broadband Internet access who can work out location (it's not like 
> it's a business conspiracy) and, eventually, this will become an 
> assumed part of the access bundle.
>
> In cellular networks, the location request associated with initiating 
> an emergency call is called a "network initiated" request because the 
> "mobile-originated". It's quite likely that any suitably capable 
> handset can request location, unhindered, from those mobile networks. 
> That's control plane - but SUPL permits SET-initated requests as well.
>
> their own processes and come to their own conclusions but I don't 
> think you'll be suffering stock option envy on this count Henning.
>
> Cheers,
> Martin
>
>
> [This is partially an editorial, but I'll get to solutions in the next

> message...]
> As a practical matter, monetizing this information is going to be very

> difficult, particularly in European Union countries with strong 
> as it has no direct need for it. The local pizza parlor might find the

> information to be of interest, but the logistics are pretty daunting. 
> Since you can't easily do per-use approval, as you can do with end 
> system location, the pizza parlor would have to contact the various 
> access providers and negotiate an arrangement. In addition, and most 
> onerously, the pizza parlor would probably need to get individual 
> approval from each potential customer to release this information to 
> them. As a customer, why would I agree to release location information

> to every business, known and unknown, for purposes unknown? This can 
> be fixed by uploading GEOPRIV policy to the access provider, but this 
> requires heavy-duty machinery, as customers have to figure out which 
> domains to include in that list.
> then sell it, once, to the customer, for free use henceforth until the

> customer changes ISPs. Heck, depending on pricing, the customer might 
> do it himself. I'd look forward to the having the access provider sue 
> this enterprise for handing a customer their own street address. 
> ("Yes, your honor, we don't allow this company to tell our customer 
> where they live.")
>
> suspect that the consequence of making it difficult to get will simply

> increase the use of (unassisted) GPS and SkyHook, or BlueTooth on 
> in-car navigation devices. (As navigation functionality gets 
> place to point to for an "I told you so" five years from now, or maybe

> a good place to be proven wrong while others cash in their stock 
> options.
>
> Henning
>
> This message is for the designated recipient only and may contain 
> privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender immediately

> and delete the original.  Any unauthorized use of this email is 
> prohibited.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 13:35:59 -0400

Okay, let's look at this.

For fixed devices, the PSAP URI doesn't change often, the cached value is
very likely to be good.  However, it MIGHT change on short notice.  The call
time query fixes this, if it works.

For mobile devices, the endpoint may get a reference.  The REFERENCE doesn't
change.  It's good for a long time (probably as long as the carrier -
subscriber relationship holds).  If it gets a value, then it wants an update
when it moves beyond the PSAP boundary.  With a value, it queries LoST and
gets the boundary, then passes that to its location determination mechanism
and asks for a notification when it moves beyond that.

The above, of course, is fairly far from what IMS currently talks about, but
that is what the IETF ecrit/presence architecture would say.

If the access network plays cozy with the location, so it passes a reference
and a PSAP URI, then it needs a way to TELL the device when the PSAP URI is
no longer valid.  Perhaps we could define a SIP event package for this
purpose, so a LIS could notify an endpoint of a new PSAP URI when its
current location warranted that.  I suppose this is a presence thing, and
maybe we could tie this more strongly into the existing presence system.

Brian

> Sent: Monday, April 16, 2007 12:54 PM
> To: Rosen, Brian
> Cc: [email-masked]; Dawson, Martin; [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 13:48:47 -0400

We have such a mechanism, in progress at least: The SIP configuration  
framework (see http://tools.ietf.org/html/draft-ietf-sipping-config- 
framework-11). It supports SIP-based event notifications for  
configuration updates. As I said in an earlier message, re-inventing  
a subset of the configuration framework just for this purpose seems  
counterproductive.

---

From: Andrew Newton <[email-masked]>
Date: Mon, 16 Apr 2007 15:07:51 -0400

> endpoints isn't an option.

Barbara,

Can we get a clarification?  Is there a technical reason not to  
support this architecture?  If so, can we be informed as to what it is?

Also, by "this architecture", you are talking about an ECRIT  
architecture, not a GEOPRIV architecture, correct?

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 18 Apr 2007 02:51:47 -0500

The circumstances you detail are more likely to have an impact on the
ability to make calls at all. Significant congestion or disruptions to
quality of service in the access network are likely to render media
streams inoperative before they break the simple act of location
retrieval.

There is an analog in cellular. Mass-calling events arising from
significant localized emergency events cause congestion in the serving
cells of those networks as well. Before they do that, however, they
cause congestion at the serving PSAP(s).

Cheers,
Martin 

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, 17 April 2007 3:35 AM
To: Dawson, Martin
Cc: Rosen, Brian; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do

Henning

On Apr 16, 2007, at 1:08 PM, Dawson, Martin wrote:

> ----------------------------------------------------------------------

> --------------------------
> ----------------------------------------------------------------------

> --------------------------
> [mf2]
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 18 Apr 2007 02:54:40 -0500

I certainly think that it's most optimal to get both location and PSAP
URI at the time of the call. I don't think anyone has suggested that the
PSAP URI should be provided "by reference" (right?) - it pretty much is
a reference anyway...

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, 17 April 2007 3:36 AM
To: 'Henning Schulzrinne'; Rosen, Brian
Cc: [email-masked]; Dawson, Martin; [email-masked]
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to

For fixed devices, the PSAP URI doesn't change often, the cached value
is
very likely to be good.  However, it MIGHT change on short notice.  The
call
time query fixes this, if it works.

For mobile devices, the endpoint may get a reference.  The REFERENCE
doesn't
change.  It's good for a long time (probably as long as the carrier -
subscriber relationship holds).  If it gets a value, then it wants an
update
when it moves beyond the PSAP boundary.  With a value, it queries LoST
and
gets the boundary, then passes that to its location determination
mechanism
and asks for a notification when it moves beyond that.

The above, of course, is fairly far from what IMS currently talks about,
but
that is what the IETF ecrit/presence architecture would say.

If the access network plays cozy with the location, so it passes a
reference
and a PSAP URI, then it needs a way to TELL the device when the PSAP URI
is
no longer valid.  Perhaps we could define a SIP event package for this
purpose, so a LIS could notify an endpoint of a new PSAP URI when its
current location warranted that.  I suppose this is a presence thing,
and
maybe we could tie this more strongly into the existing presence system.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 07:32:47 -0400

Congestion at the PSAP is much less likely in next generation emergency
calling networks.  They will be designed to handle this kind of event much
better than current ones.  Calls will be able to be answered by other PSAPs.
The goal is to build the networks such that in events larger than the
"Katrina" disaster, all calls can be answered.  Conventional networks may
indeed congest, and of course IP networks can congest.  We will have
capacity for tens of thousands of calls to be answered simultaneously.  That
is millions per hour.  All networks have limits, and these will too, but
they will be orders of magnitude larger than they are now.

Whether, and in what conditions, these facilities are used will be local
decisions, but the networks will be designed to be able to answer every call
that gets to the emergency services IP network.

The emergency services networks will have call admission controls, and the
media capacity will figure into these admission controls.  We would like
DiffServ marking of emergency calls, and slight priority over normal network
traffic for them, but don't expect that most access networks would provide
that.

Brian

> Sent: Wednesday, April 18, 2007 3:52 AM
> To: Henning Schulzrinne
> Cc: [email-masked]; Rosen, Brian; [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Apr 2007 07:33:59 -0400

Yah, the PSAP URI is "by value" as much as any URI is by value.

Brian

> Sent: Wednesday, April 18, 2007 3:55 AM
> To: Brian Rosen; Henning Schulzrinne; Rosen, Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Apr 2007 13:38:22 +0200

I am sure that someone will sooner or late get the idea that it would be 
nice not to disclose the URI of the PSAP and hence we should just return 
a reference to it.

Ciao
Hannes

Rosen, Brian wrote:
>> URI at the time of the call. I don't think anyone has suggested that
>>     
> the
>   
>> PSAP URI should be provided "by reference" (right?) - it pretty much
>>     
> is
>   
>> a reference anyway...
>>
>> Cheers,
>> Martin
>>
>> very likely to be good.  However, it MIGHT change on short notice.
>>     
> The
>   
>> call
>> The above, of course, is fairly far from what IMS currently talks
>>     
> about,
>   
>> but
>> and a PSAP URI, then it needs a way to TELL the device when the PSAP
>>     
> URI
>   
>> is
>> maybe we could tie this more strongly into the existing presence
>>     
> system.
>   
>> Brian
>>
>>
>>
>>     
>>>> The proposal (access networks that want pay to play must provide
>>>>         
>> LbyR,
>>     
>>>> PSAP URI and dialstrings seems a workable solution to those
>>>>         
>> networks.
>>     
>>> Otherwise, you have to rely on call-time queries, which
>>>       
> significantly
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 07:52:44 -0400

Actually, that is why the ESRP is there.  It can obscure what PSAP actually
gets the call.

The argument that PSAPs want security by obscurity in this way has been
asserted many times in NENA meetings.  I have went so far as to get up in
the front of the room with hundreds of technical and operational (NENA
TDC/ODC general sessions) and ask if there were any PSAP people who believed
this to please see me privately and explain.  I have NEVER talked or heard
of a PSAP who believed that his service area was a secret, or that some
hiding of which calls go to them would be valuable.

Now, several VENDORS asserted this was true, but so far, that assertion is,
from my point of view, baseless.

This gives rise to what the "PSAP URI" coming out of LoST when an ESRP is
used really is.

One possibility is:
sip:[email-masked]

Another possibility is:
sip:[email-masked]

In both cases, the esrp in New York state gets the call first.  In the
former, the esrp may need a LoST dip to determine which PSAP gets the call.
In the latter, some policy decisions would need to be made, and in some
circumstances a LoST dip, but in normal circumstances, the Buffalo, NY PSAP
gets the call.

Brian

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 7:38 AM
> To: Rosen, Brian
> Cc: Dawson, Martin; Brian Rosen; Henning Schulzrinne; [email-masked];
> [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 08:32:34 -0400

That is not true. You can still have an audio call at 10% packet  
loss, but you'll get a significant probability of the delays I  
mentioned at that point. During periods of stress, the more  
transactions you need to do, the higher the overall probability of  
failure. You might want to try this in a test bed with a loss  
emulator before making claims.

The whole idea of going IP is to distribute the load among lots of  
PSAPs if there is a regional crisis, such as an earthquake or hurricane.

We've discussed and had rough consensus on this long ago, so I'm  
surprised this comes up again. Maybe it's just convenient to ignore  
when it doesn't fit the agenda of hiding location.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 05:10:57 -0500

So you're claimimg you can have massive disruption to the access network
that won't impact calling capability but will destroy the simple task of
requesting location? I find that illogical.

This is all I'm talking about - I'm not criticizing IP in general...

And the utopian future of fully interconnected self-healing PSAP
networks is some way off at this stage. It's nice, but I'm not pinning
any present day plans on it. Another thing to consider is that in the
US, with 6000 plus PSAPs with an average seat size of five operators,
has up to 30,000 call takers on duty at any given time. In countries
with centralized call centers, the per capita representation of
operators is orders of magnitude less. I think there are subscribers on
this list from the UK industry who could confirm the numbers. I recall
there are actually only as many as 200 call takers on duty in the UK.
That's less than one percent of the available call taker population for
one fifth of the overall population compared to the US... I wonder
whether the long term trend in the US (which is just one of the markets
after all) won't be a consolidation of PSAP resources once the
architecture can support it...

All of that is an aside - I definitely think that getting location at
the time of making the call is the most optimal. It is the method used
in cellular and there is no evidence that location retrieval has been an
impediment to call delivery.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, 18 April 2007 10:33 PM
To: Dawson, Martin
Cc: Rosen, Brian; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do

Henning