Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Apr 2007 14:24:32 -0400

Okay, well, discussion has died down now, so I'd like to see if we have
consensus on how we allow access networks to hide location from endpoints
(and VSPs) and yet result in correct emergency call routing.

The proposal requires no changes to existing documents (other than
explanations in -framework and -phonebcp).

It requires no changes in endpoint, VSP, ESRP or PSAP behavior.  It is
confined to LIS behavior for LIS' that wish to hide location.

It works as follows:

1. The endpoint uses an LCP to request location.  The LIS returns an LbyR
2. The endpoint dereferences the LbyR.  
3. The LIS, noticing that the dereference request is from the endpoint (or
at least not from any entity that is entitled to get fine grained location),
takes the fine grained location and uses LoST to determine the PSAP that
serves that location.
4. The LIS returns to the endpoint a location which, if submitted to LoST,
would return the same PSAP URI the fine grained location would.  In some
circumstances, this could be a civic with only a country.  An alternative
that works for all circumstances is to return the polygon that defines the
service boundary of the PSAP (which LoST can return).  Is essential that the
PSAP URI returned from a LoST query with whatever the LIS gives the endpoint
would be the same PSAP URI any querier using the fine grained location would
get.
5. The endpoint uses the (coarse) location value it obtains to query LoST.
It gets the (correct) PSAP URI
6. This is repeated at call time.  The endpoint has a valid LbyR and a valid
PSAP URI, which it uses to construct the emergency call
7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences
it.  The result will be the same (coarse) location the endpoint got.  The
VSP does a LoST query with that location, and should get the same PSAP URI
that is in the Request URI on the call.  This validation works for coarse or
fine validation, and of course works for LbyV without the dereference step.
8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call.  It
dereferences the LbyR but gets the fine grained location; the LIS must have
a relationship with the ESRP/PSAP to assure this.
9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained
location.

Some observations:
a) The LIS probably ought to query LoST with its calculated coarse location
to assure that it gets the same PSAP URI as the fine grained location.  
b) The coarse LoST lookups can be cached.  For a given LIS, there is likely
only a few of them
c) The VSP can cache validated PSAP URIs and avoid LoST lookups in most
cases
d) The endpoint could send both the coarse location by value and the
reference, but this would really only help the VSP because the ESRP/PSAP is
going to want to dereference to get the fine grained location.
e) The LIS can identify ESRPs and PSAPs in a number of ways.  It could use
IP address filtering, VPNs, IPSEC tunnels or other address restrictive
mechanisms.  It could use TLS credentials of any form it finds acceptable.
It is essential that the mechanism work for any valid PSAP that could get
the call, and any ESRP that could handle the call, even when there are
failures.  

Now, do we have any objections to making this the answer to the problem
posed?  To be clear, I'm asking if you can live with it, not if you would
prefer another one of the proposals that have been made.

Brian 

> -----Original Message-----
> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Thursday, April 19, 2007 6:25 AM
> To: Brian Rosen; Henning Schulzrinne
> Cc: GEOPRIV; ECRIT
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto
> doendpoint centric LCP without giving away the store
> 
> Well... I just posted on an alternative thread - about preferring the
> location request be made at the time of the call - where Henning seems
> to be taking the position that this is a dangerous additional
> transaction requirement. Yet, here we appear to be suggesting that a
> location dereference be made to determine coarse routing...
> 
> I don't actually object to the additional transaction (per my previous
> thread) though I will note that the VSP is inherently "further" from the
> LIS than the device is. It just seems cleaner to me if the VSP has no
> requirement to interact with the LIS and that, in the case of emergency
> calls, all LIS interactions occur locally - either from the device or
> jurisdictional entities such as the LoST server, VPC, and/or PSAPs. This
> also obviates the need for the LIS to distinguish between "allowed"
> versus "non-allowed" granularity.
> 
> Cheers,
> Martin
> 
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 19 April 2007 4:02 AM
> To: 'Henning Schulzrinne'
> Cc: 'GEOPRIV'; 'ECRIT'
> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto
> doendpoint centric LCP without giving away the store
> 
> I can live with this way out of the mess.
> 
> I rather like the idea of returning the PSAP service boundary polygon on
> the
> endpoint's (or VSP's) dereference.  The latter (as well as coarse
> location
> when it works) also fixes the validation problem; the VSP dereferences,
> gets
> the polygon, queries LoST with it, and gets the PSAP URI.
> 
> I agree that in lots of cases, a very coarse location return from the
> LbyR
> is sufficient, and access networks ought to be able to take advantage of
> it
> when it happens.
> 
> I guess we need to hear from carriers.  I think you already raised the
> point
> that in most cases, an IP address yields city level location, albeit
> VPNs
> often obscure that.
> 
> And while you brought it up, I do think a very nice user part of a
> location
> reference is a hashed telephone number.  Most of the DSL networks, for
> example, do have telephone numbers which actually are easy to turn into
> service address in the existing databases.  I'd prefer it be hashed so
> that
> we don't reveal extra user information.  I particularly think that idea
> will
> be quite useful in dealing with legacy wireline systems, which already
> associate TN with location.  Adding a (hash of) TN with a provisioned
> LIS
> domain on a Geolocation header in, or near a PSTN to SIP gateway would
> be a
> very painless way to get location from a legacy wireline system into a
> next
> generation emergency call system.
> 
> Brian
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:[email-masked]]
> > Sent: Wednesday, April 18, 2007 12:56 PM
> > To: Brian Rosen
> > Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT'
> > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to
> > doendpoint centric LCP without giving away the store
> >
> >
> > On Apr 18, 2007, at 11:33 AM, Brian Rosen wrote:
> >
> > > I'm not sure I understand what you are saying.
> > >
> > > I'll agree that coarse location may work some times.  I wouldn't
> > > care to
> > > speculate how often it does or doesn't.  I don't think it matters.
> It
> >
> > This seems to be very country-specific. Thus, in some countries, this
> > will be quite viable, in others, less so.
> >
> > For DT, for example, you could have a very simple architecture:
> >
> > -  Use normal LCP, returning Gemeinde (city/town), Bundesstaat
> > (state) and country (DE). This is sufficient for determining the PSAP
> > and requires zero interaction with the OSS.
> >
> > - Return an LbyR that is similar to what is used today as an
> > identifier (phone number?), which resolves to the rough information
> > above.
> >
> >
> > > doesn't sometimes.  Does that mean we should misroute in those
> > > cases where
> > > you only get coarse location, and you have an irregular boundary
> that
> > > "misses"?  I suspect that would not fly with the access networks
> > > that have
> >
> > Definitely not. It would be the responsibility of the ISP to deliver
> > location information of sufficient granularity to prevent misroutes.
> > In some small number of corner cases (typically, the one boundary
> > street between PSAP regions), this would mean delivering a street
> > address or a geo region. This is easy for the ISP to determine - they
> > just query LoST and get the coverage regions.
> >
> > If you don't want to do this, just return the *geo* boundary of the
> > PSAP to the customer as location information via LCP, just like you'd
> > return an imprecise mapping from a wireless system, as a polygon. By
> > our mapping rules, LoST computes the centroid (trivial) and returns
> > the PSAP URL. I think this is somewhat similar to what Andy is
> > proposing, but requires no new effort.
> >
> > This reveals zero additional information to the client, beyond the
> > coverage region of the PSAP, but the UA behavior is exactly the same
> > as in the no-hiding case.
> >
> >
> > > the hiding problem.  You are giving them an unacceptable choice:
> > > give up
> > > accurate location to the endpoint or be responsible for misroute.
> > > That may
> > > meet your notion of endpoint simplicity, but it won't be deployed I
> > > think.
> >
> > I don't see this as the alternative. All I require is that ISP give
> > up a tiny fraction of its location information in some corner cases.
> > In most communities, all of the customers will only get city-level or
> > county-level information, which corresponds to what their phone
> > number already tells them.
> >
> > I think this is a fair bargain. I'd like to hear good reasons from
> > real carriers as to why this is not acceptable. Shadow boxing,
> > without talking to real customers, seems likely to lead us to design
> > something that doesn't actually help. (Just as I believe that the
> > whole architecture proposed doesn't actually address the don't-spend-
> > money objective of DT.)
> >
> >
> > >
> > > You also seem to be willing to accept that the client will have two
> > > locations to deal with: coarse LbyV and fine LbyR.  Not a
> > > complication I
> > > would want to have to deal with given my alternative.
> >
> > Not really. I advocate returning a single LbyR, which resolves to
> > minimal information sufficient for routing for the general public
> > and, with PSAP authentication, to precise location information for
> > dispatch.
> >
> > Henning
> >
> >
> > >
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> --------------------------------------------------------------------------
> ----------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------------------
> ----------------------
> [mf2]

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 21:44:02 +0200

Hi all,

I think it is good to solicit feedback from the group. Brian compiled 
text in a previous mail and I just changed the subject header and 
shorted the text a bit.

