Subject: [Ecrit] Multiple sources of location information and timestamp

From: <[email-masked]>
Date: Tue, 19 Sep 2006 13:02:38 +0300

Hi all,

UE may include multiple location objects into emergency session INVITE.
To my knowledge it has not been defined how to select which one of the
location objects is used for routing to PSAP if the location objects
lead to different PSAPs. I think timestamp when the location objects
were created could be useful in selecting the most recent location
information but PIDF defines timestamp only for the whole presence
tuple. Has this been discussed and does anybody see this as a problmem?
Or is there some way to identify the time when the location object was
created?

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

---

From: Andrew Newton <[email-masked]>
Date: Tue, 19 Sep 2006 06:50:20 -0400

On Sep 19, 2006, at 6:02 AM, [email-masked] wrote:

> Hi all,
>
> UE may include multiple location objects into emergency session  
> INVITE. To my knowledge it has not been defined how to select which  
> one of the location objects is used for routing to PSAP if the  
> location objects lead to different PSAPs. I think timestamp when  
> the location objects were created could be useful in selecting the  
> most recent location information but PIDF defines timestamp only  
> for the whole presence tuple. Has this been discussed and does  
> anybody see this as a problmem? Or is there some way to identify  
> the time when the location object was created?
>
> Br,
>         Vesa Hakkarainen

We've been round and round on the discussion about what to feed the  
routing function (LoST).  Until now, we have assumed it is the  
location being conveyed to the PSAP.  But there seems to be a  
problem.  If the input to the routing function is complex, the  
results are undesirable.  Yet, there seems to be a desire to have the  
PSAPs get these very complex shapes.

Perhaps there should be two sets of location info, each clearly  
marked: one for routing, one for the PSAPs.  I'd also suggest giving  
the PSAPs the input to the routing function as well, but clearly  
marking the purpose of the information could help solve this problem.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 21 Sep 2006 19:32:16 -0500

At 06:50 AM 9/19/2006 -0400, Andrew Newton wrote:

>On Sep 19, 2006, at 6:02 AM, 
><mailto:[email-masked]>[email-masked] 
>wrote:
>
>>Hi all,
>>
>>location objects is used for routing to PSAP if the location objects lead 
>>to different PSAPs. I think timestamp when the location objects were 
>>created could be useful in selecting the most recent location information 
>>but PIDF defines timestamp only for the whole presence tuple. Has this 
>>been discussed and does anybody see this as a problmem? Or is there some 
>>way to identify the time when the location object was created?
>>
>>Br,
>>         Vesa Hakkarainen
>
>routing function (LoST).  Until now, we have assumed it is the location 
>being conveyed to the PSAP.  But there seems to be a problem.  If the 
>input to the routing function is complex, the results are 
>undesirable.  Yet, there seems to be a desire to have the PSAPs get these 
>very complex shapes.
>
>Perhaps there should be two sets of location info, each clearly marked: 
>one for routing, one for the PSAPs.

SIP does not mandate support for multipart message bodies (which is a 
problem for an SDP and PIDF-LO message body), but now you are suggesting 3 
message bodies in an INVITE?

Also, SIP allows UDP, and several vendors have not implemented TCP (despite 
it being mandatory per 3261).  If there are now 2 message bodies containing 
location, there would be a growing problem (literally) of messages being or 
becoming too large to get to the destination because some middle SIP 
intermediary doesn't support TCP.

