Subject: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Apr 2007 07:18:00 -0400

In the Emergency Services SDO Coordination workshop, a familiar
discussion took place: how does location get provided for emergency
calls?  The real issue is revenue.  Access networks have location.  They
may be willing to (or may be regulated to be required to) provide
location for emergency calls.  However, they are not willing to give it
away for free for other uses.  The issue with that is how we support
calling networks that don't have relationships with access networks,
i.e. the Skype situation.  How is location provided such that a Skype
emergency call can be placed, but the access network can restrict what
else may be done with the location it provides?

We have been wrapped around the axle on this for, dare I say, years.

So, I think Barbara Stark first described this, and it needs some work,
but suppose that, as an option, an access network could supply:

1. A reference to location

2. The results of a LoST query on the location value (viz, PSAP URI and
local dialstring)

With this, an endpoint could recognize an emergency call and start
routing it to the right PSAP.  The LIS would agree to dereference for
PSAPs, but could restrict other uses of location.

Hannes points out that we need one more thing: the calling network has
to be able to validate that the PSAP URI really is a PSAP URI so that
charging (emergency calls generally are free) is protected.  We need a
mechanism for them to do that.  

Perhaps we include in the LoST return a country code for a query with a
geo.  We add a new operation to LoST that takes a service, a country
code and a PSAP URI and returns yes/no validation ("Yes, that URI is a
valid URI for that service in that country").

What would we need to do to make this happen?

We need extensions to LCPs or some new protocol that returns an LbyR and
the LoST results.  I wonder if this is just more HELD work.

We need the PSAP URI validation.

Again, this is optional.  The access network may well give up an LbyV.
It may give up an LbyR that it will dereference for the endpoint.  The
access network may have a relationship with the calling network such
that the endpoint need not be involved.

The PSAP URI validation is actually useful without this idea, especially
when location is an LbyR.  Instead of having to have the calling network
dereference, and then do a LoST query to validate, it can just do this
PSAP URI validation.

Would this solve our problem?  Would access carriers concerned about
revenue issues with "giving away" location to it's subscribers be
willing to provide LbyR dereferenceable by PSAPs (again remembering that
the access network are local to the PSAPs) as well as LoST query
services to their endpoints?  Would this address the concerns raised by
Deutsche Telecom on this issue?

Let me be very clear that I think this is an ugly solution.  I think
that everyone will be much better off if endpoints knew where they were,
and apps could take advantage of that.  I think we'll get there.  I
think tying location configuration with the LoST query is a bad idea.  I
think using LbyR for emergency calls is a bad idea.

But I can live with it.

Brian

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 16:43:15 +0200

Hi Brian,

thanks for posting this message.

When the end host is provided with LbyV and triggers the LoST lookup and 
routes the call via its VSP then the VSP (in some circumstances*) might 
want to verify that the PSAP URI in the message indeed corresponds to a 
PSAP. The idea that was mentioned a long time ago already was to let the 
VSP to use the location information for LoST and to compare the result 
with the content of the message.

The main goal here is that the VSP does not need to have a "business" 
contract to the ASP/ISP.

Since there is only a location reference that neither the end host nor 
the VSP can dereference it is necessary to enhance the existing 
procedures a bit (as Brian mentioned).

I see two ways todo so:

a) Enhance LoST
b) Enhance the dereferencing protocol

In both cases you want to have the LbyR as input and the PSAP URI (and 
potentially the service number) as output.

For (a) you would have to address the LoST query to the LoST server in 
the ASP/ISP network and the result would be a nomal LoST response.
For (b) you would have todo a dereferencing step with an additional 
parameter for "verify only". The response would be similar to the lookup 
by the end host -- just the identity that is being used for the lookup 
would be different.

Both approaches are possible and since the VSP has to support both 
protocols it does not make a big difference which one to use.

In both cases you would have to compare the result of the lookup with 
the content of the message.

Ciao
Hannes

*: It is only necessary when the VSP charges for individual calls or for 
specific calls (with the given call falling into this category).

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Apr 2007 10:51:56 -0400

Hannes

I am confused by your message.

The problem you describe, where a VSP is trying to validate that the
Request URI in what is claimed to be an emergency call is a bona fide
PSAP URI seems to be a valid concern.  My message described one way to
do this validation when what the VSP received (in a SIP Geolocation
header) is an LbyR.

Are you now wondering how you validate when you have an LbyV?  I would
think you do the same thing: send the country code (or the whole
location) and the PSAP URI to LoST and ask if the PSAP URI is valid.
This does not require any query by the VSP to the ASP/ISP.  The VSP
should be able to query its local LoST server and be referred to the
authoritative server for the location it proffers.

I'd rather not have to have the VSP try to dereference an LbyR, and if
you have an LbyV then you don't even know, necessarily, who the ASP/ISP
is.

Is there something else I'm missing here?

Brian
> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Friday, April 13, 2007 10:43 AM
> To: Rosen, Brian
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint
centric
> LCP without giving away the store
> 
> Hi Brian,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 17:25:39 +0200

Hi Brian,

I only described a different way of doing the verification without 
returning a country code.
I also focus on LbyR only rather than LbyV.

Ciao
Hannes