Note that the drawback of this architecture is the need to deploy a ESRP 
for a country, the need to establish a relationship between the ESRP and 
the LIS (in order for the ESRP to obtain more detailed location 
information) and the need to route emergency SIP messages through the ESRP.

So far we haven't received a lot of comments from operators.

Please find my questions below:

Brian Rosen wrote:
> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the SIP message.  It

Here are the questions:

1) Do you think that the problem statement is valid (i.e., the problem 
that some ASP/ISP do not reveal precise location information for free, 
for emergency services)?
2) Do you think we should investigate the proposed approach in more detail?
3) Do you understand the drawbacks?
4) Do you think it is necessary to solicit feedback from VoIP providers, 
PSAP operators, regulators and network operators on this issue?

Ciao
Hannes & Marc

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 19 Apr 2007 21:48:31 +0200

>for a country,

Where did you get this from? It could be, but it need not
 
Richard

________________________________

Von: Hannes Tschofenig [mailto:[email-masked]]
Gesendet: Do 19.04.2007 21:44
An: 'ECRIT'
Cc: GEOPRIV
Betreff: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture

Hi all,

Here are the questions:

Ciao
Hannes & Marc

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 15:53:27 -0400

>
> 1) Do you think that the problem statement is valid (i.e., the  
> problem that some ASP/ISP do not reveal precise location  
> information for free, for emergency services)?

Fortunately, if it turns out that this is a non-issue in the  
immediate or further future, the cost to end systems is nil. It is  
rather unlikely that we'll get feedback from a representative sample  
of operators. Some future operators, such as WiMax operators, may not  
exist at this time.

> 4) Do you think it is necessary to solicit feedback from VoIP  
> providers, PSAP operators, regulators and network operators on this  
> issue?
>

I think feedback should be solicited for the whole architecture, not  
this specific aspect. I don't think we want to encourage people to  
hide location or to make that the default behavior, given the  
difficulty of end-user fault detection, say.

By the way, I think it would be helpful if the framework or phonebcp  
would recommend that PSAPs read back location information via text-to- 
speech when test calls are being placed.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 21:56:30 +0200

Hi Richard,

if the access networks returns only the country code (in the worst case) 
then LoST will return (in the worst case) an ESRP corresponding to that 
country.
The emergency call would then be routed to this ESRP and subsequently 
this ESRP would have to fetch more detailed location information for 
routing within this country.

Do I miss something?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 22:03:04 +0200

Hi Henning

Henning Schulzrinne wrote:
>> problem that some ASP/ISP do not reveal precise location information 
>> for free, for emergency services)?
>
> Fortunately, if it turns out that this is a non-issue in the immediate 
> or further future, the cost to end systems is nil. It is rather 
> unlikely that we'll get feedback from a representative sample of 
> operators. Some future operators, such as WiMax operators, may not 
> exist at this time.
>
>
We don't want to encourage people to hide location for various reasons.

You are right that we don't want to solicit feedback only on this issue.
On the other hand we are designing an "enhancement" based on the 
feedback we got from a few operators regarding partial location hiding. 
Shouldn't we get feedback from a number of stakeholders about the 
validity of this architectural facet?

> would recommend that PSAPs read back location information via 
> text-to-speech when test calls are being placed.
Sounds good to me.

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 16:16:46 -0400

There clearly is a linkage here between the PSAP coverage region (or  
ESRP region and, conversely, the number of them) and the information  
returned. An ISP can't just say "sorry, I'm only going to give you  
country-level information and it's your problem to set up an ESRP,  
but I will only give location information to certain favored VSPs  
that might operate such a proxy".

I suspect regulators are smart enough to recognize any such  
hypothetical attempts at trying to restrain competition, but I doubt  
we can force this through technology design.

An ISP that is willing to release complete location information to  
the end user can essentially wash their hand of the whole emergency  
calling thing; an ISP wishing to hide such information needs to work  
more closely with local authorities and PSAPs, both in terms of  
architecture and in terms of access authorization. ISPs can then make  
business and technology choices, constrained by the local regulator,  
as to which mode they prefer to work in. This may well change over  
time; for example, future customer-facing and OSS systems may make  
location conveyance cheaper and easier, thus removing one incentive  
to hide this information. To some extent, this is a trade-off between  
capital and operational/lawyer expenses. I think the best we can do  
is to offer reasonable choices and hope that operators are both  
rational actors and have the life and safety of their customers at  
heart.

Henning

On Apr 19, 2007, at 3:56 PM, Hannes Tschofenig wrote:

> Hi Richard,
>
> if the access networks returns only the country code (in the worst  
> case) then LoST will return (in the worst case) an ESRP  
> corresponding to that country.
> The emergency call would then be routed to this ESRP and  
> subsequently this ESRP would have to fetch more detailed location  
> information for routing within this country.
>
> Do I miss something?

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Apr 2007 16:18:38 -0400

> speech when test calls are being placed.
Uh, well, in a form suitable for the media offered in the first place.  That
may be text, it may be text to sign language.

Brian

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 19 Apr 2007 22:22:00 +0200

Hannes,
 
as you say, this is the worst case.
but you can go down to village level if you want

>> Note that the drawback of this architecture is the need to deploy a ESRP
 
this sounds like the worst case is the only option

Richard

Von: Hannes Tschofenig [mailto:[email-masked]]
Gesendet: Do 19.04.2007 21:56
An: Stastny Richard
Cc: ECRIT; GEOPRIV
Betreff: Re: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture

Hi Richard,

Do I miss something?

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 16:28:57 -0400

Certainly; I'm getting infected with the voice-centric virus...

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Apr 2007 13:29:08 -0700

>may be text, it may be text to sign language.

First off, I'm not sure why Geopriv is cc'ed on this message.  Isn't what is
in framework/phonebcp purely an ECRIT matter?

Second, why are the UI elements of test call responses in scope for an IETF
document?  If I understand this right, we're not talking about the protocol
elements returned when someone is validating a location prior to making
a call, this is about what happens if someone makes a test call to the actual
PSAP.  How is this within the IETF's scope/knowledge?

Confused,
			Ted

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 22:30:17 +0200

Hi Richard,

> but you can go down to village level if you want
Correct.

> this sounds like the worst case is the only option
No. It really depends on the regulatory environment in a particular 
country. The remarks by Henning also apply.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 22:33:06 +0200

Hi Ted,

~snip~
> in framework/phonebcp purely an ECRIT matter?
I thought about that as well. With the previous discussions we came up 
with a couple of solutions that required changes to the GEOPRIV L7 LCP 
work. This particular proposal does not require changes (or introduces 
new requirements) but some of the GEOPRIV members might be interested in 
the different approach. I don't want to exclude them.

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Apr 2007 16:39:10 -0400

Wait, we're spinning out of the universe.

What is required is ONLY that the PSAP URI returned from the coarse location
is the same PSAP URI returned from the fine location.  That is the only
constraint.

If country code satisfies that, because every location in some country
returns the same result from a LoST query, great.  If that isn't true, then
country code is insufficient.

What always works is the polygon representing the service boundary of the
(fine grained location) target PSAP.  If the LIS queries LoST with fine
grained location, it can get back a suitable polygon. 

Something between the two examples above MAY work, but the constraint has to
be satisfied: LoST(coarse location, service) == LoST(fine location, service)

We don't REQUIRE country level ESRPs.  You won't get that in North America.
In some cases you may get a state level ESRP, but you can't guarantee that.
If the service area of the LIS is a proper subset of the service area of the
ESRP/PSAP, which is very common, especially with any aggregation via an
ESRP, then the LIS' task is simple.

Also note that the LIS can't use a specially modified LoST server.  The
validation depends on a VSP being able to ask its LoST server what the PSAP
URI for the proffered location is.  

Brian

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Thursday, April 19, 2007 4:22 PM
> To: Hannes Tschofenig
> Cc: GEOPRIV; ECRIT
> Subject: [Geopriv] Re: [Ecrit] Soliciting Feedback: (Partial)
> LocationHiding Emergency Services Architecture
> 
> Hannes,
>

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 19 Apr 2007 22:43:58 +0200

Fully agree
This is what I wanted to say
 
Richard

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Do 19.04.2007 22:39
An: Stastny Richard; 'Hannes Tschofenig'
Cc: 'GEOPRIV'; 'ECRIT'
Betreff: RE: [Geopriv] Re: [Ecrit] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Apr 2007 16:46:11 -0400

I dropped geopriv

Please look at -phonebcp for the current test procedure.  This would add a
step.

It's not a UI element, it's a protocol exchange.  The contents of the media
stream may not be subject to standardization, but the mechanism to signal it
would be as well as the behavior of the ends.  The current procedure
specifies a loopback of media.  We would need something that opened a one
way media stream from the PSAP to the endpoint.  It would be a normal SIP
thing, but we have to know to do it.

Brian

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Thursday, April 19, 2007 4:29 PM
> To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig'
> Cc: 'GEOPRIV'; 'ECRIT'
> Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial)