Please don't say it won't happen, as it already has to us with a partner 
vendor (and that's before we included a large location body or two)

>  I'd also suggest giving the PSAPs the input to the routing function as 
> well, but clearly marking the purpose of the information could help solve 
> this problem.
>
>-andy

---

From: Andrew Newton <[email-masked]>
Date: Thu, 21 Sep 2006 20:43:42 -0400

On Sep 21, 2006, at 8:32 PM, James M. Polk wrote:
> SIP does not mandate support for multipart message bodies (which is  
> a problem for an SDP and PIDF-LO message body), but now you are  
> suggesting 3 message bodies in an INVITE?

Actually, I was thinking more of multiple locations within PIDF-LO,  
each marked as to its purpose.

> Also, SIP allows UDP, and several vendors have not implemented TCP  
> (despite it being mandatory per 3261).  If there are now 2 message  
> bodies containing location, there would be a growing problem  
> (literally) of messages being or becoming too large to get to the  
> destination because some middle SIP intermediary doesn't support TCP.
>
> Please don't say it won't happen, as it already has to us with a  
> partner vendor (and that's before we included a large location body  
> or two)

TCP vs. UDP is a battle for another day.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 21 Sep 2006 19:53:24 -0500

Hi Andy,

PSAPs in the USA today for cellular can only receive a point, point with
uncertainty circle, point with altitude, or point with altitude an
uncertainty radius. 

These translate to 2D point, 3D point, circle and sphere as were defined
in the GeoShapes draft. This restriction comes about because of what can
be provided over the E2 interface between the MPC/GMLC and the ALI.

In the UK and Europe shape types are not so restricted as they use the
OMA MLP specification. That is, they can receive any of the shape types
defined in the geoshape draft with the exception of the Prism.  So your
point that these are complexity of these shapes is a little unfounded
given that they can be received today.

Further, one of the purposes of the LIS in the NENA architecture is to
ensure that locations provided to end-points for are in a suitable form
to be digested by the local PSAP, and hence should also be able to yield
a valid route  to the local PSAP. To that end, the PSAPs already have
the say in route determination you described below.

Cheers

James

________________________________

From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, 19 September 2006 8:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ecrit] Multiple sources of location information and
timestamp

Hi all, 

Br, 
        Vesa Hakkarainen 

We've been round and round on the discussion about what to feed the
routing function (LoST).  Until now, we have assumed it is the location
being conveyed to the PSAP.  But there seems to be a problem.  If the
input to the routing function is complex, the results are undesirable.
Yet, there seems to be a desire to have the PSAPs get these very complex
shapes.

Perhaps there should be two sets of location info, each clearly marked:
one for routing, one for the PSAPs.  I'd also suggest giving the PSAPs
the input to the routing function as well, but clearly marking the
purpose of the information could help solve this problem.

-andy

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

---

From: Andrew Newton <[email-masked]>
Date: Thu, 21 Sep 2006 21:17:59 -0400

On Sep 21, 2006, at 8:53 PM, Winterbottom, James wrote:
> PSAPs in the USA today for cellular can only receive a point, point  
> with uncertainty circle, point with altitude, or point with  
> altitude an uncertainty radius.
>
> These translate to 2D point, 3D point, circle and sphere as were  
> defined in the GeoShapes draft. This restriction comes about  
> because of what can be provided over the E2 interface between the  
> MPC/GMLC and the ALI.
>
>
>
> In the UK and Europe shape types are not so restricted as they use  
> the OMA MLP specification. That is, they can receive any of the  
> shape types defined in the geoshape draft with the exception of the  
> Prism.  So your point that these are complexity of these shapes is  
> a little unfounded given that they can be received today.

At what point was I suggesting the PSAPs should not receive these  
complex shapes?

> Further, one of the purposes of the LIS in the NENA architecture is  
> to ensure that locations provided to end-points for are in a  
> suitable form to be digested by the local PSAP, and hence should  
> also be able to yield a valid route  to the local PSAP. To that  
> end, the PSAPs already have the say in route determination you  
> described below.

With all due respect, we are not talking about a NENA architecture.   
We are talking about an ECRIT architecture.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 21 Sep 2006 20:28:35 -0500

> At what point was I suggesting the PSAPs should not receive these

I seem to have misread your comment, my apologies.

> We are talking about an ECRIT architecture.

To the best of my knowledge, ECRIT does not specify how an end-point or
call-server for that matter should learn location information. It does
however concern itself with the provisioning and querying of PSAP and
other service boundaries. To bury our heads in the sand and ignore what
other organizations have already architected and are implementing in
this direction is tantamount to developing a square wheel because we
don't like the people that were offering us a round one. 

This should not be an NIH debate, but one that actually involves the
organizations that are delivering these services today and helping them
to evolve towards a strong safe NG architecture. Ignoring what they have
done does not breed that cooperation.