Rosen, Brian wrote:
>> When the end host is provided with LbyV and triggers the LoST lookup
>>     
> and
>   
>> routes the call via its VSP then the VSP (in some circumstances*)
>>     
> might
>   
>> want to verify that the PSAP URI in the message indeed corresponds to
>>     
> a
>   
>> PSAP. The idea that was mentioned a long time ago already was to let
>>     
> the
>   
>> parameter for "verify only". The response would be similar to the
>>     
> lookup
>   
>> *: It is only necessary when the VSP charges for individual calls or
>>     
> for
>   
>>> calls?  The real issue is revenue.  Access networks have location.
>>>       
> They
>   
>>> location for emergency calls.  However, they are not willing to give
>>>       
> it
>   
>>> i.e. the Skype situation.  How is location provided such that a
>>>       
> Skype
>   
>>> emergency call can be placed, but the access network can restrict
>>>       
> what
>   
>>> So, I think Barbara Stark first described this, and it needs some
>>>       
> work,
>   
>>> 2. The results of a LoST query on the location value (viz, PSAP URI
>>>       
> and
>   
>>> local dialstring)
>>>
>>> routing it to the right PSAP.  The LIS would agree to dereference
>>>       
> for
>   
>>> Hannes points out that we need one more thing: the calling network
>>>       
> has
>   
>>> to be able to validate that the PSAP URI really is a PSAP URI so
>>>       
> that
>   
>>> charging (emergency calls generally are free) is protected.  We need
>>>       
> a
>   
>>> Perhaps we include in the LoST return a country code for a query
>>>       
> with a
>   
>>> code and a PSAP URI and returns yes/no validation ("Yes, that URI is
>>>       
> a
>   
>>> We need extensions to LCPs or some new protocol that returns an LbyR
>>>       
> and
>   
>>> Again, this is optional.  The access network may well give up an
>>>       
> LbyV.
>   
>>> It may give up an LbyR that it will dereference for the endpoint.
>>>       
> The
>   
>>> The PSAP URI validation is actually useful without this idea,
>>>       
> especially
>   
>>> when location is an LbyR.  Instead of having to have the calling
>>>       
> network
>   
>>> dereference, and then do a LoST query to validate, it can just do
>>>       
> this
>   
>>> PSAP URI validation.
>>>
>>> willing to provide LbyR dereferenceable by PSAPs (again remembering
>>>       
> that
>   
>>> services to their endpoints?  Would this address the concerns raised
>>>       
> by
>   
>>> that everyone will be much better off if endpoints knew where they
>>>       
> were,
>   
>>> think tying location configuration with the LoST query is a bad
>>>       
> idea.  I
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 13 Apr 2007 12:04:19 -0400

Huh, I didn't get that.

I'd like to eliminate the country code thing, because otherwise we need a
way to carry it in the SIP Geolocation.  However, I don't really want the
VSP having to ask the ASP/ISP for a dereference of any sort, and I'd like to
minimize the work of the ASP/ISP.  The notion that the ASP/ISP has to help
the VSP determine if what it has is a valid PSAP URI strikes me as a
problem.

Now, you may remember WAAAY WAAY back, I strongly suggested that the geo
form of location always include a country code.  I suggested this for
disputed areas.  The access network is in a very good position to tell you
how best to interpret which country actually is the on-the-ground
administrator of the location.  If you are connected to an Israeli access
network, and you ask LoST for a PSAP URI, you probably want an Israeli fire
brigade.  If you are on a Palestinian access network, then you probably want
a different answer.  So, having country code in a PIDF with an otherwise geo
location is actually helpful.

The current answer for this is some kind of manual configuration of the LoST
servers so you get the answer you want.  While that can work, I think
something more automatic might work better, and it fixes the problem.

Brian

> Sent: Friday, April 13, 2007 11:26 AM
> To: Rosen, Brian
> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do
> endpoint centric LCP without giving away the store
> 
> Hi Brian,
> 
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2007 12:44:50 -0400

Brian,

I think that you're right that provision of location by reference is a 
use case we need to support.

URI validation will be useful in either case (LbyR or LbyV), and it 
seems like a natural extension to make to LoST:  Validating that a given 
URI is a PSAP URI is like a reverse DNS lookup. Normal DNS queries map 
names->addresses (A+ records); reverse DNS queries map addresses to 
names (*PTR records).  Likewise, LoST queries map locations (+service 
URNs) to URIs; a "reverse LoST" query could map a URI to a service area 
and a service URN.  There's probably even simpler approaches, maybe via 
some form of NAPTR or ENUM lookup.

As far as getting the endpoint the results of a LoST query based on an 
LbyR:  Your suggestion is good, but it has the problem that the access 
network doesn't really know what to fill in for the <service/> element 
of the LoST query.  It could request all of the services available, but 
that would require a second LoST request.

I would suggest that a more elegant solution (and one that deals better 
with the "unknown <service/>" problem) would be to extend LoST to handle 
location by reference.  It wouldn't be a complicated  change to LoST, 
just another location profile.  Realizing that this has been discussed 
in the past, I scanned through the archive and found two main arguments 
against LoST doing LbyR:

1. Dereference access control
In order to do the LoST lookup, a LoST server would have to be allowed 
to dereference the location reference.  Given that most of the LoST 
infrastructure (e.g. the trees) is pretty static, it doesn't seem 
difficult to provide authentication credentials for LoST servers and 
require that they be able to dereference (just like PSAPs).

2. Extra time/complication
It's correct that it would not be feasible for every LoST server 
involved in an LbyR-based query to dereference the location reference. 
However, this can be avoided if the resolver doing the recursive queries 
is allowed to do a dereference, since it can then just include the 
location by value in subsequent queries.  This may cover most cases, 
e.g., if a local LoST resolver is provided by the access network (as is 
often the case with DNS).

There's a lot of overlap between LoST/LbyR and what you propose.  If the 
access network provides a resolver, then the two are essentially the 
same, except that if LoST/LbyR is used, then the client sends an extra 
query.  However, extending LoST seems to maintain a better separation of 
the location configuration and mapping functions.

Humbly submitted,
--Richard

---

From: "Liess, Laura" <[email-masked]>
Date: Fri, 13 Apr 2007 18:48:48 +0200

Brian, Hannes,
thank you for bringing up this issue. 
In principle, I like the option for the access network to supply the PSAP URI. A similar option could be for the AN to provide an ESRP URI.  The ESRP URI is for the AN a trusted party, so it has the necessary credentials to fetch the Location Info from the LIS. 

I figured out how such a scenario could work

               Configuration           VSP's         	            LoST
       Alice      Servers      	  SIP proxy	    ESRP          Servers          PSAP

     ***Alice gets IP-connectivity****        
      [M1]   DHCP (with LbyR, country code and ESRP URI)
         <---------

     ***Some time later, Alice dials/initiates emergency call***
      [M2] INVITE (sos URN or 911/112, contains LbyR, country code and ESRP URI)
         ------------------------------->
                               [M3] LoST Query (contains country code and ESRP URI)
                                         --------------------------->
                               [M4] LoST Response (contains a mark if ESRP URI is valid)
                                        <----------------------------
                                        [M5] INVITE (sos URN or 911/112, contains LbyR)
                                         ------------->
                         [M6] HTTPS(contains LbyR)
                    <----------------------------------
                          [M7] HTTPS(contains Location)
                     --------------------------------->
                                                  [M8] LoST Query (contains Location)
                                                   --------------------->
                      		            [M9] LoST Response (contains PSAP URI) 
                                                  <----------------------
                                                  [M10] INVITE (contains Location)
                                                   ----------------------------------->
                                                          200 OK
         <-------------------------------------------------------------------------------
                                    ACK
         ------------------------------------------------------------------------------->

I think if there is a local ESRP between the VSP's SIP Proxy and the PSAP we are more flexible to comply to country-specific regulations. 
The ESRP could choose the PSAP based on a local LoST server which knows the capabilities of the local PSAPs. E.g. during a transition period we may have the old PSTN PSAPs and very few IP PSAPs with additional capabilities, e. g. emergency call takers speaking foreign languages or  emergency call takers for deaf people. The local LoST server would be able to choose the right PSAP (this is just an idea, I don't know whether or not it's realistic). 

Thanks
Laura

> -----Ursprüngliche Nachricht-----
> Von: Rosen, Brian [mailto:[email-masked]] 
> Gesendet: Freitag, 13. April 2007 13:18
> An: [email-masked]
> Cc: [email-masked]
> Betreff: [Ecrit] Not-so-grand compromise on how to do 
> endpoint centric LCPwithout giving away the store
> 
> 
> In the Emergency Services SDO Coordination workshop, a 
> familiar discussion took place: how does location get 
> provided for emergency calls?  The real issue is revenue.  
> Access networks have location.  They may be willing to (or 
> may be regulated to be required to) provide location for 
> emergency calls.  However, they are not willing to give it 
> away for free for other uses.  The issue with that is how we 
> support calling networks that don't have relationships with 
> access networks, i.e. the Skype situation.  How is location 
> provided such that a Skype emergency call can be placed, but 
> the access network can restrict what else may be done with 
> the location it provides?
> 
> So, I think Barbara Stark first described this, and it needs 
> some work, but suppose that, as an option, an access network 
> could supply:
> 
> 2. The results of a LoST query on the location value (viz, 
> PSAP URI and local dialstring)
> 
> With this, an endpoint could recognize an emergency call and 
> start routing it to the right PSAP.  The LIS would agree to 
> dereference for PSAPs, but could restrict other uses of location.
> 
> Hannes points out that we need one more thing: the calling 
> network has to be able to validate that the PSAP URI really 
> is a PSAP URI so that charging (emergency calls generally are 
> free) is protected.  We need a mechanism for them to do that.  
> 
> Perhaps we include in the LoST return a country code for a 
> query with a geo.  We add a new operation to LoST that takes 
> a service, a country code and a PSAP URI and returns yes/no 
> validation ("Yes, that URI is a valid URI for that service in 
> that country").
> 
> We need extensions to LCPs or some new protocol that returns 
> an LbyR and the LoST results.  I wonder if this is just more 
> HELD work.
> 
> Again, this is optional.  The access network may well give up 
> an LbyV. It may give up an LbyR that it will dereference for 
> the endpoint.  The access network may have a relationship 
> with the calling network such that the endpoint need not be involved.
> 
> especially when location is an LbyR.  Instead of having to 
> have the calling network dereference, and then do a LoST 
> query to validate, it can just do this PSAP URI validation.
> 
> Would this solve our problem?  Would access carriers 
> concerned about revenue issues with "giving away" location to 
> it's subscribers be willing to provide LbyR dereferenceable 
> by PSAPs (again remembering that the access network are local 
> to the PSAPs) as well as LoST query services to their 
> endpoints?  Would this address the concerns raised by 
> Let me be very clear that I think this is an ugly solution.  
> I think that everyone will be much better off if endpoints 
> knew where they were, and apps could take advantage of that.  
> I think we'll get there.  I think tying location 
> configuration with the LoST query is a bad idea.  I think 
> using LbyR for emergency calls is a bad idea.
> 
> But I can live with it.
> 
> Brian
>

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 13 Apr 2007 13:22:52 -0400

Who is responsible for PSAP mis-routes?  I would think this transfers
liability for routing to the access-provider, are they willing to step up to
that?

-Marc-

> From: Rosen, Brian [mailto:[email-masked]] 
> Sent: Friday, April 13, 2007 7:18 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ecrit] Not-so-grand compromise on how to do 
> It may give up an LbyR that it will dereference for the 
> endpoint.  The access network may have a relationship with 
> the calling network such that the endpoint need not be involved.
>

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 13 Apr 2007 10:58:17 -0700

3GPP approaches this in a different way - one which (I think) we could
parallel, as shown in the following diagrams:

Proposal: 

- Define a new function which handles location dereferencing and
supports lost queries (this seems to me to be somewhat similar to an LRF
in 3GPP, since an LRF goes and gets loc + routing).
- LoST doesn't need to change, (except maybe in the validation bits -
which I still don't understand).
- run by the Access Network (therefore Access Network has controls)

     +------+           +------+
     |  LS  |           | LoST |
     |      |           |      |
     |      |           |      |
     +------+           +------+
          \              /
           \ LCP (n/c)  / LoST Protocol (n/c)
            \          /
              +------+ 
              | ULS  |    New, URI-Loc-Server - logically in Access
Network
              |      |
              |      |
              +------+
             /        
            /          
           /            
     +------+           +------+
     |  UA  |           |  P1  |
     |      |-----------|      |
     |      |           |      |
     +------+           +------+

1. Endpoint accessed model

     +------+           +------+
     |  LS  |           | LoST |
     |      |           |      |
     |      |           |      |
     +------+           +------+
          \              /
           \ LCP (n/c)  / LoST Protocol (n/c)
            \          /
              +------+ 
              | ULS  |    New, URI-Loc-Server - logically in Access
Network
              |      |
              |      |
              +------+
                      \
                       \
                        \
     +------+           +------+
     |  UA  |           |  P1  |
     |      |-----------|      |
     |      |           |      |
     +------+           +------+

2. Proxy accessed model

Summary:
Neither of these scenarios preclude LbyV direct UA or Proxy interaction,
if desirable, and (in my mind) don't impact (much) existing protocols.

-roger marshall.

>From: Richard Barnes [mailto:[email-masked]] 
>Sent: Friday, April 13, 2007 9:45 AM
>To: Rosen, Brian
>Subject: Re: [Ecrit] Not-so-grand compromise on how to do 
>endpoint centricLCP without giving away the store
>
>Brian,
>
>I think that you're right that provision of location by 
>reference is a use case we need to support.
>
>URI validation will be useful in either case (LbyR or LbyV), 
>and it seems like a natural extension to make to LoST:  
>Validating that a given URI is a PSAP URI is like a reverse 
>DNS lookup. Normal DNS queries map 
>URNs) to URIs; a "reverse LoST" query could map a URI to a 
>service area and a service URN.  There's probably even simpler 
>approaches, maybe via some form of NAPTR or ENUM lookup.
>
>LbyR:  Your suggestion is good, but it has the problem that 
>the access network doesn't really know what to fill in for the 
><service/> element of the LoST query.  It could request all of 
>the services available, but that would require a second LoST request.
>
>I would suggest that a more elegant solution (and one that 
>deals better with the "unknown <service/>" problem) would be 
>to extend LoST to handle location by reference.  It wouldn't 
>be a complicated  change to LoST, just another location 
>profile.  Realizing that this has been discussed in the past, 
>I scanned through the archive and found two main arguments 
>against LoST doing LbyR:
>
>In order to do the LoST lookup, a LoST server would have to be 
>allowed to dereference the location reference.  Given that 
>most of the LoST infrastructure (e.g. the trees) is pretty 
>static, it doesn't seem difficult to provide authentication 
>credentials for LoST servers and require that they be able to 
>dereference (just like PSAPs).
>
>It's correct that it would not be feasible for every LoST 
>server involved in an LbyR-based query to dereference the 
>location reference. 
>However, this can be avoided if the resolver doing the 
>recursive queries is allowed to do a dereference, since it can 
>then just include the location by value in subsequent queries. 
> This may cover most cases, e.g., if a local LoST resolver is 
>provided by the access network (as is often the case with DNS).
>
>There's a lot of overlap between LoST/LbyR and what you 
>propose.  If the access network provides a resolver, then the 
>two are essentially the same, except that if LoST/LbyR is 
>used, then the client sends an extra query.  However, 
>extending LoST seems to maintain a better separation of the 
>location configuration and mapping functions.
>
>Humbly submitted,
>--Richard
>
>
>
>Rosen, Brian wrote:
>> They may be willing to (or may be regulated to be required 
>to) provide 
>> it away for free for other uses.  The issue with that is how we 
>> support calling networks that don't have relationships with access 
>> networks, i.e. the Skype situation.  How is location provided such 
>> that a Skype emergency call can be placed, but the access 
>network can 
>> restrict what else may be done with the location it provides?
>> 
>> work, but suppose that, as an option, an access network could supply:
>> 
>> and local dialstring)
>network has 
>query with 
>> a geo.  We add a new operation to LoST that takes a service, 
>a country 
>> and the LoST results.  I wonder if this is just more HELD work.
>> 
>endpoint.  The 
>> especially when location is an LbyR.  Instead of having to have the 
>> calling network dereference, and then do a LoST query to 
>validate, it 
>> can just do this PSAP URI validation.
>> 
>> that the access network are local to the PSAPs) as well as 
>LoST query 
>> by Deutsche Telecom on this issue?
>> 
>> were, and apps could take advantage of that.  I think we'll 
>get there.  
>> I think tying location configuration with the LoST query is a bad 
>> idea.  I think using LbyR for emergency calls is a bad idea.
>> 
>> But I can live with it.
>> 
>> Brian
>> 

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 20:33:12 +0200