---

From: "Liess, Laura" <[email-masked]>
Date: Thu, 19 Apr 2007 23:05:01 +0200

Brian,

this is for us (DT) the prefered solution and, from the alternatives we had, the only one we can live with. 

Laura

> -----Ursprüngliche Nachricht-----
> Gesendet: Donnerstag, 19. April 2007 20:25
> An: 'Dawson, Martin'; 'Henning Schulzrinne'
> Cc: 'GEOPRIV'; 'ECRIT'
> Betreff: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on 
> howto doendpointcentric LCP without giving away the store
> 
> 
> Okay, well, discussion has died down now, so I'd like to see 
> if we have consensus on how we allow access networks to hide 
> location from endpoints (and VSPs) and yet result in correct 
> emergency call routing.
> 
> The proposal requires no changes to existing documents (other 
> than explanations in -framework and -phonebcp).
> 
> It requires no changes in endpoint, VSP, ESRP or PSAP 
> behavior.  It is confined to LIS behavior for LIS' that wish 
> to hide location.
> 
> It works as follows:
> 
> 1. The endpoint uses an LCP to request location.  The LIS 
> returns an LbyR 2. The endpoint dereferences the LbyR.  
> 3. The LIS, noticing that the dereference request is from the 
> endpoint (or at least not from any entity that is entitled to 
> get fine grained location), takes the fine grained location 
> and uses LoST to determine the PSAP that serves that 
> location. 4. The LIS returns to the endpoint a location 
> which, if submitted to LoST, would return the same PSAP URI 
> the fine grained location would.  In some circumstances, this 
> could be a civic with only a country.  An alternative that 
> works for all circumstances is to return the polygon that 
> defines the service boundary of the PSAP (which LoST can 
> return).  Is essential that the PSAP URI returned from a LoST 
> query with whatever the LIS gives the endpoint would be the 
> same PSAP URI any querier using the fine grained location 
> would get. 5. The endpoint uses the (coarse) location value 
> it obtains to query LoST. It gets the (correct) PSAP URI 6. 
> This is repeated at call time.  The endpoint has a valid LbyR 
> and a valid PSAP URI, which it uses to construct the 
> emergency call 7. A VSP wishing to validate the PSAP URI 
> takes the LbyR and dereferences it.  The result will be the 
> same (coarse) location the endpoint got.  The VSP does a LoST 
> query with that location, and should get the same PSAP URI 
> that is in the Request URI on the call.  This validation 
> works for coarse or fine validation, and of course works for 
> LbyV without the dereference step. 8. The PSAP (or ESRP) 
> which is the target of the PSAP URI gets the call.  It 
> dereferences the LbyR but gets the fine grained location; the 
> LIS must have a relationship with the ESRP/PSAP to assure 
> this. 9. Any succeeding ESRPs or PSAPs can also dereference 
> and get fine grained location.
> 
> Some observations:
> a) The LIS probably ought to query LoST with its calculated 
> coarse location to assure that it gets the same PSAP URI as 
> the fine grained location.  
> b) The coarse LoST lookups can be cached.  For a given LIS, 
> there is likely only a few of them
> c) The VSP can cache validated PSAP URIs and avoid LoST 
> lookups in most cases
> d) The endpoint could send both the coarse location by value 
> and the reference, but this would really only help the VSP 
> because the ESRP/PSAP is going to want to dereference to get 
> the fine grained location.
> e) The LIS can identify ESRPs and PSAPs in a number of ways.  
> It could use IP address filtering, VPNs, IPSEC tunnels or 
> other address restrictive mechanisms.  It could use TLS 
> credentials of any form it finds acceptable. It is essential 
> that the mechanism work for any valid PSAP that could get the 
> call, and any ESRP that could handle the call, even when 
> there are failures.  
> 
> Now, do we have any objections to making this the answer to 
> the problem posed?  To be clear, I'm asking if you can live 
> with it, not if you would prefer another one of the proposals 
> that have been made.
> 
> Brian 
> 
> > thread) though I will note that the VSP is inherently 
> "further" from 
> > the LIS than the device is. It just seems cleaner to me if 
> the VSP has 
> > no requirement to interact with the LIS and that, in the case of 
> > emergency calls, all LIS interactions occur locally - 
> either from the 
> > device or jurisdictional entities such as the LoST server, 
> VPC, and/or 
> > PSAPs. This also obviates the need for the LIS to 
> distinguish between 
> > "allowed" versus "non-allowed" granularity.
> > 
> > Cheers,
> > Martin
> > 
> > I rather like the idea of returning the PSAP service 
> boundary polygon 
> > on the endpoint's (or VSP's) dereference.  The latter (as well as 
> > coarse location
> > LbyR is sufficient, and access networks ought to be able to take 
> > advantage of it
> > when it happens.
> > 
> > point that in most cases, an IP address yields city level location, 
> > albeit VPNs
> > often obscure that.
> > 
> > location reference is a hashed telephone number.  Most of the DSL 
> > networks, for example, do have telephone numbers which actually are 
> > easy to turn into service address in the existing databases.  I'd 
> > prefer it be hashed so that
> > > > care to speculate how often it does or doesn't.  I 
> don't think it 
> > > > matters.
> > It
> > >
> > > This seems to be very country-specific. Thus, in some countries, 
> > > this will be quite viable, in others, less so.
> > >
> > > (state) and country (DE). This is sufficient for determining the 
> > > PSAP and requires zero interaction with the OSS.
> > >
> > > > cases where you only get coarse location, and you have an 
> > > > irregular boundary
> > that
> > > address or a geo region. This is easy for the ISP to determine - 
> > > they just query LoST and get the coverage regions.
> > >
> > > PSAP to the customer as location information via LCP, just like 
> > > you'd return an imprecise mapping from a wireless system, as a 
> > > polygon. By our mapping rules, LoST computes the centroid 
> (trivial) 
> > > and returns the PSAP URL. I think this is somewhat 
> similar to what 
> > > Andy is proposing, but requires no new effort.
> > >
> > > > give up accurate location to the endpoint or be responsible for 
> > > > misroute. That may
> > > In most communities, all of the customers will only get 
> city-level 
> > > or county-level information, which corresponds to what 
> their phone 
> > > whole architecture proposed doesn't actually address the 
> > > don't-spend- money objective of DT.)
> > >
> > >
> > > >
> > > > You also seem to be willing to accept that the client will have 
> > > > two locations to deal with: coarse LbyV and fine LbyR.  Not a 
> > > > complication I would want to have to deal with given my 
> > > > alternative.
> > >
> > [email-masked] https://www1.ietf.org/mailman/listinfo/geopriv
> > 
> >

---

From: Andrew Newton <[email-masked]>
Date: Thu, 19 Apr 2007 17:08:51 -0400

First, thanks for spelling this out.  This sounds more reasonable  
than all the other solutions.  And it touches little while solving  
the problem.

-andy

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Apr 2007 14:43:59 -0700

>Please look at -phonebcp for the current test procedure.  This would add a

So, the proposal is to add this to 9.1.  The current version says:

   INVITE requests to a service urn with a urn parameter of "test"
   indicates a request for an automated test.  For example,
   "urn:service.sos.fire;test".  As in standard SIP, a 200 (OK) response
   indicates that the address was recognized and a 404 (Not found) that
   it was not.  A 486 (Busy Here) MUST be returned if the test service
   is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP
   does not support the test mechanism.

   In its response to the test, the PSAP MAY include a text body
   indicating the identity of the PSAP, the requested service, and the
   location reported with the call.  For the latter, the PSAP SHOULD
   return location-by-value even if the original location delivered with
   the test was by-reference.

   A PSAP accepting a test call SHOULD accept a media loopback
   test[I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-pkt-
   loopback" and "rtp-start-loopback" options.  The user agent would
   specify a loopback attribute of "loopback-source", the PSAP being the
   mirror.  User Agents should expect the PSAP to loop back no more than
   3 packets of each media type accepted, after which the PSAP would
   normally send BYE.

   User agents SHOULD perform a full call test, including media
   loopback, after a disconnect and subsequent change in IP address.
   After an initial IP address assignment test, a full test SHOULD be
   repeated approximately every 30 days with a random interval.

   User agents MUST NOT place a test call immediately after booting, as
   a widespread power outage and subsequent restoration would impose an
   inordinate load on the emergency call routing system.

   PSAPs MAY refuse repeated requests for test from the same device in a
   short period of time.

This seems to me to be a set of tests which would never require
the user to be aware that the call was going on.  The User Agent
would perform this test periodically (with the noted random interval)
and would throw an error only if it failed in some unexpected way.
That is, I would not expect an error to reach the end user if it
said "busy here" or "not acceptable here", since both of those could
be normal. 

But shifting this to something that "reads out" the
location in text-to-speech bumps this up to the UI, in my opinion.
That is only useful if the user is aware of it and has some way to listen
to the read-aloud  portion.  That's a pretty major change to the functionality,
and I don't think it is justified.  In the case where location-by-value
was used, it just consumes a media stream to read aloud something
that is stored on the end device anyway.  When the network provided
the location, it does return something of value, but in a less-than
useful way.  The PSAP already MAY return the location accompanying
the call.  If the end device wants to read that aloud, let it; or let it
display it, or whatever.  So, I don't think there is any reason to add
a one-way media stream from PSAP to the terminal in this, as
I think the added burden on the PSAP gets the terminal basically nothing.

I have to say, I also find the timing on this:

   User agents SHOULD perform a full call test, including media
   loopback, after a disconnect and subsequent change in IP address.
   After an initial IP address assignment test, a full test SHOULD be
   repeated approximately every 30 days with a random interval.

pretty ridiculous.  This would have me test the softphone on my
laptop no less than three times in my usual day, as I get IP
address changes as I move among networks (home, wireline
office, wireless conference room).   I think we should recommend
a bound on this for mobile or nomadic devices; the alternative will
be pretty stressful on the infrastructure for no good reason.

			Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 17:52:18 -0400

We're talking about resolvers, i.e., not the authoritative servers.  
They can be administered by anybody, including the famous VSP in  
Sierra Leone that Brian subscribes to. The resolver has no business  
relationship with the ISP, but needs to dereference the location  
reference, as it otherwise has no idea what to do next. Thus, I'm  
afraid that your proposal is not workable given the current LoST  
architecture and design.

Henning

On Apr 19, 2007, at 5:39 PM, Dawson, Martin wrote:

> Well - I think it's awful but I could live with it. It seems like a  
> long
> winded way to avoid having the LoST server do a dereference.
>
> Does anyone think that a LoST server for Portugal will be administered
> by an entity anywhere other than Portugal? I don't. And in that  
> case, I
> don't see any issue for those jurisdictions that want to apply auth 
> +auth
> on the dereference. The LoST server in such a jurisdiction can
> reasonably be expected to be authorised.
>
> Cheers,
> Martin
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Apr 2007 18:00:20 -0400

I think there is value to the read out, but it does change the mechanism
from fully automatic to manual at the user side.  We could have two test
processes.  I'll listen to others and move as the consensus dictates.

I'm not sure how to address the timing issue you raise.  If you DO switch
between 3 addresses every day, what IS reasonable advice?  At the very
least, you could cache IP addresses and reduce the testing when you have the
same address.  That works in a lot of cases.  But, suppose you get a new
address every time?  What IS the right advice?

We could say "any address in the same subnet" is assumed to be the same
using the mask, so don't repeat.

Brian

> Sent: Thursday, April 19, 2007 5:44 PM
> Cc: 'ECRIT'
> >> First off, I'm not sure why Geopriv is cc'ed on this message.  Isn't
> what
> >> is

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 18:04:33 -0400

The whole point is that the caller can, if he so desires, verify the  
location information. Incorrect location information is a major  
source of mis-routes and false dispatches today (see the NYT article  
I sent around a few weeks ago).

Since location information, even without hiding, can be added by a  
proxy, this is the only way for the end system to determine what  
information will be conveyed to the PSAP in all cases. In existing  
system, finding this out is extremely tedious and burdensome to the  
PSAP, as you actually have to call 911 to see what address your  
carrier has registered for you. You really don't want to resolve the  
"No, I'm not living at 123 Main Street, that's my billing address"  
during an emergency call.

I have no objection to returning this PSAP-seen information in some  
other way, such as location-conveyance, but I expected to hear  
screams from the hide-location crowd in that case. Thus, I was trying  
to find a way that achieves most of the goals, while not stepping on  
sensitive toes. Since the existing test text includes the return of  
location information, albeit in a format that is left unspecified  
(which should be fixed), I'm happy with that.

I also have no objection to making this an optional request in the  
call, so that unattended test calls do not generate this, but I'm not  
convinced that the complexity is worth it.

Thus, I believe that this mechanism adds significantly to the overall  
reliability of the system and we should encourage that it be  
provided, whether as location-conveyance, audio or just a PIDF-LO  
attachment in the 200 OK. (This generally won't work well, given the  
difficulty real phones have with multipart, but that's a different  
topic.)

Henning

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Apr 2007 15:25:14 -0700

At 6:04 PM -0400 4/19/07, Henning Schulzrinne wrote:
>The whole point is that the caller can, if he so desires, verify the location information. Incorrect location information is a major source of mis-routes and false dispatches today (see the NYT article I sent around a few weeks ago).
>
>Since location information, even without hiding, can be added by a proxy, this is the only way for the end system to determine what information will be conveyed to the PSAP in all cases. In existing system, finding this out is extremely tedious and burdensome to the PSAP, as you actually have to call 911 to see what address your carrier has registered for you. You really don't want to resolve the "No, I'm not living at 123 Main Street, that's my billing address" during an emergency call.

Do you believe, then, that the user has to be aware of the test call, and responsive
during it?  That's very different from the way the BCP seems to be written now,
and I suspect there are some pretty scaly dragons there.  If, at a random interval,
the phone rings and reports on the status of a pseudo-911 call, I think users
are going to be surprised and may be alarmed.  I'd rather leave it as something
where the phone confirms that the test works and stores the outcome, so that a
user may review it and make corrections if needed.  But that means storing
time and date along with the test call info (imagine someone saying,
"I'm at 3 Wall Street, and this thing believes I'm at JFK" where it really meant
that the most recent test call was when the user was at the airport).

>I have no objection to returning this PSAP-seen information in some other way, such as location-conveyance, but I expected to hear screams from the hide-location crowd in that case. Thus, I was trying to find a way that achieves most of the goals, while not stepping on sensitive toes. Since the existing test text includes the return of location information, albeit in a format that is left unspecified (which should be fixed), I'm happy with that.

I agree that the format should be specified.  I believe that returning it in
a text body, as 9.1 already allows the end system to determine the best
way to present it to the end user, if it desires to do so.  I think the media
stream is a less-optimal and heavier weight mechanism for accomplishing
that.

>I also have no objection to making this an optional request in the call, so that unattended test calls do not generate this, but I'm not convinced that the complexity is worth it.

I think we should assume that the typical test call will be unattended.  How
far off the consensus am I on that?

>Thus, I believe that this mechanism adds significantly to the overall reliability of the system and we should encourage that it be provided, whether as location-conveyance, audio or just a PIDF-LO attachment in the 200 OK. (This generally won't work well, given the difficulty real phones have with multipart, but that's a different topic.)

I think incorporating it into the response to the 200 OK is the best way forward,
and that making it part of the text actually relieves some of the location hiding
concerns (since the information would need to be scraped from there into other
applications).
				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 19:42:12 -0400

Based on my experience, there are two kinds of test calls:

- automatic: done to verify NAT operation, LoST lookups and such;  
nothing is reported unless there's a problem; done fairly regularly  
when network conditions change; no human interaction.

- manual: explicitly invoked by the user; for example, done when  
moving into a new house. There is no ringback or anything else - the  
user picks up the phone, clicks on the "test emergency call" link and  
gets information back, similar to the test numbers that regular phone  
service has (including such  numbers as 1 700 555.4141 [http:// 
www.cs.columbia.edu/~hgs/internet/telephone.html]).

For example, when we installed our new departmental PBX, we wanted to  
make sure 911 worked and delivered the right number and location to  
the PSAP. We had to call the "real" 911, which our sys admin did with  
great trepidation.

> far off the consensus am I on that?

See above; we need both.

>> Thus, I believe that this mechanism adds significantly to the  
>> overall reliability of the system and we should encourage that it  
>> be provided, whether as location-conveyance, audio or just a PIDF- 
>> LO attachment in the 200 OK. (This generally won't work well,  
>> given the difficulty real phones have with multipart, but that's a  
>> different topic.)
>

I don't know what you have in mind. I'm sure you are not proposing to  
put it as

200 OK (123 Main Street)

Putting it in plain text as a body (text/plain) isn't likely to deter  
scraping unless it is so obfuscated that it confuses humans, too.  
Plus, you lose the ability to know which elements are actually  
populated, so that a correct-looking address is actually unusable for  
routing or dispatch. For example, showing

Room 123 456 Corporate Plaza
Anytown CA 01234

can still have "Room 123" show up in the street address field in PIDF- 
LO, even though the text "looks" ok.

Plus, text isn't too useful for an ATA (terminal adapter) device. It  
can't show the text, since it has no display.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Apr 2007 20:04:27 -0400

On Apr 19, 2007, at 6:17 PM, Dawson, Martin wrote:

> OK I see...
>
> If we're talking about VSPs (which I didn't think were necessary for
> ECRIT) then I agree. However, that's the same challenge that i2 has -
> except it's not just a routing question, it has to go to the right VPC
> so the PSAP can get the location information from it out of band.

As per our definitions, VSPs could be something like a corporation or  
university campus, not necessarily an operator such as SunRocket,  
Verizon or Vonage. As noted before, a LoST server could also be  
operated by an independent party, just like STUN servers are today  
(e.g., http://www.stunserver.org/).

>
> If this is the only scenario we are talking about, then I still think
> there are less convoluted solutions from the perspective of the  
> device.
>
> How about the "resolver" does a dereference and the LIS, realizing  
> it's
> not an authorized requestor, just returns a country code. Or there may

That's roughly what happens in the proposal, except that the query is  
done by the UA. But that doesn't solve the problem of finding the  
right PSAP and doesn't seem to change the problems leading to the  
currently-proposed solution.

> actually be standard HTTP (for example) error constructs that would
> provide the equivalent information. Or, as I tentatively suggested, a
> convention for the URL construction could indicate the jurisdiction  
> - or
> the LIS request could include a URL and a bare bones PIDF-LO (both of
> which eliminate the additional transaction altogether). I don't think
> any of those proposals require changes to existing specifications  
> either
> (apart from LoST doing the dereference).

My general perception is that encoding information into URLs (not  
URNs) is considered a hack, as they are supposed to be opaque to the  
HTTP client.

>
> Anyway, my response stands. I could live with the solution but it  
> feels
> unnecessarily convoluted.

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 20 Apr 2007 10:09:18 -0400

I see this as an attempt to get around the access provider's "hiding". I
can see people using the PSAP test call now as not only a means of
testing whether an unauthenticated phone works, but as a tool to figure
out their location, if the access provider won't give it to them. 

I'm against this recommendation. But I won't fight hard, since the
recommendation has no teeth.

I should point out, though, that phonebcp currently only describes the
UA doing automated testing, and not providing a user interface to
support user-initiated testing. And support of media (above and beyond
SIP signaling) appears to only be a "SHOULD". In my phonebcp comments, I
did object to the recommendation that PSAPs respond with the location
value in their SIP response, if a reference were sent in the request.
But again, I won't argue hard. This will ultimately be a matter of local
or national policy, independent of the IETF attempts to impact such
policy.
Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 4:19 PM
To: 'Henning Schulzrinne'; 'Hannes Tschofenig'
Cc: 'GEOPRIV'; 'ECRIT'
Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback:
(Partial)LocationHiding Emergency Services Architecture

> speech when test calls are being placed.
Uh, well, in a form suitable for the media offered in the first place.
That may be text, it may be text to sign language.

Brian

*****

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 10:58:17 -0400

The IETF specs are mainly directed towards implementors and mainly  
read by them. Implementors need to be aware of the data coming back  
from a test call, so they MUST implement the necessary functionality.  
It is up to the regulator, as you hint at, whether to allow or force  
the PSAP to return the information. I see nothing wrong with  
documenting, however, operational considerations that indicate that  
this is a good thing for the customer, as it allows verification. It  
is then up to the lobbyists of the telcos to convince the regulators  
that their business interests trump the public safety interests; it's  
not the role of the IETF to hide our technical opinion simply because  
it's inconvenient to the lobbyists.

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 17:17:58 -0500

OK I see...

If this is the only scenario we are talking about, then I still think
there are less convoluted solutions from the perspective of the device.

How about the "resolver" does a dereference and the LIS, realizing it's
not an authorized requestor, just returns a country code. Or there may
actually be standard HTTP (for example) error constructs that would
provide the equivalent information. Or, as I tentatively suggested, a
convention for the URL construction could indicate the jurisdiction - or
the LIS request could include a URL and a bare bones PIDF-LO (both of
which eliminate the additional transaction altogether). I don't think
any of those proposals require changes to existing specifications either
(apart from LoST doing the dereference).

Anyway, my response stands. I could live with the solution but it feels
unnecessarily convoluted.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 7:52 AM
To: Dawson, Martin
Cc: Brian Rosen; GEOPRIV; ECRIT
Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto
doendpoint centric From [email-masked] Mon Apr 23 08:16:28 2007
Content-class: urn:content-classes:message
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto	doendpoint
	centric LCP	without giving away the store
Date: Thu, 19 Apr 2007 17:17:58 -0500
From: "Dawson, Martin" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>
Cc: GEOPRIV <[email-masked]>, ECRIT <[email-masked]>

OK I see...

If this is the only scenario we are talking about, then I still think
there are less convoluted solutions from the perspective of the device.

How about the "resolver" does a dereference and the LIS, realizing it's
not an authorized requestor, just returns a country code. Or there may
actually be standard HTTP (for example) error constructs that would
provide the equivalent information. Or, as I tentatively suggested, a
convention for the URL construction could indicate the jurisdiction - or
the LIS request could include a URL and a bare bones PIDF-LO (both of
which eliminate the additional transaction altogether). I don't think
any of those proposals require changes to existing specifications either
(apart from LoST doing the dereference).

Anyway, my response stands. I could live with the solution but it feels
unnecessarily convoluted.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 7:52 AM
To: Dawson, Martin
Cc: Brian Rosen; GEOPRIV; ECRIT
Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto

Henning

> reasonably be expected to be authorised.

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 16:39:13 -0500

P without giving away the store

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 16:39:13 -0500

Well - I think it's awful but I could live with it. It seems like a long
winded way to avoid having the LoST server do a dereference.

Does anyone think that a LoST server for Portugal will be administered
by an entity anywhere other than Portugal? I don't. And in that case, I
don't see any issue for those jurisdictions that want to apply auth+auth
on the dereference. The LoST server in such a jurisdiction can
reasonably be expected to be authorised.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 4:25 AM
To: Dawson, Martin; 'Henning Schulzrinne'
Cc: 'GEOPRIV'; 'ECRIT'
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto

Okay, well, discussion has died down now, so I'd like to see if we have
consensus on how we allow access networks to hide location from
endpoints
(and VSPs) and yet result in correct emergency call routing.

It works as follows:

1. The endpoint uses an LCP to request location.  The LIS returns an
LbyR
2. The endpoint dereferences the LbyR.  
3. The LIS, noticing that the dereference request is from the endpoint
(or
at least not from any entity that is entitled to get fine grained
location),
takes the fine grained location and uses LoST to determine the PSAP that
serves that location.
4. The LIS returns to the endpoint a location which, if submitted to
LoST,
would return the same PSAP URI the fine grained location would.  In some
circumstances, this could be a civic with only a country.  An
alternative
that works for all circumstances is to return the polygon that defines
the
service boundary of the PSAP (which LoST can return).  Is essential that
the
PSAP URI returned from a LoST query with whatever the LIS gives the
endpoint
would be the same PSAP URI any querier using the fine grained location
would
get.
5. The endpoint uses the (coarse) location value it obtains to query
LoST.
It gets the (correct) PSAP URI
6. This is repeated at call time.  The endpoint has a valid LbyR and a
valid
PSAP URI, which it uses to construct the emergency call
7. A VSP wishing to validate the PSAP URI takes the LbyR and
dereferences
it.  The result will be the same (coarse) location the endpoint got.
The
VSP does a LoST query with that location, and should get the same PSAP
URI
that is in the Request URI on the call.  This validation works for
coarse or
fine validation, and of course works for LbyV without the dereference
step.
8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call.
It
dereferences the LbyR but gets the fine grained location; the LIS must
have
a relationship with the ESRP/PSAP to assure this.
9. Any succeeding ESRPs or PSAPs can also dereference and get fine
grained
location.

Some observations:
a) The LIS probably ought to query LoST with its calculated coarse
location
to assure that it gets the same PSAP URI as the fine grained location.  
b) Thehttps://www1.ietf.org/mailman/listinfo/ecrit>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Well - I think it's awful but I could live with it. It seems like a long
winded way to avoid having the LoST server do a dereference.

