Subject: [Ecrit] A Concrete Proposal for LbyR Emergency Calling

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Apr 2007 08:46:15 -0400

As Hannes and Henning have pointed out, almost every proposal is going 
to require modifications to either LoST or the LCP(s).  In light of 
that, ISTM that our goal should be to be "minimally invasive", i.e., to 
make the smallest number of changes to enable a reliable emergency 
calling function when location is only provisioned by reference.  Here's 
my proposed set of changes:

1. Enable DHCP / LCP to convey a pointer to a LoST resolver (as is done 
with DNS servers within an access network)
2. Enable LoST to carry location-by-reference (possibly with an 
statement to limit applicability)

A call flow would look something like this:
1. DHCP Server -> UA: LoST Resolver URI
2. LIS -> UA: Location reference
3. UA -> LoST Resolver: LoST query with Location reference
4. LoST Resolver -> UA: LoST response

This would enable many of the approaches being discussed.  LoST, 
extended in this way, could be used as the mechanism to deliver PSAP 
URIs, country codes, service boundaries, etc, since LoST already conveys 
them.  And it mitigates the problem of the UA having to use the "right" 
LoST resolver (i.e., one that can do the dereference) since it allows 
the access network to explicitly indicate which one should be used.

Thoughts?
--Richard

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Apr 2007 15:08:36 +0200

Hi Richard,

Richard Barnes wrote:
> that, ISTM that our goal should be to be "minimally invasive", i.e., 
> to make the smallest number of changes to enable a reliable emergency 
> calling function when location is only provisioned by reference.

Keeping changes small is something I like.

>   Here's my proposed set of changes:
>
> 1. Enable DHCP / LCP to convey a pointer to a LoST resolver (as is 
> done with DNS servers within an access network)
Would 
http://tools.ietf.org/id/draft-ietf-ecrit-dhc-lost-discovery-01.txt do 
the job for discovering a LoST server via DHCP?

> URIs, country codes, service boundaries, etc, since LoST already 
> conveys them.  And it mitigates the problem of the UA having to use 
> the "right" LoST resolver (i.e., one that can do the dereference) 
> since it allows the access network to explicitly indicate which one 
> should be used.
>
> Thoughts?
This would work.

Ciao
Hannes

---

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

Mine is:

1. DHCP server -> UA: HELD server URI
2. UA -> HELD server: Location request with identifiers
3. HELD server -> LoST Server: query with LbyV
4. LoST server -> HELD server: LoST Response
5. HELD server -> UA: LbyR + LoST response

As before, in many cases, steps 3/4 can be omitted because the LIS service
area is known to be within one PSAP boundary

Brian

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 8:46 AM
> To: ECRIT
> Subject: [Ecrit] A Concrete Proposal for LbyR Emergency Calling
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Apr 2007 15:17:39 +0200

The optimized version.

The only problem with both versions: In a mobility environment the LoST 
response might have changed. Hence, the end host either (a) periodically 
needs to trigger step (2) - (5) or the protocol used between the SIP UA 
and the LIS is not based on HTTP but rather on SIP  (and the LIS sends a 
notification when the location changed enough so that the LoST response 
changed as well).

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 09:18:41 -0400

I'll again protest as you're converting HELD into a SIP configuration  
protocol. This is an architecturally fundamentally bad idea.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 09:21:16 -0400