How would the message exchange look like?

Roger Marshall wrote:
>>> routing it to the right PSAP.  The LIS would agree to 
>>>       
>> dereference for 
>>     
>>> to be able to validate that the PSAP URI really is a PSAP 
>>>       
>> URI so that 
>>     
>>> charging (emergency calls generally are free) is protected.  
>>>       
>> We need a 
>>     
>>> code and a PSAP URI and returns yes/no validation ("Yes, 
>>>       
>> that URI is a 
>>     
>>> Again, this is optional.  The access network may well give 
>>>       
>> up an LbyV.
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 20:34:29 +0200

Hi Laura,

in some sense your proposal is similar to use a SIP proxy in the access 
network (or someone that is closely related to it). Couldn't we just use 
the DHCP discovery technique for SIP proxies for that purpose?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 20:45:52 +0200

Hi Brian,

sorry that I confused everything. Maybe I am still suffering from a 
post-SDO Emergency Service Workshop syndrome:

Let me describe the procedure in a message sequence:

Target => LIS: Request  LbyR

Target<= LIS: LbyR, PSAP URI, Service Number

Target=> VSP-Proxy: SIP message including LbyR, PSAP URI

VSP-Proxy=> LIS: Check PSAP URI at LbyR

VSP-Proxy<= LIS: OK or NOT OK (LIS checks whether the location 
information behind the LbyR translates to the PSAP URI presented by the 
VSP-Proxy)

DONE

Note that yo can replace LIS with LoST server in this example.

Does this make sense to you?

Ciao
Hannes

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2007 14:55:03 -0400

What's the protocol between the UA/P1 and the ULS?  It needs to (1) 
carry LbyR to the ULS and a service URN to the ULS, and (2) return a 
LoST response to the UA/P1.  LoST would be the natural candidate for 
this, if it could carry LbyR.

That said, I don't think that this model has any different requirements 
in terms of protocols, it just shifts the whole show off the endpoint 
into the ULS.  And I thought the whole point of Brian/Barbara's 
suggestion was to allow for access-controlled location while keeping 
positioning local to the endpoint.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 13 Apr 2007 15:11:09 -0400

I think that is part of the tradeoff an access network makes.  If its
restricting access to location, and location is needed to route, then it has
to assume the liability for misroute, since it's providing the route in lieu
of providing location for the VSP to route.

If it doesn't want to assume that liability, then it has to give location to
someone who does the route, and we're back around that axle again.

So, I think it's reasonable that the access network deal with misroutes in
this case.

Brian

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Friday, April 13, 2007 1:23 PM
> To: 'Rosen, Brian'; [email-masked]
> Cc: [email-masked]
> Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do
> endpointcentric LCPwithout giving away the store
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 13 Apr 2007 15:15:06 -0400

I'm not sure there is a whole lot of difference to extending the LCP to
supply the route data (or, if you like Richard's proposal, to allow the
route protocol to do the dereference) and inventing a new protocol to do
both.  I don't really care all that much, since the message sequences would
look the same (you send your identifiers in, like you would with an LCP, and
you get back the LbyR and the LoST result).

If you don't understand the validation bits (which allow a VSP, who cannot
dereference) to make sure that the PSAP URI which the endpoint is routing
towards, really is a PSAP URI, ask a question :)

Brian

> From: Roger Marshall [mailto:[email-masked]]
> Sent: Friday, April 13, 2007 1:58 PM
> To: Richard Barnes; Rosen, Brian
> The information contained in this message may be privileged and/or
> confidential. If you are not the intended recipient, or responsible for
> delivering this message to the intended recipient, any review, forwarding,
> dissemination, distribution or copying of this communication or any
> attachment(s) is strictly prohibited. If you have received this message in
> error, please so notify the sender immediately, and delete it and all
> attachments from your computer and network.
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2007 15:15:08 -0400

Hannes,

I think you're trying to enable the PSAP to answer the wrong question. 
There are two questions that one can ask about a call:
(1) Is this a valid PSAP URI for this Location (byR)?
(2) If this URI a valid PSAP URI?

It seems like answering question (2) provides enough information to make 
charging decisions, and it doesn't require dereferencing a location. 
Which is nice for several reasons, including that there's no interaction 
needed between the VSP and the ASP/ISP.

Also, note that for mobile targets, question (1) can become false while 
the call is being routed if the target crosses a PSAP boundary.

--Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2007 21:15:13 +0200

I also believe that this is reasonable assumption with regard to the 
split of responsibilities in this particular case.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 13 Apr 2007 15:21:36 -0400

ESRPs URIs are just PSAP URIs as far as anyone outside the Emergency
Services IP Network is concerned.  What you get out of LoST is an ESRP URI
or a PSAP URI, and which you get depends on the local emergency authority's
wishes.   We don't need to know, and we don't do anything different.

Within the ESInet, the ESRP may well use LoST to do further routing.  In
North America, we imagine a common arrangement would be that a regular user
query to LoST would yield an ESRP URI that was roughly operated at the state
level -- all calls from Virginia go to a (replicated, load balanced) ESRP.
The ESRP may do a further LoST dip, and take into account local conditions,
like congestion and PSAP state, and time of day, and decide which PSAP will
actually get the call.

This is invisible to the endpoint, the access network and the VSP.  It's all
in what LoST returns.

So I don't think we need to specify how ESRPs work.  I think the important
part for you is that the access network would trust the ESRP for a
dereference the same as it would trust a PSAP.  In North America, they would
probably have similar credentials.

Brian

> From: Liess, Laura [mailto:[email-masked]]
> Sent: Friday, April 13, 2007 12:49 PM
> To: [email-masked]; [email-masked]
> Subject: AW: [Ecrit] Not-so-grand compromise on how to do endpoint
> centricLCPwithout giving away the store
> 
> 
> Brian, Hannes,
> In principle, I like the option for the access network to supply the PSAP
> URI. A similar option could be for the AN to provide an ESRP URI.  The
> ESRP URI is for the AN a trusted party, so it has the necessary
> credentials to fetch the Location Info from the LIS.
> 
>        Alice      Servers      	  SIP proxy	    ESRP
Servers
> PSAP
>                       		            [M9] LoST Response
(contains
> PSAP URI)
> I think if there is a local ESRP between the VSP's SIP Proxy and the PSAP
> we are more flexible to comply to country-specific regulations.
> The ESRP could choose the PSAP based on a local LoST server which knows
> the capabilities of the local PSAPs. E.g. during a transition period we
> may have the old PSTN PSAPs and very few IP PSAPs with additional
> capabilities, e. g. emergency call takers speaking foreign languages or
> emergency call takers for deaf people. The local LoST server would be able
> to choose the right PSAP (this is just an idea, I don't know whether or
> not it's realistic).
> 
> 
> Thanks
> Laura
> 
> 
> 
> 
> 
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2007 15:24:54 -0400

I would state things more generally: If you're going to restrict access 
to location information, then you bear liability for failures resulting 
from that restriction.

That way, if the AN provides routing, then it's responsible for routing 
working correctly.  If the AN wants to out-source mapping , then it's 
responsible for mapping failures caused by the mapping function not 
having access to location -- but NOT other mapping failures, like a bad 
cached mapping.

--Richard

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 13 Apr 2007 15:35:42 -0400

Deb

There is a tradeoff here between providing some kind of location when,
for whatever reason, you can't get current location at the time of the
call, and the cost of engaging the location determination mechanism.
Once at boot and periodically thereafter is not going to be a problem
for measurement systems that provide constant high quality measurements.
It's much more of a problem for the current crop of mobile networks that
can only provide a coarse location quick, and take much more time (and
expend more resources) to get an accurate location.

In such networks, what you get from the boot and periodically thereafter
queerly is the coarse location, which is by definition fast, and usually
low resource consumption.  Of course, it also could be a location
reference, which doesn't typically change, but even if it did (as it
might when changing visited networks), and it would be available
instantly, with no resource expenditure.  The visited network could
quite easily cache the LoST route for the coarse location, so that
wouldn't be much work either.

Brian

> From: Barclay, Deborah L (Deb) [mailto:[email-masked]]
> Sent: Friday, April 13, 2007 12:08 PM
> To: Rosen, Brian; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Ecrit] Not-so-grand compromise on how to do endpoint
centric
> LCPwithout giving away the store
> 
> Hi Brian,
> 
> The ecrit bcp recommends obtaining location on power-up/registration
and
> then refresh often/occasionally.
> 
> That means endpoints may obtain location frequently but never use it
for
> an emergency call.
> 
> I thought business models often worked on a pay per dip basis.
> 
> For cellular endpoints, network based and network assisted position
> determination are very complex and resource intensive - requiring
> auxiliary equipment for position determination.
> 
> Due to the impact on network resources, I'm not sure obtaining
position
> whenever requested and never being charged will be a viable model for
> some technologies.
> 
> Deb
> 
> Sent: Friday, April 13, 2007 6:18 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ecrit] Not-so-grand compromise on how to do endpoint centric
> LCPwithout giving away the store
> 
They
it
work,
and
and
especially
network
that
by
were,

---

From: "Liess, Laura" <[email-masked]>
Date: Fri, 13 Apr 2007 23:17:03 +0200

Hannes,

I didn't mean the ERSP being in the access network, but rather what Brian describes in his answer, ESRPs operated at country or state level. Depending on the granularity of ESRPs, they could be configured into the access network data (e.g. if they are operated at country level)or the access network can do LoST queries. 