Does anyone think that a LoST server for Portugal will be administered
by an entity anywhere other than Portugal? I don't. And in that case, I
don't see any issue for those jurisdictions that want to apply auth+auth
on the dereference. The LoST server in such a jurisdiction can
reasonably be expected to be authorised.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 4:25 AM
To: Dawson, Martin; 'Henning Schulzrinne'
Cc: 'GEOPRIV'; 'ECRIT'
Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto

Okay, well, discussion has died down now, so I'd like to see if we have
consensus on how we allow access networks to hide location from
endpoints
(and VSPs) and yet result in correct emergency call routing.

It works as follows:

1. The endpoint uses an LCP to request location.  The LIS returns an
LbyR
2. The endpoint dereferences the LbyR.  
3. The LIS, noticing that the dereference request is from the endpoint
(or
at least not from any entity that is entitled to get fine grained
location),
takes the fine grained location and uses LoST to determine the PSAP that
serves that location.
4. The LIS returns to the endpoint a location which, if submitted to
LoST,
would return the same PSAP URI the fine grained location would.  In some
circumstances, this could be a civic with only a country.  An
alternative
that works for all circumstances is to return the polygon that defines
the
service boundary of the PSAP (which LoST can return).  Is essential that
the
PSAP URI returned from a LoST query with whatever the LIS gives the
endpoint
would be the same PSAP URI any querier using the fine grained location
would
get.
5. The endpoint uses the (coarse) location value it obtains to query
LoST.
It gets the (correct) PSAP URI
6. This is repeated at call time.  The endpoint has a valid LbyR and a
valid
PSAP URI, which it uses to construct the emergency call
7. A VSP wishing to validate the PSAP URI takes the LbyR and
dereferences
it.  The result will be the same (coarse) location the endpoint got.
The
VSP does a LoST query with that location, and should get the same PSAP
URI
that is in the Request URI on the call.  This validation works for
coarse or
fine validation, and of course works for LbyV without the dereference
step.
8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call.
It
dereferences the LbyR but gets the fine grained location; the LIS must
have
a relationship with the ESRP/PSAP to assure this.
9. Any succeeding ESRPs or PSAPs can also dereference and get fine
grained
location.