Periodically doesn't cut it, since there's no way for the device to  
know how long it will be residing within that service region.  
(Obviously, querying every few seconds will work well enough, but  
this will kill any mobile device's battery.) I keep saying that, but  
somehow it doesn't seem to register. If you go that route, you need a  
subscription mechanism - just like the one already offered by SIP  
configuration.

On Apr 18, 2007, at 9:17 AM, Hannes Tschofenig wrote:

> The optimized version.
>
> The only problem with both versions: In a mobility environment the  
> LoST response might have changed. Hence, the end host either (a)  
> periodically needs to trigger step (2) - (5) or the protocol used  
> between the SIP UA and the LIS is not based on HTTP but rather on  
> SIP  (and the LIS sends a notification when the location changed  
> enough so that the LoST response changed as well).
>

---

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

Yup. 

I tried to hint to the subscription mechanism
 
> -----Ursprüngliche Nachricht-----
> Von: Henning Schulzrinne [mailto:[email-masked]] 
> Gesendet: Mittwoch, 18. April 2007 15:21
> An: Hannes Tschofenig
> Cc: 'ECRIT'
> Betreff: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling
>

---

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

Where did we cross a bright line?

I must have missed it.

What you are saying is that an endpoint can do an LCP request and a LoST
request separately, but something that combines them has to be SIP
configuration.

What if the endpoint uses, oh, say, AIM?  Skype?

LoST returns dialstrings.  Is that SIP configuration?
HELD returns things that go in -conveyance.  Is that SIP configuration?

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 9:19 AM
> To: Brian Rosen
> Cc: 'Richard Barnes'; 'ECRIT'
> Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling
>

---

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

Well, subscription, but presence, not configuration.

The LIS notifies you when you go outside the boundary.  The endpoint never
sees the boundary, but the LIS (which is a presence server after all) does.

If you had LbyV from the LIS, that's what you want: tell me when I go beyond
this boundary.

Brian

> Sent: Wednesday, April 18, 2007 9:21 AM
> To: Hannes Tschofenig
> Cc: Brian Rosen; 'ECRIT'

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 18 Apr 2007 10:11:27 -0400

I'm a bit fuzzy as to who will be running LoST servers. I thought I'd
read somewhere that VSPs might have cached LoST data, and be able to
tell their endpoints to come to their LoST server, first. If this is
true, and if I don't trust VSPs to dereference, can I trust LoST servers
to dereference?

Or did I misunderstand the LoST server architecture somewhere down the
line?
Barbara

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2007 8:46 AM
To: ECRIT
Subject: [Ecrit] A Concrete Proposal for LbyR Emergency Calling

1. Enable DHCP / LCP to convey a pointer to a LoST resolver (as is done
with DNS servers within an access network) 2. Enable LoST to carry
location-by-reference (possibly with an statement to limit
applicability)

A call flow would look something like this:
1. DHCP Server -> UA: LoST Resolver URI
2. LIS -> UA: Location reference
3. UA -> LoST Resolver: LoST query with Location reference 4. LoST
Resolver -> UA: LoST response

Thoughts?
--Richard

*****

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

---

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

I'll speak for the NENA work.  The authoritative LoST servers will be
operated by, or on behalf of the "9-1-1 Authority", which is often one level
higher than a PSAP.  It's most often a county agency, but in some places
it's a state agency, and in other places it really is one PSAP and in other
areas is a regional group of PSAPs not tied to "county" or "state".  The
9-1-1 authority may authorize an access network (or a VSP) to have a replica
of the data, which it can use for a local LoST resolver.

I do think that assuming either the access network or the VSP can actually
control what the endpoint uses for a LoST service is probably not viable.
Consider, for example, a softclient using what we hope will be a standard
api in the laptop to an O/S function that runs all the LCPs to find
location.  The location would be known before the softclient even started
up.  On the other hand, consider a hardwired sipphone that is supplied by a
VSP and is configured to query the VSP's LoST service.  Both are viable,
both should work.

Brian

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2007 10:11 AM
> To: Richard Barnes; ECRIT
> Subject: RE: [Ecrit] A Concrete Proposal for LbyR Emergency Calling
> 
> 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
> 
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Apr 2007 10:54:10 -0400

Henning,

Since LoST is only defined at the XML level, couldn't you just define a 
SIP binding (possibly an event package)?  The target could subscribe 
it's LoST status on the access network LoST resolver.

--RB

Henning Schulzrinne wrote:
> Periodically doesn't cut it, since there's no way for the device to know 
> how long it will be residing within that service region. (Obviously, 
> querying every few seconds will work well enough, but this will kill any 
> mobile device's battery.) I keep saying that, but somehow it doesn't 
> seem to register. If you go that route, you need a subscription 
> mechanism - just like the one already offered by SIP configuration.
> 
>> between the SIP UA and the LIS is not based on HTTP but rather on SIP  
>> (and the LIS sends a notification when the location changed enough so 
>> that the LoST response changed as well).
>>
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Apr 2007 10:56:27 -0400

I think the point is that LCP does one thing (location provisioning) and 
LoST does another (mapping); both are restricted types of configuration.

It's just clean engineering to use distinct protocols for distinct 
functions when possible.

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 11:00:59 -0400

We're all guessing here, but LoST servers have been advocated as  
being run by at least four entities:

- the ISP
- a pseudo-ISP (e.g., a hotel or mid-sized enterprise)
- the VSP
- some public entity, such as a state, DOT or FEMA (or even NENA)

I don't think any of us knows, but I think we have to prepared for  
the case that there will be multiple hierarchies and certainly  
multiple resolvers, just like we have for DNS today. Thus, a single  
UA might have access to multiple LoST servers (and that's a good thing).

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 11:04:18 -0400

Yes, you've just re-discovered how SIP configuration works.

On Apr 18, 2007, at 10:54 AM, Richard Barnes wrote:

> Henning,
>
> Since LoST is only defined at the XML level, couldn't you just  
> define a SIP binding (possibly an event package)?  The target could  
> subscribe it's LoST status on the access network LoST resolver.
>
> --RB
>
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Apr 2007 11:25:46 -0400

The difference being that LoST is (1) more specialized than general SIP 
configuration, and (2) more generally applicable than SIP configuration.
--RB

Henning Schulzrinne wrote:
>> Since LoST is only defined at the XML level, couldn't you just define 
>> a SIP binding (possibly an event package)?  The target could subscribe

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Apr 2007 11:31:55 -0400

But your notion of a SIP event package ties it to SIP, so you've now  
created some weird hybrid which is neither LoST nor SIP  
configuration. Plus, again, you've increased UA behavorial options,  
as the UA now has to discover whether to use LoST-over-SIP or LoST- 
over-HTTP. Yet more complexity and failure modes.

On Apr 18, 2007, at 11:25 AM, Richard Barnes wrote:

> The difference being that LoST is (1) more specialized than general  
> SIP configuration, and (2) more generally applicable than SIP  
> configuration.
> --RB
>
>
>
>>> define a SIP binding (possibly an event package)?  The target  
>>> could subscribe it's LoST status on the access network LoST  
>>> resolver.
>>>
>>> --RB
>>>
>>>
>