("Local ESRP" was probably quite misleading.) 

Laura

 -----Ursprüngliche Nachricht-----
> Von: Hannes Tschofenig [mailto:[email-masked]] 
> Gesendet: Freitag, 13. April 2007 20:34
> An: Liess, Laura
> Cc: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: AW: [Ecrit] Not-so-grand compromise on how to do 
> endpoint centricLCPwithout giving away the store
> 
> 
> Hi Laura,
> 
> > In principle, I like the option for the access network to 
> supply the PSAP URI. A similar option could be for the AN to 
> provide an ESRP URI.  The ESRP URI is for the AN a trusted 
> party, so it has the necessary credentials to fetch the 
> Location Info from the LIS. 
> >
> >                Configuration           VSP's         	
>             LoST
> > I think if there is a local ESRP between the VSP's SIP 
> Proxy and the 
> > PSAP we are more flexible to comply to country-specific regulations.
> > The ESRP could choose the PSAP based on a local LoST server 
> which knows the capabilities of the local PSAPs. E.g. during 
> a transition period we may have the old PSTN PSAPs and very 
> few IP PSAPs with additional capabilities, e. g. emergency 
> call takers speaking foreign languages or  emergency call 
> takers for deaf people. The local LoST server would be able 
> to choose the right PSAP (this is just an idea, I don't know 
> whether or not it's realistic). 
> >
> >
> > Thanks
> > Laura
> >
> >          
> >     
> >
> >    
> >
> >
> >

---

From: "Liess, Laura" <[email-masked]>
Date: Sat, 14 Apr 2007 00:04:08 +0200

Brian,

I agreee with you.  And I think this is a model that almost everyone can live with. We just need a way to convey the PSAP/ESRP URI from the access network to the client. 
Something like draft-polk-dhc-uri-03.txt? But the document is currently expired.  

Laura

> Von: Brian Rosen [mailto:[email-masked]] 
> Gesendet: Freitag, 13. April 2007 21:22
> An: Liess, Laura; Rosen, Brian; [email-masked]
> Betreff: RE: [Ecrit] Not-so-grand compromise on how to do 
> endpointcentricLCPwithout giving away the store
> 
> 
> ESRPs URIs are just PSAP URIs as far as anyone outside the 
> Emergency Services IP Network is concerned.  What you get out 
> of LoST is an ESRP URI or a PSAP URI, and which you get 
> depends on the local emergency authority's
> Within the ESInet, the ESRP may well use LoST to do further 
> routing.  In North America, we imagine a common arrangement 
> would be that a regular user query to LoST would yield an 
> ESRP URI that was roughly operated at the state level -- all 
> calls from Virginia go to a (replicated, load balanced) ESRP. 
> The ESRP may do a further LoST dip, and take into account 
> local conditions, like congestion and PSAP state, and time of 
> day, and decide which PSAP will actually get the call.
> 
> This is invisible to the endpoint, the access network and the 
> VSP.  It's all in what LoST returns.
> 
> So I don't think we need to specify how ESRPs work.  I think 
> the important part for you is that the access network would 
> trust the ESRP for a dereference the same as it would trust a 
> PSAP.  In North America, they would probably have similar credentials.
> 
> Brian
> 
> supply the 
> > PSAP URI. A similar option could be for the AN to provide 
> an ESRP URI.  
> > The ESRP URI is for the AN a trusted party, so it has the necessary 
> >       [M2] INVITE (sos URN or 911/112, contains LbyR, 
> country code and 
> > ESRP URI)
> >                                [M3] LoST Query (contains 
> country code 
> > and ESRP URI)
> >                                          
> >                                [M4] LoST Response (contains 
> a mark if 
> > ESRP URI is valid)
> >                                         
> >                                                   [M10] INVITE 
> > Location)
> > The ESRP could choose the PSAP based on a local LoST server which 
> > knows the capabilities of the local PSAPs. E.g. during a transition 
> > period we may have the old PSTN PSAPs and very few IP PSAPs with 
> > additional capabilities, e. g. emergency call takers 
> speaking foreign 
> > languages or emergency call takers for deaf people. The local LoST 
> > server would be able to choose the right PSAP (this is just 
> an idea, I 
> > don't know whether or not it's realistic).
> > 
> > 
> > Thanks
> > Laura
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > Betreff: [Ecrit] Not-so-grand compromise on how to do endpoint 
> > > centric LCPwithout giving away the store
> > >
> > >
> > > They may be willing to (or may be regulated to be required to) 
> > > provide location for emergency calls.  However, they are 
> not willing 
> > > to give it away for free for other uses.  The issue with 
> that is how 
> > > we support calling networks that don't have relationships with
> > > for PSAPs, but could restrict other uses of location.
> > >
> > > has to be able to validate that the PSAP URI really is a 
> PSAP URI so 
> > > that charging (emergency calls generally are
> > > with a geo.  We add a new operation to LoST that takes a 
> service, a 
> > > country code and a PSAP URI and returns yes/no validation ("Yes, 
> > > that URI is a valid URI for that service in that country").
> > >
> > > LbyV. It may give up an LbyR that it will dereference for the 
> > > endpoint.  The access network may have a relationship with the 
> > > calling network such that the endpoint need not be involved.
> > >
> validate, 
> > > it can just do this PSAP URI validation.
> > >
> concerned about 
> > > that the access network are local to the PSAPs) as well as LoST 
> > > query services to their endpoints?  Would this address 
> the concerns 
> > > raised by Deutsche Telecom on this issue?
> > >
> > > were, and apps could take advantage of that. I think we'll get 
> > > there.  I think tying location configuration with the 
> LoST query is 
> > > a bad idea.  I think using LbyR for emergency calls is a bad idea.
> > >
> > > But I can live with it.
> > >
> > > Brian
> > >

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 14 Apr 2007 18:02:00 +0200

Hi Brian,

~snip~
> valid URI for that service in that country").

Please describe when the country code is returned and to whom.
Who triggers the validation step?

Ciao
Hannes

---

From: "Raymond Forbes \(CV/ETL\)" <[email-masked]>
Date: Sat, 14 Apr 2007 19:13:53 +0200

In many areas, especially Mobile Networks Country codes are not
reliable.

Geneva is a good case. Most calls originated by Non-Swiss mobiles in
Geneva are actually made on the French networks and so will get the
Country Code +33 of the base station on the surrounding Mountains, the
French authorities have no jurisdiction to enter Switzerland even in the
case of Emergencies.

True because of Cross-boarder agreement on this friendly boarder region
the French PSAPs will forward the calls to Switz PSAPs. 

I am sure that what Brian says may be reasonable from fixed access, but
not from Radio Access, radio has no respect for artificial political
boundaries.

Regards, 

Ray Forbes

BU Networks (CV/ETL/BBC/D)
Telephone: +44 (0) 24 7656 3106 
Mobile: +44 (0) 771 851 1361

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 13 April 2007 17:04
To: 'Hannes Tschofenig'; Rosen, Brian
Cc: [email-masked]; [email-masked]
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
doendpoint centric LCP without giving away the store

Huh, I didn't get that.

I'd like to eliminate the country code thing, because otherwise we need
a way to carry it in the SIP Geolocation.  However, I don't really want
the VSP having to ask the ASP/ISP for a dereference of any sort, and I'd
like to minimize the work of the ASP/ISP.  The notion that the ASP/ISP
has to help the VSP determine if what it has is a valid PSAP URI strikes
me as a problem.

Now, you may remember WAAAY WAAY back, I strongly suggested that the geo
form of location always include a country code.  I suggested this for
disputed areas.  The access network is in a very good position to tell
you how best to interpret which country actually is the on-the-ground
administrator of the location.  If you are connected to an Israeli
access network, and you ask LoST for a PSAP URI, you probably want an
Israeli fire brigade.  If you are on a Palestinian access network, then
you probably want a different answer.  So, having country code in a PIDF
with an otherwise geo location is actually helpful.

The current answer for this is some kind of manual configuration of the
LoST servers so you get the answer you want.  While that can work, I
think something more automatic might work better, and it fixes the
problem.

Brian

> > Request URI in what is claimed to be an emergency call is a bona 
> > fide PSAP URI seems to be a valid concern.  My message described one

> > way to do this validation when what the VSP received (in a SIP 
> > Geolocation
> > header) is an LbyR.
> >
> > Are you now wondering how you validate when you have an LbyV?  I 
> > would think you do the same thing: send the country code (or the 
> > whole

> > I'd rather not have to have the VSP try to dereference an LbyR, and 
> > if you have an LbyV then you don't even know, necessarily, who the 
> > ASP/ISP is.
> >
> >> VSP to use the location information for LoST and to compare the 
> >> result with the content of the message.
> >>
> >> Since there is only a location reference that neither the end host 
> >> nor the VSP can dereference it is necessary to enhance the existing

> >> In both cases you want to have the LbyR as input and the PSAP URI 
> >> (and potentially the service number) as output.
> >>
> >> For (a) you would have to address the LoST query to the LoST server

> >> in the ASP/ISP network and the result would be a nomal LoST
response.

> >> by the end host -- just the identity that is being used for the 
> >> lookup would be different.
> >>
> >> In both cases you would have to compare the result of the lookup 
> >>> discussion took place: how does location get provided for 
> >>> emergency calls?  The real issue is revenue.  Access networks have
location.

> >>> that a

> >>> geo.  We add a new operation to LoST that takes a service, a 
> >>> that URI is
> >>> access network may have a relationship with the calling network 
> >>> such that the endpoint need not be involved.
> >>>
> >>> Would this solve our problem?  Would access carriers concerned 
> >>> about revenue issues with "giving away" location to it's 
> >>> subscribers be willing to provide LbyR dereferenceable by PSAPs 
> >>> (again remembering
> >>>
> > that
> >
> >>> Let me be very clear that I think this is an ugly solution.  I 
> >>> think that everyone will be much better off if endpoints knew 
> >>> where they
> >>>
> > were,
> >
> >>> and apps could take advantage of that.  I think we'll get there.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 10:58:25 -0400

The editorial out the way, I'll start by listing some requirements,  
some of which have been mentioned already:

- Hiding location should not make the PSAP behavior more costly and  
complicated or less reliable; in other words, just because an access  
provider choses, for business reasons, to withhold location  
information from customers should not impose a burden on tax payers.

- Hiding location information by one provider should not impose a  
burden on those access providers that offer location information to  
their customers.

I think the framework document needs to clearly spell out the  
reliability and security considerations of such a choice. If nothing  
else, this will prove valuable to the trial lawyer that gets called  
when the first person gets hurt when location information is  
erroneously withheld from a PSAP.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 10:51:51 -0400

[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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 12:18:35 -0400

I'll try to summarize some solutions and pick apart the problem.

There seem to be two basic approaches:

(1) Provide only location information that is sufficient for call  
routing or possibly for obtaining the service number, but not for  
dispatch. The latter is included by a PSAP-only LbyR. This would  
remove a large part of the value of the address to pizza parlors, but  
would not interfere with our standard architecture. It would provide  
the user with some ability to verify his own address, albeit only  
partially. (This is one of the reliability drawbacks of the withhold- 
location-information approaches, which is going to be a major cause  
of dispatch problems, I suspect.)

The biggest problem is determining this minimal address information,  
but this isn't too hard, given the availability of LoST service  
region information.

(2) Provide only the PSAP URL and LbyR resolvable by the PSAP.

Only (2) requires additional work. From what I can tell, the  
following solutions have been proposed:

(a) Include in configuration protocols, such as DHCP.

(b) Include in location configuration protocols, such as L7 LCP.

(c) Include in a special LoST response, e.g., if the client provides  
no location information.

All of these have problems:

- DHCP: Since this is configuration information, adding a lot of  
extra material to DHCP seems ill-advised, particularly since the  
likelihood that this information actually reaches residential users  
is slim. After all, this motivated the whole L7-LCP discussion. This  
also has problems if the URL needs to be changed since the INFORM  
request expiration doesn't seem to be tied to the IP address  
expiration. The number of URLs could be substantial, given that we  
need more than one emergency service URL and that we may need service  
testing URLs.

- L7 LCP: This subverts a location determination protocol into a  
general configuration protocol.

- LoST: This seems closest to our existing notion of returning a  
'default' PSAP if no other resolution is possible. Nothing prevents  
an ISP-provided LoST client from using whatever information it has  
available, such as client IP addresses, to make this information  
better than a national call center.

If we go down this route, I think a better solution is to use the on- 
going work for SIP configuration mechanisms. One of the sources of  
configuration information is the local access network, so it has all  
the right properties. After all, emergency calling URLs are not  
fundamentally different from other configuration information for  
special servers. Plus, the configuration protocol will likely have  
mechanism of dealing with conflicting information. The more protocols  
you add, the higher the likelihood that a device will get conflicting  
information, with no deterministic way to resolve it.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 13:46:38 -0400

I think this is a separable topic, so I've changed the subject line  
and removed the GEOPRIV cc.

Also, this matters only if IP-to-IP calls are being charged for,  
which seems to be unusual for landline services at this point, to put  
it mildly. (If there's a PSTN gateway, it is presumably easy to keep  
a record of PSAP phone numbers, as such databases will need to be  
kept for other purposes.)

Thus, this may only be required for mobile calls using per-minute  
charging (as opposed to mobile calls using a data service charging  
model).

I'd also argue that this problem would likely best be solved by law  
enforcement, rather than through protocols. This is clear fraud, with  
a clearly-identified perpetrator, so it would seem highly unlikely  
that somebody would want to risk a criminal record to save a few  
cents on a phone call. (This is obviously not true for  
unauthenticated calls.)

That said, I think brute force is the best solution here. I'd hate to  
create an elaborate infrastructure for something that may not be all  
that important in the future. Another important requirement is that  
the list of valid URLs needs to be automatically synchronized with  
the LoST records. We really want to avoid the case of having to  
maintain separate databases for the inverse mapping, simply because  
they'll invariably get out of sync, with possibly catastrophic  
consequences.

If we assume a country-level mechanism, the number of PSAP URLs is  
modest. The largest number would likely be the US, with roughly 6000.  
Figure about 50 bytes for the URL, so we're talking a total data  
volume of 300,000 bytes. The change frequency in that URL list is  
likely to be modest, with maybe a few changes each day. Thus, a  
flooding mechanism seems sufficient, using the synchronization tools  
that draft-schulzrinne-ecrit-lost-sync offers (with probably one  
additional flag if a server is only interested in the URLs, without  
the service region). Since the synchronization mechanism supports  
push, new URLs can propagate rapidly to resolvers. You'd

For higher efficiency and lower risk of inadvertent refusal, one  
might consider keeping partial URLs in the list, so that an entry of  
"emergency.nj.us" would match "sip:[email-masked]" or  
any other URL with that suffix. However, that makes indexed searches  
very difficult and seems more hassle than it's worth, given the  
trivial data volume. It also makes it harder to automatically derive  
this information within an authoritative LoST server.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 16:55:57 -0400

> allowed to dereference the location reference.  Given that most of  
> the LoST infrastructure (e.g. the trees) is pretty static, it  
> doesn't seem difficult to provide authentication credentials for  
> LoST servers and require that they be able to dereference (just  
> like PSAPs).
>

Unfortunately, every resolver and forest guide would have to  
dereference. Resolvers and forest guides will be operated by numerous  
entities, including companies. There is no trust relationship between  
the Columbia LoST resolver (VSP, in my case) and the access provider.  
If any resolver can get the location information, you might as well  
hand it out to the client to begin with. Saves you the extra effort.

Thus, this is a non-starter.

> involved in an LbyR-based query to dereference the location  
> reference. However, this can be avoided if the resolver doing the  
> recursive queries is allowed to do a dereference, since it can then  
> just include the location by value in subsequent queries.  This may  
> cover most cases, e.g., if a local LoST resolver is provided by the  
> access network (as is often the case with DNS).

In many cases, the LoST resolver will be provided by the VSP,  
including non-traditional VSPs. Are you suggesting we restrict the  
LoST architecture to cater to this particular need?

I thought we agreed that the business practices of some ISPs should  
not burden the rest of the infrastructure?

>
> There's a lot of overlap between LoST/LbyR and what you propose.   
> If the access network provides a resolver, then the two are  
> essentially the same, except that if LoST/LbyR is used, then the  
> client sends an extra query.  However, extending LoST seems to  
> maintain a better separation of the location configuration and  
> mapping functions.
>
> Humbly submitted,
> --Richard

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 14 Apr 2007 19:03:47 -0500

There is potentially one other thing that springs to mind, and that is a
specific sos domain. If that were done, then the resulting URI itself
would be explicit that it was for emergency services.

Just a thought.

Cheers
James

> Sent: Saturday, 14 April 2007 12:43 AM
> To: Rosen, Brian
> centricLCP without giving away the store
> 
> Hi Brian,
> 
and
might
a
the
lookup
for
They
it
Skype
what
work,
and
for
has
that
a
with a
a
and
LbyV.
The
especially
network
this
that
by
were,
idea.  I
> > think using LbyR for emergency calls is a bad idea.

------------------------------------------------------------------------------------------------
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]

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 14 Apr 2007 19:14:14 -0500

I agree.

Indirectly the access network is already assuming this responsibility
since it is providing location to the end-point in any case, either
directly or indirectly.

> Sent: Saturday, 14 April 2007 5:11 AM
> To: 'Marc Linsner'; Rosen, Brian; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to
> doendpointcentric LCPwithout giving away the store
> 
> restricting access to location, and location is needed to route, then
it
> has
> to assume the liability for misroute, since it's providing the route
in
> lieu
> If it doesn't want to assume that liability, then it has to give
location
> to
> > liability for routing to the access-provider, are they willing to
step
> up
> > to
LbyV.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 14 Apr 2007 20:21:26 -0400

Who would administer such a domain? At least in the US, there is no  
national authority for PSAPs. Given the PSAP-like semi-private  
emergency call centers on many corporate and university campuses,  
there is unlikely to be one.

(Yes, this particular solution was discussed, and dismissed, a few  
years ago. It might even have appeared in one of the early emergency  
I-Ds.)

Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 14 Apr 2007 19:23:21 -0500

I am fine with that, it was just a pie-in-the-sky.. ;)

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, 15 April 2007 10:21 AM
> To: Winterbottom, James
> Cc: GEOPRIV; ECRIT

---

From: "Marc Linsner" <[email-masked]>
Date: Sat, 14 Apr 2007 23:32:18 -0400

Brian,

You also realize that an emergency call is going to be routed using 'stale'
data.  We've always stated that routing at call time is optimal.  You are
prepared to give that up?

-Marc- 

> Sent: Friday, April 13, 2007 3:11 PM
> Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on 
> how to do endpointcentric LCPwithout giving away the store
> 
> I think that is part of the tradeoff an access network makes. 
>  If its restricting access to location, and location is 
> needed to route, then it has to assume the liability for 
> misroute, since it's providing the route in lieu of providing 
> location for the VSP to route.
> 
> If it doesn't want to assume that liability, then it has to 
> give location to someone who does the route, and we're back 
> around that axle again.
> 
> So, I think it's reasonable that the access network deal with 
> misroutes in this case.
> 
> Brian
> 
> > liability for routing to the access-provider, are they 
> willing to step 
> > up to that?
> > 
> > -Marc-
> > 
> > > Subject: [Ecrit] Not-so-grand compromise on how to do endpoint 
> emergency 
> > > calls?  The real issue is revenue.
> > > Access networks have location.  They may be willing to (or may be 
> > > regulated to be required to) provide location for 
> emergency calls.  
> > > However, they are not willing to give it away for free for other 
> > > uses.  The issue with that is how we support calling 
> networks that 
> > > don't have relationships with access networks, i.e. the Skype 
> > > situation.  How is location provided such that a Skype emergency 
> > > call can be placed, but the access network can restrict what else 
> > > may be done with the location it provides?
> > >
> endpoint.  
> > > The access network may have a relationship with the 
> calling network 
> > > I think that everyone will be much better off if endpoints knew 
> > > where they were, and apps could take advantage of that.
> configuration with 
> > > the LoST query is a bad idea.  I think using LbyR for emergency 
> > > calls is a bad idea.
> > >
> > > But I can live with it.
> > >
> > > Brian
> > >

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 14 Apr 2007 23:27:05 -0500

I am not so sure that this anymore the case than it would be with a
location value is it?

If the device is fixed, then the likelihood of change in low, but the
PSAP route could be tagged with an expiry the same as a literal location
can. So I think this is the same problem.

If the device is mobile then yes this does require an extra dip prior to
the mobile sending the initial invite, but the proxy doesn't have to the
LoST dip on the way, so the net result may be neutral depending on how
the proxy does URI checking etc.

I am not suggesting that this solution is optimal either, but like Brian
and I can live with it.

Cheers
James

> Sent: Sunday, 15 April 2007 1:32 PM
> To: 'Brian Rosen'
> Cc: [email-masked]
some
> > > > routing it to the right PSAP.  The LIS would agree to
dereference

---

From: "Marc Linsner" <[email-masked]>
Date: Sun, 15 Apr 2007 15:58:25 -0400

James,

> 
> I am not so sure that this anymore the case than it would be 
> with a location value is it?

No, if the client has LbyV, the client can do the LoST lookup at call time.

> 
> If the device is fixed, then the likelihood of change in low, 
> but the PSAP route could be tagged with an expiry the same as 
> a literal location can. So I think this is the same problem.

You are suggesting the host go back to the access network when setting up an
emergency call?

I wonder if a course location (enough to route properly) with LbyR embedded
in the LbyV would be better.

The access provider can take the fine grain location, perform a LoST lookup,
give the client only the tuples that LoST returned in the service boundary.
The client can then perform a LoST lookup anytime with that set of tuples.
If the client is fixed no need to contact the access network at emergency
call time.

I worry about too many dependencies at call time.

-Marc-

> 
> If the device is mobile then yes this does require an extra 
> dip prior to the mobile sending the initial invite, but the 
> proxy doesn't have to the LoST dip on the way, so the net 
> result may be neutral depending on how the proxy does URI 
> checking etc.
> 
> I am not suggesting that this solution is optimal either, but 
> like Brian and I can live with it.
> 
> Cheers
> James
> 
> > data.  We've always stated that routing at call time is 
> optimal.  You
> are
> > > do endpointcentric LCPwithout giving away the store
> > >
> > >  If its restricting access to location, and location is needed to 
> > > route, then it has to assume the liability for misroute, 
> since it's 
> > > providing the route in lieu of providing location for the VSP to 
> > > route.
> > >
> > > location to someone who does the route, and we're back 
> around that 
> > > axle again.
> > >

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 15 Apr 2007 17:29:36 -0500

Marc,

> Sent: Monday, 16 April 2007 5:58 AM
> To: Winterbottom, James
> Cc: [email-masked]
[AJW] This presupposes that the location has not changed. If the
location has changed then this doesn't help unless the client also
requests a new location at call time. In this case I put to you that
there is no difference in the number of queries performed.

> You are suggesting the host go back to the access network when setting
up
> an

[AJW] Local network hit is likely to be faster than a wide-area network
hit.

> in the LbyV would be better.

[AJW] Hmmm, maybe. I would need to think about this one a bit more as I
am not sure that we can easily arrive at a solution to how coarse is too
coarse, or too fine.

> I worry about too many dependencies at call time.

[AJW] Agreed, but we need to allow people to deploy it also. Like most
things some ground in the middle will need to be found.

> > > You also realize that an emergency call is going to be routed
using
> > > 'stale'
> > > > > Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how
to
> > do
may
> > be
> > > > > > work, but suppose that, as an option, an access network
could
> > > > > > supply:
> > > > > > revenue issues with "giving away" location to it's
subscribers
> > be

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Apr 2007 21:46:09 -0400

I'll just add that you have to provide the client with rough location  
information ahead of time. Otherwise, it has no clue when to re-query  
LoST for an updated mapping. Rough location is better than no  
location - at least the call gets to the right PSAP. Having a  
location lookup fail completely at call time would likely cause the  
call to be routed to the wrong PSAP or, worst case, to some generic  
backup call center.

We have long had agreement that we want pre-call lookup to have at  
least some rough location and PSAP data. Why are we re-opening this  
debate?

Again, this reveals very little additional information to the client,  
as the client can already determine the tower ID today.

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 15 Apr 2007 22:04:09 -0500

Sorry Henning perhaps I wasn't being to clear as I was leveraging off
Brian's previous statement about changing the L7 LCP response type.

I would therefore return an expiry time for the created context that
applied equally to the LoST URI. That is the LIS would choose the
shortest of the two and provide that as the expiry time the end-point,
so when the end-point updates the context, it gets the new PSAP URI.
Does that make sense?

Cheers
James

> Sent: Monday, 16 April 2007 11:46 AM
> To: Winterbottom, James
> Cc: Marc Linsner; [email-masked]
> Subject: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to
> >> No, if the client has LbyV, the client can do the LoST lookup at
call
> >> time.
> >> The access provider can take the fine grain location, perform a
LoST
> >> lookup,

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Apr 2007 23:11:05 -0400

The whole idea of LoST caching is that is both time-based (typically,  
measured in days or months) and location-based. Thus, I don't see how  
your mechanism can work. Since there's no way to predict how fast  
somebody moves, you'd have to have very short expiration times, thus  
dramatically increasing the LoST query load. In our neighborhood, the  
PSAP coverage area is roughly a few miles, so at highway speed, so  
everybody would have to expire bindings every minute or two, even for  
the vast majority of vehicles that re-visit the same area again and  
again or stay within the same area.

This seems to exactly violate the stipulated "don't make others pay  
for your business plan" requirement.

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 15 Apr 2007 22:23:20 -0500

Please, this is not my business plan and never has been. I am only
trying to help move things forward. I must admit though that I don't
understand how this is any different to providing a location by value in
the same circumstance.

Your argument seems to be, you are moving super fast so the data that
you have is not right to make a call, go and get new data at call time.
It is not clear to me that there is a real difference between:

a) End-point going to the LIS getting updated data then end-point doing
LoST lookup and routing call and

b) End-point asking LIS for location, LIS doing LoST lookup and
returning PSAP URI to the end-point.