Some observations:
a) The LIS probably ought to query LoST with its calculated coarse
location
to assure that it gets the same PSAP URI as the fine grained location.  
b) The coarse LoST lookups can be cached.  For a given LIS, there is
likely
only a few of them
c) The VSP can cache validated PSAP URIs and avoid LoST lookups in most
cases
d) The endpoint could send both the coarse location by value and the
reference, but this would really only help the VSP because the ESRP/PSAP
is
going to want to dereference to get the fine grained location.
e) The LIS can identify ESRPs and PSAPs in a number of ways.  It could
use
IP address filtering, VPNs, IPSEC tunnels or other address restrictive
mechanisms.  It could use TLS credentials of any form it finds
acceptable.
It is essential that the mechanism work for any valid PSAP that could
get
the call, and any ESRP that could handle the call, even when there are
failures.  

Now, do we have any objections to making this the answer to the problem
posed?  To be clear, I'm asking if you can live with it, not if you
would
prefer another one of the proposals that have been made.

Brian 

> service address in the existing databases.  I'd prefer it be  coarse LoST lookups can be cached.  For a given LIS, there is
likely
only a few of them
c) The VSP can cache validated PSAP URIs and avoid LoST lookups in most
cases
d) The endpoint could send both the coarse location by value and the
reference, but this would really only help the VSP because the ESRP/PSAP
is
going to want to dereference to get the fine grained location.
e) The LIS can identify ESRPs and PSAPs in a number of ways.  It could
use
IP address filtering, VPNs, IPSEC tunnels or other address restrictive
mechanisms.  It could use TLS credentials of any form it finds
acceptable.
It is essential that the mechanism work for any valid PSAP that could
get
the call, and any ESRP that could handle the call, even when there are
failures.  

Now, do we have any objections to making this the answer to the problem
posed?  To be clear, I'm asking if you can live with it, not if you
would
prefer another one of the proposals that have been made.

Brian 

> > This seems to be very country-specific. Thus, in some countries,
this
> > (state) and country (DE). This is sufficient for determining the
PSAP
> > address or a geo region. This is easy for the ISP to determine -
they
> > PSAP to the customer as location information via LCP, just like
you'd
> > I think this is a fair bargain. I'd likhashed so
> that
this
> > (state) and country (DE). This is sufficient for determining the
PSAP
> > address or a geo region. This is easy for the ISP to determine -
they
> > PSAP to the customer as location information via LCP, just like
you'd
> > whole architecture proposed doesn't actually address the
don't-spend-
> > > You also seem to be willing to accept that the client will have
two
> > and, with PSAP authentication, to precise location information for
------------------------------------------------------------------------
--
------------------------------------------------------------------------
--

e to hear good reasons from
> > whole architecture proposed doesn't actually address the
don't-spend-
> > > You also seem to be willing to accept that the client will have
two
> > and, with PSAP authentication, to precise location information for
------------------------------------------------------------------------
--
------------------------------------------------------------------------
--

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 23 Apr 2007 10:40:47 -0400

Having thought about this over the weekend, I think I prefer
recommending the voice-back of the de-referenced location, over
providing a PIDF-LO in the 200 OK. For all the reasons that Henning
mentioned. But I don't know how this would work if the negotiated medium
were something other than a voice codec. Does support of this function
for non-voice media need to be recommended?
Barbara

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 6:05 PM
To: Ted Hardie
Cc: 'ECRIT'
Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback:

The whole point is that the caller can, if he so desires, verify the
location information. Incorrect location information is a major source
of mis-routes and false dispatches today (see the NYT article I sent
around a few weeks ago).

Since location information, even without hiding, can be added by a
proxy, this is the only way for the end system to determine what
information will be conveyed to the PSAP in all cases. In existing
system, finding this out is extremely tedious and burdensome to the
PSAP, as you actually have to call 911 to see what address your carrier
has registered for you. You really don't want to resolve the "No, I'm
not living at 123 Main Street, that's my billing address"  
during an emergency call.

I have no objection to returning this PSAP-seen information in some
other way, such as location-conveyance, but I expected to hear screams
from the hide-location crowd in that case. Thus, I was trying to find a
way that achieves most of the goals, while not stepping on sensitive
toes. Since the existing test text includes the return of location
information, albeit in a format that is left unspecified (which should
be fixed), I'm happy with that.

I also have no objection to making this an optional request in the call,
so that unattended test calls do not generate this, but I'm not
convinced that the complexity is worth it.

Thus, I believe that this mechanism adds significantly to the overall
reliability of the system and we should encourage that it be provided,
whether as location-conveyance, audio or just a PIDF-LO attachment in
the 200 OK. (This generally won't work well, given the difficulty real
phones have with multipart, but that's a different
topic.)

Henning

On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote:

>> Please look at -phonebcp for the current test procedure.  This would 
>> add a step.
>

---

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

You have the problem with the deaf community; a very vocal and effective
lobbyist for something I consider a very reasonable point of view: they want
equivalent service.  The specs require support for IM and real time
interactive text.  If that is the media asserted on the test INVITE, they
would expect the location coming back as text.

Similarly, if they ask for video, they are expecting sign language.  I have
a query into them about the practicality of text to sign language.  I don't
see why it won't work just fine.  Presumably you wouldn't have a problem
with that.

Brian

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Monday, April 23, 2007 10:41 AM
> To: Henning Schulzrinne; Ted Hardie
> Cc: ECRIT
> Subject: [Ecrit] phonebcp and testing location correctness
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 23 Apr 2007 11:46:44 -0400

I would think that video letter-by-letter automated spelling of a
location would be rather tedious to watch.

Could we send a JPG picture of a street map with a star where the
location is?
Barbara 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, April 23, 2007 11:10 AM
To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie'
Cc: 'ECRIT'
Subject: RE: [Ecrit] phonebcp and testing location correctness

You have the problem with the deaf community; a very vocal and effective
lobbyist for something I consider a very reasonable point of view: they
want equivalent service.  The specs require support for IM and real time
interactive text.  If that is the media asserted on the test INVITE,
they would expect the location coming back as text.

Similarly, if they ask for video, they are expecting sign language.  I
have a query into them about the practicality of text to sign language.
I don't see why it won't work just fine.  Presumably you wouldn't have a
problem with that.

Brian

> mentioned. But I don't know how this would work if the negotiated 
> medium were something other than a voice codec. Does support of this 
> function for non-voice media need to be recommended?
> Barbara
> 

> from the hide-location crowd in that case. Thus, I was trying to find 
> a way that achieves most of the goals, while not stepping on sensitive

> >> Please look at -phonebcp for the current test procedure.  This 
> >> would add a step.
> >

---

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

Yeah, maybe.  I don't know how well that works on MPEG encoded video.

However, spelling is just about the only way to sign a street address; there
are no signs for some street names and many city names.  Spelling is one of
the most common signs everyone learns.  Good CAs spell really fast.

Brian

> Sent: Monday, April 23, 2007 11:47 AM
> To: Brian Rosen; Henning Schulzrinne; Ted Hardie
> Cc: ECRIT

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Apr 2007 11:32:26 -0700

>the most common signs everyone learns.  Good CAs spell really fast.

I think you are now seriously over-engineering a test system.  Saying that
the test system can be expected to return the location in a form which
may be rendered by the device at its UI discretion is the right on-the-wire
choice.  Moving from that to one where you negotiate and then carry
the UI presentation itself is a distant second.  Decided that negotiation
must carry all possible representations is silly.  For a test system,
representations of the location in text are likely to be valid for pretty
much any user and if you add in voice to text, you've covered the deaf
and blind communities as well as the users with both of those facilities.
Allowing an image with a map might be useful, but switching to video
to watch someone finger-spell on a letter by letter basis is now targeting
a very limited audience:  those with very high end devices, no ability
to read text, and who are guaranteed to be able to map the finger-spelled
version to whatever sign is normally used in their language community
for the area/street/etc.

You do realize that you have whacked yourself into an internationalization
problem as well, right?  British Sign and American Sign Language are not mutual
intelligible, and you're now going to have to negotiate sign language communities
of interest, even where you can presume a mutually intelligible language in text?