If the end-point is static, then both mechanisms are roughly equivalent
also.

I have no reason to hide location from the end-point, but the reality is
that some people want to do this. The number of lookup dips is the same
in both circumstances as best as I can tell.

Cheers
James

> Sent: Monday, 16 April 2007 1:11 PM
> To: Winterbottom, James

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Apr 2007 23:28:38 -0400

No, my note refers to the ability to cache data ahead of the call, as  
discussed as a requirement. The number of call-associated queries is  
much, much smaller than the pre-call queries, particularly if caching  
is "dumbed down" as you seem to suggest.

Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 15 Apr 2007 22:30:27 -0500

So that being the case, what is the objection?

> Sent: Monday, 16 April 2007 1:29 PM
> To: Winterbottom, James

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 16 Apr 2007 08:19:00 -0400

James, 

> > No, if the client has LbyV, the client can do the LoST 
> lookup at call 
> > time.
> > 
> [AJW] This presupposes that the location has not changed. If 
> the location has changed then this doesn't help unless the 
> client also requests a new location at call time. In this 
> case I put to you that there is no difference in the number 
> of queries performed.

I think we understand mobile clients.  Wrt: Fixed clients: The long-standing
requirement that a host perform a LoST query at emergency call time gets
uglier when that client has to go back to the access provider, who performs
the query for the client.  Too many messages/round trips.  Giving the fixed
client a rough location is better.

> [AJW] Local network hit is likely to be faster than a 
> wide-area network hit.

No hit to the local network is faster.

> 
> > 
> > I wonder if a course location (enough to route properly) with LbyR 
> > embedded in the LbyV would be better.
> >
> 

If the access provider performs a LoST query with the *real* location, they
will know which elements of the location object to pass to the client.

> things some ground in the middle will need to be found.

As long as the middle ground is deployable and works.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 08:22:27 -0400

I think there's a distinct danger of talking past each other after  
the third level of >>>, so maybe it's time to review and see where we  
diverge.

Assumption: Devices are mobile.

Requirement: Devices need to obtain PSAP URLs well ahead of a call,  
as part of normal configuration, even if there will be a LoST re- 
query at call time. (With the non-hiding model, this isn't really  
necessary as the mobile will have requeried if it has left the PSAP  
coverage area, so that it will always have correct and up-to-date  
PSAP information. Re-querying at call time only addresses the highly  
unlikely scenario that the LoST information itself has changed before  
the cache expiration time. This distinction seems to have gotten lost  
in the discussion.)

Model: #1 (location) Devices only obtain a (constant) location  
reference and "trade" this with a LoST server for a PSAP URL.

#2 (URL) Devices query for a PSAP URL.

In both #1 and #2, the mobile device has no idea when it leaves the  
coverage area of the PSAP, so either the configuration mechanism has  
to push a new PSAP URL to the mobile or the mobile has to re-query at  
high frequency, as it has no idea when it has left one PSAP coverage  
area and entered another. Thus, this dramatically increases the load  
on the LoST server (and the power consumption in the mobile).

Henning

---

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

Back from a weekend of no Internet access and lots of email to process:

The country code is returned from the L7 LCP query when an LbyR is returned.

The validation is done by the VSP when an emergency call is placed.

Brian

> Sent: Saturday, April 14, 2007 12:02 PM
> To: Rosen, Brian

---

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

Thank you for this reminder.

I don't think we have a real problem.  The call is going to be routed based
on the country of the location you have when you place the call.  That is
going to match the country code that we are using for the validation.  The
PSAP that gets the call may transfer it when the actual fine grained
location is determined, but that is after the call is routed.  This is all
about routing.  The entity returning the LbyR, the country code and the PSAP
URI is the access network.  It can keep the information consistent.

Even if the location were to change between the time the endpoint got the
data from its access network, and the time the VSP validated, the VSP isn't
getting updated location.  It's just validating that the PSAP URI it's
routing for is valid within the country that it's routing to.

If a bad guy could seed bad information in the worldwide LoST database, then
he could put his URI in there, and get calls.  I think we have to accept
this kind of problem.

We don't actually need the country code, and in fact perhaps we should
consider it a hint.  If there is a URI in the database that matches the
proffered URI, it's valid.  The country code just gives us a hint of where
to look.  We might want to recommend that the URIs belong to the country
where the URI is routed towards (eg psap.london.uk).  However, it works with
any URI.

Brian

> From: Raymond Forbes (CV/ETL) [mailto:[email-masked]]
> Sent: Saturday, April 14, 2007 1:14 PM
> To: Brian Rosen; Hannes Tschofenig; Rosen, Brian
> Cc: [email-masked]

---

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

I will make sure that we have a discussion of this in -framework.  I do
intend to note that LbyR is more fragile for emergency calls because the
dereference may not work in a disaster.  

The VSP who wishes to validate takes on responsibility for failure to
progress a valid call that fails validation for whatever reason.  

Brian