Send the location object, and let the local rendering engine worry about it!  It
will be configured for the user's needs.

And, since I haven't said this for a day or two, it is now very, very clear to me
that the document needs to cover both an automated test system and
a separate user-invoked one.  If our putative high-end-system-using
signer loses his dhcp lease and gets a new IP, having the system start
signing at him is going way past the principle of least surprise.

					Ted

---

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

Ted

You just haven't been in the room with the deaf folks much.

They reasonably demand equal service.  They get it, because they ask for
reasonable accommodation.  There are laws about that.  We pay attention.
It's the right thing to do.

There is no technical difficulty in providing text to signing.  I don't
think an IETF spec has to say that, it just says: responds with a media
stream in the form negotiated containing the location in a human
understandable form (e.g. using text to speech).  

Agree that automated test is different from user interactive test.

Brian

> Sent: Monday, April 23, 2007 2:32 PM
> To: Brian Rosen; 'Stark, Barbara'; 'Henning Schulzrinne'
> Cc: 'ECRIT'
> source
> screams
> provided,

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Apr 2007 15:30:39 -0400

To echo Ted, providing machine-readable location is the right 
*on-the-wire* choice.  Given a machine-readable LO, the user's equipment 
can render it as text, braille, a map, sign language, or interpretive 
dance -- it's much more easily adaptable for users with different 
abilities.

If you force the presentation onto the wire, you only get the 
presentation that the server sends you.

--RB

---

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

You want a video endpoint that could be used by a deaf user to render video
from text?

You want every telephone that could be used by a blind user to render audio
from text?

This is a local service, and can reasonably use local conventions (and
caller prefs).

Brian
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Monday, April 23, 2007 3:31 PM
> To: Brian Rosen
> Cc: 'Ted Hardie'; 'Stark, Barbara'; 'Henning Schulzrinne'; 'ECRIT'
> Subject: Re: [Ecrit] phonebcp and testing location correctness
> 
> >>> are no signs for some street names and many city names.  Spelling is
> one
> >> of
> >> problem as well, right?  British Sign and American Sign Language are
> not
> >> mutual
> >> of interest, even where you can presume a mutually intelligible
> language
> >> in text?
> >>
> >> Send the location object, and let the local rendering engine worry
> about
> >> it!  It
> >>>> I don't see why it won't work just fine.  Presumably you wouldn't
> have
> >> a
> >>>> problem with that.
> >>>>
> >>>> Brian
> >>>>
> overall

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Apr 2007 13:04:24 -0700

>You just haven't been in the room with the deaf folks much.

Brian, I have been in the room with lots of deaf folks.  I used to
sign fairly fluently because I worked with both ASL interpreters
and deaf engineers.  I'm rusty, but plenty aware of the concerns.

>It's the right thing to do.

Giving reasonably equal service is the law and it is the right thing to do.
It is also the right thing to do to meet the needs of multiple language
communities, to recognize that some of the folks using a location
object will not be locals, and to provide facilities for that.  But the
way you are proposing to meet those needs is not the most effective
solution.   Will you provide for the needs of the deaf-blind by shipping
braille punches over the wire?  No, you will ship something that you
presume their UI can transform into something they can read and
which they will use for further interaction. 

Shipping a location object back with the presumption that the that
the user who needs text-to-signing will have a UI that provides
it makes a lot more sense, just as a UI can provide multiple ways to
present a geolocation or translate the pidf-lo entities into something
meaningful in the language of the user (Does the read aloud you have
in mind really say "A6" or does it say "street" or "rue" or "calle" or
"Strasse" or "ø¥Ã¬" ?)

>understandable form (e.g. using text to speech). 

This form of content negotiation is not trivial and maintaining the facilities
to meet the needs of all users is certainly not trivial.  Imagine for a moment
you got stuck going 3ppp SA2, and you are in Beijing.  You're running
a test of your system to make sure it works with the Beijing emergency
services.  For this to work in your test scenario, they will need to
take the location you provide them in a nice independent format,
confirm it (which can be done very simply at the protocol level by
re-affirming it in that independent format), then move it from that format
into English for read-aloud.  Since that's a dominant language, you're probably
in luck. If your native language were Wolof, you would have a harder problem,
and I suspect you're going to get a non-native version (French, maybe)
instead. If your native language were British Sign, you definitely would
have a harder problem.  But if the British Sign user had gotten back the
confirming location object and had it rendered into sign, they would be
getting back something that their UI can likely handle (either by converting
it to appropriate text or the appropriate sign).

Note that I am not arguing for providing this back just for the deaf users.
This is the right way to design the system for all the users, for the localization
reasons I gave above.  It's just how that localization works in this case.

If a user would need facilities for specific media streams (e.g. audio, text,
video), then the loopback mechanism can be used to test whether the PSAP
can handle those media.  But that doesn't need to be combined with using
those media to do this type of confirmation.

>Agree that automated test is different from user interactive test.

Well, we've gotten to one point of agreement, at least.  Good for that.

				Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Apr 2007 15:57:50 -0400

If a video endpoint is given a machine readable response, then it has to
render something meaningful to the user.  A deaf user may be able to read a
map, but a videophone constructing the map may or may not be easy.  It would
be impossibly difficult to expect the videophone to render video of text to
signing.  The PSAP could provide that at its end reasonably.

Having a telephone render speech from text for a blind user is similarly
unreasonable, and also reasonable from the PSAP side.

Sending the presentation on the wire as media in the form the SDP specifies
is not unreasonable.  Forcing the endpoint to generate media from machine
readable information is unreasonable.

Barbara doesn't want to send machine readable information.