> Sent: Saturday, April 14, 2007 10:58 AM
> To: Rosen, Brian
> endpointcentric LCP without giving away the store
>

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 16 Apr 2007 10:04:40 -0400

Brian,

> 
> I will make sure that we have a discussion of this in 
> -framework.  I do intend to note that LbyR is more fragile 
> for emergency calls because the dereference may not work in a 
> disaster.  

Actually, it is possible that the dereference may not work in 'normal'
conditions.  Lots of machinery with that mechanism.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 10:09:40 -0400

> progress a valid call that fails validation for whatever reason.

Wouldn't that typically be the ISP doing the authorization? (I don't  
want to use the term validation, since we seem to use that for a  
different operation.)

Henning

---

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

> Sent: Saturday, April 14, 2007 12:19 PM
> To: Rosen, Brian
> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise [solutions]
> 
I think this is impossible for the U.S., where PSAP boundaries can be one
side of the street or another.

It works in many countries that don't have many PSAPs.

> need more than one emergency service URL and that we may need service
I think we all believe DHCP is only viable in fixed environments, but I use
the extreme example of a wired phone connected to a router with a wireless
access installed in an RV traveling down the highway as a counterexample.
Such situations exist, therefore it has to work, but they are unusual, so it
can be less than optimal.

In this case, we need DHCP responses that return LbyV and country code and
probably another that returns the LoST data.  I fail to see that as a major
deviation from what DHCP does.  The expiration is a red herring.  It won't
change much, and you do get it again at call time.

The number of URIs is an issue, and we may need to do something clever about
that.

However, I do suspect that the access network that does this will use the L7
LCP, and I don't think leaving DHCP out of this is a problem.

> general configuration protocol.
No it gives you information related to location (the PSAP URI associated
with this location.

> better than a national call center.
I think this is a poor choice because it has too many restrictions on who
operates the LoST server.  You would either require that the LoST server
operator be permitted to dereference, or the access network itself operates
the LoST server.  While that may be the case, it may not be and I don't see
why we should tie these together.

> information, with no deterministic way to resolve it.
Where did you make the leap that the Vonage configuration server knows
anything about the Comcast access network?

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Apr 2007 10:37:46 -0400

Maybe this has already been answered, but:

You update the data at call time.  You only use stale data if that doesn't
work.

Brian

> Sent: Saturday, April 14, 2007 11:32 PM
> To: 'Brian Rosen'
> Cc: [email-masked]
> Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 16 Apr 2007 10:41:58 -0400

Brian,

> 
> You update the data at call time.  You only use stale data if 
> that doesn't work.

Remind us of the goal for 'send button to ringback' timing, please?  2
seconds?

-Marc-

---

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

No, this was Hannes' problem.

The VSP wants to make sure that the PSAP URI is valid.

Brian

> Sent: Monday, April 16, 2007 10:10 AM
> To: Brian Rosen
> Cc: Rosen, Brian; [email-masked]; [email-masked]
> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 11:01:20 -0400

I thought we were talking primarily about residential wireline?

I don't think anybody is proposing that a wireless device  
continuously query for its own location. In many cases of interest,  
this is unnecessary since handsets have GPS built in. (As a side  
note, since navigation will become standard functionality on  
handsets, I have a hard time imagining how per-dip systems are going  
to compete.)

A much better solution for systems where location needs to be  
conveyed to the end system is to have location triggers, namely the  
ability of the handset to tell the network "notify me if I'm leaving  
this polygon". We have the necessary tools to do this, via SIP presence.

Henning

On Apr 13, 2007, at 12:07 PM, Barclay, Deborah L ((Deb)) wrote:

> Hi Brian,
>
> The ecrit bcp recommends obtaining location on power-up/ 
> registration and
> That means endpoints may obtain location frequently but never use  
> it for
> an emergency call.
>

---

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

Okay, this is a "have your cake and eat it too" situation.

If you want to restrict location, you have to take on the burden of
providing the PSAP URI (the route) for an emergency call.  This would change
only when the user changed something like cell site.  You need to make sure
the endpoint has this when it changes.  You can either keep the update
frequency high, or force it when cell site changes (the endpoints know
this).

The IMS solution, because it couples the access network with the calling
network can avoid this because it uses proxy adding of location.  However,
the general packet interfaces have to support emergency calling too, and
here the L7 LCP would have to support the PSAP URI.

Brian

> The ecrit bcp recommends obtaining location on power-up/registration and
> That means endpoints may obtain location frequently but never use it for
> an emergency call.
> 
> Due to the impact on network resources, I'm not sure obtaining position

---

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

Right, 2 seconds.

You query LCP (that is local).  Someone (endpoint or access network) queries
LoST (that is not real local, but not very far).  You route.  The VSP
validates (normally local, but may need a referral which could be to
anywhere, that may take time).

Then it rings.  

The dereference happens after the ring starts.

Brian

> Sent: Monday, April 16, 2007 10:42 AM
> To: 'Brian Rosen'
> Cc: [email-masked]

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 16 Apr 2007 12:10:05 -0400

Brian,

> 
> You query LCP (that is local).  Someone (endpoint or access 
> network) queries LoST (that is not real local, but not very 
> far).  You route.  The VSP validates (normally local, but may 
> need a referral which could be to anywhere, that may take time).
> 
> Then it rings.  
> 

Please explain 'local'.  What are you inferring?

-Marc-

---

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

The endpoint has a direct connection to the access network; very low
latency.

The LoST server may be local (because the access network has a replica), or
it may be a pretty direct connection (access network + 1-2 hops).  In most
networks, it won't even get outside the local Internet exchange point
(although some backhaul is inevitable).  A look at the Pittsburgh exchange
point for example shows all the big cable and LEC carriers have presence.

The VSP is querying a local-to-him LoST server.  That may not have the
actual answer to the query, and may have to refer.

Brian

> Sent: Monday, April 16, 2007 12:10 PM
> To: 'Brian Rosen'
> Cc: [email-masked]

---

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

The problem is that there are (and should be) many LoST resolvers,  
including those operated by a third party, neither the VSP nor ISP.  
Relying on some specific deployment combination seems unwise.

I agree that the LoST server will often be local.

---

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

If I were a VSP concerned with this problem, I wouldn't make the
validation sequential in the process. I would go ahead and route the
call and do the validation simultaneously. If it's really invalid, then
I charge for it, or maybe shut down the call. That depends on how big of
a problem this is. I would also probably cache valid emergency URIs, so
I can do the validation locally. But that's just me.
Barbara  

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 11:10 AM
To: 'Marc Linsner'
Cc: [email-masked]
Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to

Right, 2 seconds.

You query LCP (that is local).  Someone (endpoint or access network)
queries LoST (that is not real local, but not very far).  You route.
The VSP validates (normally local, but may need a referral which could
be to anywhere, that may take time).

Then it rings.  

Brian

> > You update the data at call time.  You only use stale data if that 
> > doesn't work.
> 

*****

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. GA624

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 14:22:52 -0400

[I think it would be helpful to align the subject with the topic at  
hand, as this is confusing enough already...]

While it is certainly a good idea to provide country information to  
the user, as that will also allow retrieval of the dial string using  
LoST and possibly a default if-all-else-fails "PSAP", I don't see  
this as necessary for checking whether a URL is a PSAP or not. As I  
mentioned before, the number of such URLs and the total data volume  
is so small that flooding this to all resolvers isn't a big problem.

If we don't want to flood, there are other mechanisms that can be  
used to efficiently determine where in the server hierarchy a URL  
might be. In particular, Bloom filters are a good way to do this.

Henning

On Apr 16, 2007, at 9:52 AM, Brian Rosen wrote:

>>>>>> access
>>>>>> start

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Apr 2007 21:52:40 -0400

[Removing items that we've beaten to death already.]

> change much, and you do get it again at call time.

I suspect you'll run into major objections, correctly, from the SIP  
community for replicating SIP configuration via DHCP. There are  
possible length issues, as one minor item, as you include a whole  
list of services. After all, this has to work for emergency and non- 
emergency LoST services. A bigger architectural issue is that if we  
do include PSAP URIs in the SIP configuration framework, we now have  
a fourth source of SIP-related configuration, which needs to be  
synchronized and conflict-tested.

> No it gives you information related to location (the PSAP URI  

By that token, *every* SIP configuration option is related to LCP and  
we might as well suggest that we replace the SIP configuration  
framework with LCP.

> why we should tie these together.

I'm not particularly fond of this choice, but others have proposed  
making the access provider LoST server "special" in that it can  
resolve LbyR location.

> anything about the Comcast access network?

I suspect you haven't been following this all that closely (which I  
sympathize with...), but consider taking a look at the configuration  
framework draft or review the recent SIPPING discussion on this  
topic. One of the sources of (SIP) configuration information is the  
access network.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Apr 2007 08:10:12 +0200

-- changed subject header

Hi Brian,

I just wanted to state that my proposal does not work (for deployment 
reasons) since the VSP would have a hard time figuring out whether the 
LIS is indeed at an access network. Demanding some relationship between 
the ASP/ISP and the VSP for authorization would make this solution to 
work but it would not be deployable anymore and that's what we do not want.

Ciao
Hannes

Hannes Tschofenig wrote:
> information behind the LbyR translates to the PSAP URI presented by 
> the VSP-Proxy)
>
> DONE
>
>>>>> nor
>>>>> (and

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Apr 2007 08:20:05 +0200

Hence, it suffers from the same problems as the solution I proposed 
unless you assume a relationship between the VSP and the ISP/ASP.
Do you?

Ciao
Hannes

---

From: Andrew Newton <[email-masked]>
Date: Tue, 17 Apr 2007 14:58:43 -0400

I agree with Barbara on this point.  A VSP can do policing after the  
fact.

But there is a tweak on this proposal I'd like to make.

An ISP or access network wishing to keep a target's location  
information out of the hands of the target can do the following (and  
this is similar to Brian's original message in this thread):  The  
access network provides to the client the following:

1) A reference to location.
2) The results of a LoST query, which are a PSAP URI, a LoST service  
boundary reference (instead of a country code), and the local  
dialstring.

So that the target does not get the location information, I believe  
this could all be implemented in the LIS without need for protocol  
change.  Essentially, the LIS knows something special about the  
target that enables it to know the target's location information.   
Why can't it also know not to all the target to dereference the  
LbyR?  So the target can convey the LbyR to the PSAP and the PSAP can  
dereference it, the target can never dereference it because the LIS  
knows who the target is and knows that it is not authorized to have  
it.  Doing so is a matter of local policy in the LIS.

Also, I'd like to be clear on something.  None of this or any of the  
alternatives discussed will preclude a network operator from  
deploying the standard architecture, right?

-andy

On Apr 16, 2007, at 1:41 PM, Stark, Barbara wrote:

> 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. GA624
>
>
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Apr 2007 16:03:07 -0400

No, I don't.

I assume that the LoST server the VSP consults to validate contains the same
URIs that the LoST server used by the access network LIS to determine the
URI.  The endpoint passes a URI to its VSP and claims it's a bona fide PSAP
URI from LoST.  As long as that URI is in the LoST server (directly or via a
referral) that the VSP uses, validation is possible.

If the attacker can insert bogus data into the global LoST database, then we
couldn't detect it, but that is not threat here.

The access network and the endpoint can collude all they want, but unless
the LoST server the VSP uses has bad data, it can determine if the PSAP URI
is a genuine PSAP URI.  

No relationship between the VSP and the access network is needed.

Brian

> Sent: Tuesday, April 17, 2007 2:20 AM
> To: Brian Rosen

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Apr 2007 16:49:34 -0400

I'm not sure I understand the boundary.  Since no one downstream of the LIS
can get the location other than the PSAP, the boundary can't be used for its
normal purpose.  

I think that the protocol changes Henning refers to are changes that allow
an endpoint to query with the LCPs identifiers and get back the LbyR, PSAP
URI, dial string and boundary/country code.  Neither LoST nor any LCP has
that operation so far.  I don't think we need anything special to prohibit
the endpoint from dereferencing; it would not have the credentials to
dereference, which the PSAP would.  I will note that if a LIS insists on
credentials, and some kind of failure occurs and the PSAP is not able to get
location, the LIS operator takes on some significant liability.

And, I definitely agree that an access network can supply an LbyV or an LbyR
that it will dereference for anyone and everything still works the way we
originally envisioned.  I even imagine some kind of tiered service the
access provider offers has which allows a subscriber to have pay-per-dip
dereferencing (for him or anyone else) or buck-a-month all-you-can-eat
dereferencing.  The LIS can hand out different kinds of references and keep
them straight itself.

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Tuesday, April 17, 2007 2:59 PM
> To: ECRIT
> Cc: Brian Rosen; Barbara Stark; Marc Linsner
> Subject: A slightly different take: RE: [Ecrit] Not-so-grand compromise on
> how to doendpointcentric LCPwithout giving away the store
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 17 Apr 2007 21:19:11 -0400

> can get the location other than the PSAP, the boundary can't be  

I don't follow what you are saying.  Note that I said "boundary  
reference", not boundary.  A VSP could validate the boundary  
reference, which would be far more specific than just a country code.

> that operation so far.

If we are to make protocol changes, I'd rather not stray too far.   
The behavior we need is simply this: LoST returns boundary references  
with mappings, and these boundary references are simply put into well- 
known SIP URI parameters (to be used by the VSP later).

To the client, the behavior is the same:

1) The client queries the LCP for location.
2) The LCP returns location that is very broad, perhaps just the  
country code.
3) The client gets configured with the LoST resolve of the access  
network.
4) The client queries LoST with its location.
5) The LoST resolver consults the LIS for the more specific location.
6) The LoST resolver then conducts the regular resolution.
7) The LoST resolver returns the normal answer to the client.
8) The client makes the call in the normal way.