Brian

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Monday, April 23, 2007 3:51 PM
> To: Brian Rosen
> Cc: 'Richard Barnes'; 'Stark, Barbara'; 'ECRIT'
> I don't understand your response here.  But I agree with Richard and
> Ted.
> 
> -andy
> 
> On Apr 23, 2007, at 3:42 PM, Brian Rosen wrote:
> 
> >>>>> However, spelling is just about the only way to sign a street
> >>>>> address;
> >>>> there
> >>>> I think you are now seriously over-engineering a test system.
> >>>> Saying
> >> that
> >>>> may be rendered by the device at its UI discretion is the right
> >>>> on-the-
> >>>> wire
> >>>> intelligible, and you're now going to have to negotiate sign
> >>>> language
> >>>> communities
> >>>> And, since I haven't said this for a day or two, it is now very,
> >>>> very
> >>>> clear to me
> >>>>>> lobbyist for something I consider a very reasonable point of
> >>>>>> view:
> >> they
> >>>>>> want equivalent service.  The specs require support for IM and
> >>>>>> real
> >>>> time
> >>>>>> Similarly, if they ask for video, they are expecting sign
> >>>>>> language.
> >> I
> >>>>>>> call, so that unattended test calls do not generate this, but
> >>>>>>> I'm
> >> not
> >>>>>>> whether as location-conveyance, audio or just a PIDF-LO
> >>>>>>> attachment
> >> in
> >>>>>>> the 200 OK. (This generally won't work well, given the
> >>>>>>> difficulty
> >>>> real

---

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

Brian,

-andy

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Apr 2007 14:22:51 -0700

>signing.  The PSAP could provide that at its end reasonably.

Are you imagining it gets sent video of text, and turns that into video of
signing?  That would be very hard.   But the core object isn't video in
the proposal I've made; it is the PIDF-LO.  Assuming the PIDF-LO can
be rendered into text, any text-to-sign system available to the UI
would work. 

If there is no text-to-sign available, text alone would be available.  You
were only talking about finger spelling, if I understood your original proposal,
and using a large finger spelling font would cover at least that much.
If something better were available I would, of course, expect it to be used.

>unreasonable, and also reasonable from the PSAP side.

Why do you think having the phone do this is unreasonable?  There are
already phones that do short speech-to-text (e.g. the Samsung p207)
and that is much harder.  Both the p207 and a890 also do speech-to-text.

I am assuming a specialized device or software set, I grant
you, but it seemed to me you were as well.  Are you concerned that this
requirement would have to be met by all phones?  Using a relay
seems much more likely to be the case for a special needs user and
a regular phone.

>readable information is unreasonable.

This seems like a dogmatic assertion.  It certainly isn't going to be unreasonable
to generate text from the pidf-lo, and that really is going to cover a lot of
cases where the phone has a screen. 

>Barbara doesn't want to send machine readable information.

If I understood Barbara, she wasn't going to fight on this point, as she
thought it was really going to be up to regulators rather than us.  But
perhaps we should both speak for ourselves and let Barbara raise what
concerns she has.

					Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Apr 2007 17:27:56 -0400

Ted

Although it may be possible for a videophone to render text, and might be
acceptable to most deaf folks, do you think it is reasonable for a voice
phone to render speech for a blind person?  I get to needing text to sign by
realizing I have to serve blind folks by the media of their choice and back
myself into having to serve signing folks in the media of their choice.

Is it reasonable for any phone to render text in a variety of languages for
this purpose?  Do you think, realistically, it will happen?

Given Barbara's concerns about revealing location, do you think PSAPs will
choose to jeopardize local access network's efforts to supply location by
revealing it in machine readable form?

On the other hand, do you think it would be reasonable for a PSAP (or some
contractor operating under authority of a PSAP or other agency) to provide
text to speech and text to sign for this purpose?

I fear we can write the specs to say send a PIDF back, it will not result in
a useful service to users.  

Brian

> Sent: Monday, April 23, 2007 4:04 PM

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Apr 2007 17:42:30 -0400

In the case of video, plain video-rendered text is obviously the  
easiest. After all, CNN and Bloomberg have no problem producing video  
that contains text, nor does your local airport. (Indeed, titling  
hardware and software is a common staple in every video production  
facility.) MPEG does the same video compression as JPEG, so you get  
the same quality and artifacts.

As Barbara (?) mentioned, a map would work nicely, although it may be  
hard to read on the usual CIF/QCIF video devices with heavy compression.

Personally, I'd prefer having both as a matter of course, i.e., SIP  
location conveyance for PIDF-LO and a media-appropriate format (text- 
to-speech, etc.). From a user perspective, the latter is easier to  
work with for limited-UI and limited-capability devices, such as your  
typical Polyberg video-conferencing system or a voice-only terminal  
adapter ("ATA"), which isn't suddenly going to incorporate a full- 
fledged text-to-speech system just to read back addresses. As Brian  
notes, this sensible answer may not be feasible if the local carrier  
insists on "no machine-readable format" and the regulator or PSAP  
lets them get away with it.

Henning

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Apr 2007 14:41:22 -0700

>and that is much harder.  Both the p207 and a890 also do speech-to-text.

I meant they do text-to-speech.  Sorry.
				Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Apr 2007 17:45:02 -0400

Messages crossing in the Ether.

> be rendered into text, any text-to-sign system available to the UI
No, I am imagining the PSAP sends video of finger spelling.  I am not
imagining a videophone could reasonably produce finger spelling from PIDF.
I am imagining a server at a PSAP could do that, but see below.

> If something better were available I would, of course, expect it to be
As per my previous message, I got to a requirement that the PSAP send finger
spelling by working back from speech for a blind person.

> and that is much harder.  Both the p207 and a890 also do speech-to-text.
I am reasonably conversant in the technology to do text to speech for street
addresses.  It is not something that would fit in current phones, or even
what is contemplated for next generation.  There could be a hybrid system
like that being developed for speech understanding in mobile devices, where
the quality of the audio coming over the air is hard to do speech
recognition on.  In that environment, they do some of the front end work on
the mobile, and then do the rest on the server, with a protocol in the
middle.  We have a work group doing the protocol (speechsc).  I could
imagine some kind of hybrid for text to speech, but that would be a lot of
work to develop, and not be justified for this purpose (alone).  

> seems much more likely to be the case for a special needs user and
Letting a relay do this did not occur to me, I'll admit, and that may help.
I was thinking it would have to be done by all phones.

> cases where the phone has a screen.
Agree, if you get a PIDF-LO.

> perhaps we should both speak for ourselves and let Barbara raise what
I'll do the same

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Apr 2007 15:29:29 -0700

>Messages crossing in the Ether.

Twice, at least.  I'm sending this knowing it's probably crossing
one of yours.

>spelling by working back from speech for a blind person.

So, the base requirement is "Return the location so that the user can
confirm it".  That's underneath all of this, and we're working out how,
for a variety of users, right?
>what is contemplated for next generation. 

Is there something about addresses that is particularly bad about this?  At
least Samsung, Nokia, and Pantech have phones that do speech to text in multiple
languages (English, Korean, Russian, and Mandarin, if I read the press
reports right).  This isn't next generation for mobiles; these are shipping
phones (The Nokia Series 60 and the Pantech PG-6200, PG-8000, and
PG-3700).  There is even 50k free download of a VoiceXML SDK from
Voicent.  These aren't low end phones (or targeted at low-end phones),
but it also doesn't seem to be the case that text-to-speech is generally
seen out of the ballpark here.

>There could be a hybrid system
>recognition on.

Why is speech recognition needed?  The phone gets an object, translates it
from XML to localized text, and reads it out.

> In that environment, they do some of the front end work on

Ah, I was assuming relays where the phones were not designed with
UIs for their user communities.  I believe this is reasonable for a test
service that is user-initiated.   It would again make automated testing
a distinct case, as the idea of the phone calling up the relay...just not
okay.

>Agree, if you get a PIDF-LO.

If we agree on this point, then the architecturally correct way forward is
probably pretty obvious.

>> perhaps we should both speak for ourselves and let Barbara raise what

Barbara, as you marshall your comments, can you think about relays
in addition to the methods described above?

			thanks,
				Ted

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 24 Apr 2007 09:13:32 -0400

I thought Brian was doing a great job expressing my views...

Oh well.
I'm thinking that it does makes sense for the test capability described
in phonebcp to include returning a PIDF-LO, since that really is the
most flexible and easiest format. But, since I think location-hiding
access providers won't like this to be used in areas they serve, I think
it would also be good to describe returning the de-referenced location
in media, as well. While this isn't the "best" way to do it, it's better
than an all-or-nothing solution, where either a PIDF-LO is returned, or
people get no location confirmation capability at all. I wasn't going to
fight it in phonebcp, because I figured regulators could be convinced to
use the "nothing" approach in exchange for access providers building the
ability to deliver location. 

The existence of relays to support in translation is an interesting
topic, but I don't think it has a real impact on the possible options
for how or whether a PSAP returns a dereferenced location. I don't think
the PSAP can assume a relay, unless we want to get into having the PSAP
authenticate where test requests come from. And I'm pretty sure that
no-one wants that!
Barbara

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Monday, April 23, 2007 6:29 PM
To: Brian Rosen; 'Andrew Newton'
Cc: Stark, Barbara; 'ECRIT'
Subject: RE: [Ecrit] phonebcp and testing location correctness

>Messages crossing in the Ether.

Twice, at least.  I'm sending this knowing it's probably crossing one of
yours.

>> If there is no text-to-sign available, text alone would be available.

>> You were only talking about finger spelling, if I understood your 
>> original proposal, and using a large finger spelling font would cover

>> at least that much.
>As per my previous message, I got to a requirement that the PSAP send 
>finger spelling by working back from speech for a blind person.

> >
>> >Having a telephone render speech from text for a blind user is 
>> >similarly unreasonable, and also reasonable from the PSAP side.
>>

>I am reasonably conversant in the technology to do text to speech for 
>street addresses.  It is not something that would fit in current 
>phones, or even what is contemplated for next generation.

Is there something about addresses that is particularly bad about this?
At least Samsung, Nokia, and Pantech have phones that do speech to text
in multiple languages (English, Korean, Russian, and Mandarin, if I read
the press reports right).  This isn't next generation for mobiles; these
are shipping phones (The Nokia Series 60 and the Pantech PG-6200,
PG-8000, and PG-3700).  There is even 50k free download of a VoiceXML
SDK from Voicent.  These aren't low end phones (or targeted at low-end
phones), but it also doesn't seem to be the case that text-to-speech is
generally seen out of the ballpark here.

>like that being developed for speech understanding in mobile devices, 
>where the quality of the audio coming over the air is hard to do speech

>recognition on.

Why is speech recognition needed?  The phone gets an object, translates
it from XML to localized text, and reads it out.

> In that environment, they do some of the front end work on the mobile,

>and then do the rest on the server, with a protocol in the middle.  We 
>have a work group doing the protocol (speechsc).  I could imagine some 
>kind of hybrid for text to speech, but that would be a lot of work to 
>develop, and not be justified for this purpose (alone).
>
>>
>> I am assuming a specialized device or software set, I grant you, but 
>> it seemed to me you were as well.  Are you concerned that this 
>> requirement would have to be met by all phones?  Using a relay seems 
>> much more likely to be the case for a special needs user and a 
>> regular phone.

Ah, I was assuming relays where the phones were not designed with UIs
for their user communities.  I believe this is reasonable for a test
service that is user-initiated.   It would again make automated testing
a distinct case, as the idea of the phone calling up the relay...just
not okay.

>> >is not unreasonable.  Forcing the endpoint to generate media from 
>> >machine readable information is unreasonable.
>>
>> This seems like a dogmatic assertion.  It certainly isn't going to be

>> unreasonable to generate text from the pidf-lo, and that really is 
>> going to cover a lot of cases where the phone has a screen.

If we agree on this point, then the architecturally correct way forward
is probably pretty obvious.

>> If I understood Barbara, she wasn't going to fight on this point, as 
>> she thought it was really going to be up to regulators rather than 
>> us.  But perhaps we should both speak for ourselves and let Barbara 
>> raise what concerns she has.
>I'll do the same

Barbara, as you marshall your comments, can you think about relays in
addition to the methods described above?

			thanks,
				Ted

*****

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