The only change here is to LoST to include boundary references in  
mappings, and to the clients so that they know to pass those  
references to the VSP.

>   I don't think we need anything special to prohibit

What credentials would the PSAP have?  If we are talking about PKI,  
then I have a problem with that.  Having the LIS simply know not to  
allow a dereference by the target, of which it has a solid  
understanding who that is, should be enough.  And that requires  
absolutely no cross-domain coordination.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Apr 2007 22:04:17 -0400

> Sent: Tuesday, April 17, 2007 9:19 PM
> To: Brian Rosen
> Cc: 'ECRIT'; 'Barbara Stark'; 'Marc Linsner'
> Subject: Re: A slightly different take: RE: [Ecrit] Not-so-grand
> compromise on how to doendpointcentric LCPwithout giving away the store
> 
> 
The VSP doesn't have a location to verify a boundary.  The original proposal
was to reverse search the PSAP URI within a country.  The country is really
just a hint that may help the reverse search.  Henning argues we don't need
it at all, and he may be right.  You could try to make the LoST server
reverse search within a boundary, but I suspect that is a lot harder.  I
don't know why a reference is any more or less helpful than the actual
boundary.  

> mappings, and to the clients so that they know to pass those
I'm lost (pun, sorry).
Country codes aren't useful enough to pick a PSAP.  You know this, so I
don't understand what that location does, but I'm even more confused than
that.  In step 5 you have LoST querying the LIS.  That's a big step, and how
is it doing this?  With an LbyR?  So far, the LCP has a coarse LbyV.  See
how lost I am?

I really, truly don't understand the reluctance to simply combining a call
to an LCP with a call to a LoST resolver into one step.  It means the access
network is calling LoST instead of the client, but I think we're mostly
thinking the access network is pretty close to the LoST resolver, so that
should be a no brainer.

If you don't want to dirty the LCP protocol, we really can invent a new
combo protocol; it's no big deal, since it's mostly the query syntax of the
LCP with the return of the LCP+LoST as one data structure.    
> absolutely no cross-domain coordination.
Well, since the LIS and the PSAP are local to one another they could use
anything they agree to use.  The point of the LbyR is to control WHO can
dereference.  The access network is happy to have anyone dereference as long
as they pay for the privilege.  It WANTS the endpoint to give the LbyR to
anyone who wants it, to maximize it's revenue.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Apr 2007 22:19:35 -0400

> don't know why a reference is any more or less helpful than the actual

My sense is that there are no objections, on business model grounds,  
to at least provide the country information to the user agent. This  
would be somewhat helpful for the PSAP URL verification and, more  
importantly, for the dial string.

> to an LCP with a call to a LoST resolver into one step.  It means  

This means changing either LCP (probably both L7 and DHCP) or LoST.  
LCP is then really a configuration protocol. This means that the UA  
behavior has to change and get more complicated. I'm opposed to such  
hacks.

> thinking the access network is pretty close to the LoST resolver,  

There are going to many different LoST resolvers, operated by VSP,  
ISPs and independent third parties. Thus, you now have to pick just  
the right one to get good information. Yet another complication.

> LCP with the return of the LCP+LoST as one data structure.

I guess I have to keep repeating this for a while, but you're re- 
inventing SIP configuration. We really don't need two SIP  
configuration protocols and I will protest and raise a stink in  
SIPPING if we do.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Wed, 18 Apr 2007 00:07:22 -0400

Brian,

For some reason we seem to be miscommunicating, most likely because  
of the medium.  I'll try to clarify below.

> don't know why a reference is any more or less helpful than the actual

My point about the boundary reference is that it can be used to get a  
<mapping> from LoST.  If you point LoST client A at a LoST server and  
it gets back a boundary reference, that reference can the be handed  
to LoST client B who can use it to retrieve the very same <mapping>.   
Included in <mapping> is the PSAP URI.

If a VSP wants to validate that the URI it has been given is truly a  
PSAP URI, it can use the boundary reference to achieve the  
<mapping>.  That mapping should contain the very same PSAP URI.

> don't understand what that location does, but I'm even more  

I didn't explain that well.  In step 2, the LCP returns a place  
holder location.  It might as well say "planet Earth", but that isn't  
valid within the protocol schemas.  The point is, the client does not  
know that the location is just a place holder and treats it no  
differently.  By definition, this location information has not real  
meaning.

>   In step 5 you have LoST querying the LIS.  That's a big step, and  
> how

Note that in step 3, the LoST server that the client gets configured  
with resides in the access network.  It might as well be the LIS  
itself, just with a LoST interface.  Since the access network knows  
the location of the target, it can combine the LIS and LoST functions  
together.  It can also ignore the place holder location that will be  
given it by the client, because it knows the real location of the  
client... and that is what it will use for LoST.

> thinking the access network is pretty close to the LoST resolver,  

I think we are on the same page, just reading different paragraphs.

> LCP with the return of the LCP+LoST as one data structure.

Personally I'd rather put this in LoST than have to go back and  
retrofit 5 LCPs.  However, I'm also concerned with the behavior of  
the client.  I would like it to do the same thing and have the same  
steps no matter if it is a network that attempts to hide its location  
or in a network that does not.  Having separate client, endpoint  
behavior for these two situations may lead to trouble.

> anyone who wants it, to maximize it's revenue.

Ok.  Here we are reading from different books.  An LbyR is not the  
only thing a LIS needs to hand out to get paid for its location,  
unless you have a different perspective of that whole micro-payments  
thing from 10 years ago.  Also, there may be networks that had  
location for client endpoints for reasons other than money.

All that is besides the point, as you cannot predict that every PSAP  
will have a relationship with every access network within its  
jurisdiction.  I know we've been over this time and again on this  
mailing list, but wishing that these multitude of entities will get  
together in a harmonious administrative effort is just that,  
wishing.  If human nature worked like that, PGP would be a  
universally accepted technology.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 10:30:01 -0400

Okay, I understand what you propose.

I don't see a request in LoST where you supply a boundary reference, and you
get back the uris.  I see "getServiceBoundaryResponse" as in figure 11 in
Lost-05, but it doesn't have the uri.  I can see how it could, but the text
doesn't say that it does.  I don't see anything where you supply a boundary
reference and get a mapping.  Did I miss some text in the document?

If you could, I see how this would work.

I am not opposed to modifying LoST to solve the problem.  I am opposed to
REQUIRING that the LoST server be combined with the LIS.  If I'm
understanding what you propose, that isn't really necessary; you are just
proposing the LIS have a LoST query interface the client uses to get the
PSAP URI.  The LIS could consult a "real" LoST server to get the info that
it returns to the client.  This has the problem that the UA must for sure
use the access network to determine the LoST server.  I don't think that
will always work.

I do think that the response to the LIS for location is an LbyR, and not
something else.  That is what it passes in -conveyance, and that is what the
PSAP uses.  Your point that the LIS could ignore it is sort of okay.  It
isn't really because the LoST query doesn't supply enough identifiers to the
LIS to uniquely identify the endpoint.  However, the LbyR does.  But then
you are back to accepting LbyR in a LoST request.

Brian

> Sent: Wednesday, April 18, 2007 12:07 AM
> To: Brian Rosen