Subject: [Ecrit] LoST and multiple responses -phone-bcp

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 18 Mar 2011 12:32:24 +0800

I was always under the impression that RFC5222 didn't allow for multiple responses.  Andrea corrected me on this, but it made me think:

Shouldn't -phone-bcp say something about a LoST server offering multiple routes?  I looked, and Section 8 seemed to be the right place, but there isn't anything on it.

The argument is exactly the same as for multiple locations:

  AN/SP-?? A LoST server SHOULD provide at most one emergency service mapping for any combination of service and location.

  ED-?? The device SHOULD select the first valid mapping in a LoST response if multiple mappings are present.

--Martin

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 18 Mar 2011 12:39:17 +0800

Hey Martin,

Just so I am clear on what you are saying.
You could include just a basic sos service URN in the request to the LoST server, but if you were in a jurisdiction that didn't have a single service control point, but required separate service distinction for police, fire or ambulance, then you could get back 3 service mapping response. But it is bad form to allow three service mappings all for police. Is that what you are saying?

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thomson, Martin
> Sent: Friday, 18 March 2011 3:32 PM
> To: Rosen, Brian; [email-masked]
> Subject: [Ecrit] LoST and multiple responses -phone-bcp
> 
> I was always under the impression that RFC5222 didn't allow for multiple
> responses.  Andrea corrected me on this, but it made me think:
> 
> Shouldn't -phone-bcp say something about a LoST server offering multiple
> routes?  I looked, and Section 8 seemed to be the right place, but there
> isn't anything on it.
> 
>   AN/SP-?? A LoST server SHOULD provide at most one emergency service
> mapping for any combination of service and location.
> 
>   ED-?? The device SHOULD select the first valid mapping in a LoST
> response if multiple mappings are present.
> 
> --Martin
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 18 Mar 2011 12:48:10 +0800

On 2011-03-18 at 15:39:17, Winterbottom, James wrote:
> You could include just a basic sos service URN in the request to the 
> LoST server, but if you were in a jurisdiction that didn't have a 
> single service control point, but required separate service 
> distinction for police, fire or ambulance, then you could get back 3 
> service mapping response. But it is bad form to allow three service 
> mappings all for police. Is that what you are saying?

Right.

Given one location and one service, then you should get one mapping.

If you could ask for police, fire and ambulance all at once, then I'd expect a mapping for each (even if all were the same mapping).  But I don't think you can't do that.

--Martin

---

From: "Andrea G. Forte" <[email-masked]>
Date: Fri, 18 Mar 2011 12:22:15 -0400

So, are we saying that for emergency services only, the LoST server will
pick and return one result all the time? If so, how do we account for a
wrong decision on the LoST server part? Are we just leaving that to "human
intervention"? 
There should be at least a level of confidence on the location of the user
falling within some PSAP boundaries.

Again, I am assuming this would apply to emergency services only.

-Andrea

On 3/18/11 12:48 AM, "Thomson, Martin" <[email-masked]>
wrote:

>If you could ask for police, fire and ambulance all at once, then I'd
>expect a mapping for each (even if all were the same mapping).  But I
>don't think you can't do that.
>
>--Martin

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 18 Mar 2011 12:29:55 -0400

My general advice for this kind of thing is that the querier has no way to figure out which of a set of choices is correct.  The LoST server at least has a shot of picking out the best one.

Brian

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 18 Mar 2011 13:06:42 -0400

That might not be categorically true, right?  If there are service boundaries included, then a human has a chance of saying "I'm in this one".

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 18 Mar 2011 13:13:56 -0400

Based on what knowledge the human has that the LoST server doesn't?

In general, I think this case only occurs due to a provisioning error (overlap of service boundaries).  If it does, the LoST server is probably better at figuring it out.

Brian

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 18 Mar 2011 13:52:28 -0400

I'm imagining cases with imprecise location.  If I'm in Luxembourg and located to cell tower level accuracy, then my location value could overlap PSAP boundaries in France and Belgium.  But if I get back mappings for Belgian, French, and Luxemburgish PSAPs, then I can say, "Yes, I'm in Luxembourg".

--Richard

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 18 Mar 2011 14:17:46 -0400

Today, these are decided by cell tower.  Calls from a given sector route to a specific PSAP.  
Generally, asking for user input during a call is frowned upon.

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Mar 2011 16:29:40 -0400

See
http://www.policechiefmagazine.org/magazine/index.cfm?fuseaction=display_arch&article_id=2069&issue_id=42010
for a similar solution: The caller is asked to input a zip code or city name.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 18 Mar 2011 16:38:48 -0400

I'm familiar with this.  It's really a bad solution in my opinion, given that the cellid comes in the SMS messaging protocol and we already have mapping from cell id to PSAP in current systems.  

You send a message to the short code.  It replies with a request to text your address (as a civic).  It then forwards the text to the PSAP.

Brian

---

From: "Andrea G. Forte" <[email-masked]>
Date: Fri, 18 Mar 2011 17:00:56 -0400

If the LoST server decides wrong and routes my call to the wrong PSAP, the
9-1-1 operator will have to "discover" that a wrong routing has taken
place, will have to find the correct PSAP and will have to transfer the
call to the correct PSAP. All of this while I am on the call. As a user I
would rather "select" one of the returned multiple mappings when making
the call in the first place.

-Andrea

On 3/18/11 4:38 PM, "Rosen, Brian" <[email-masked]> wrote:

>I'm familiar with this.  It's really a bad solution in my opinion, given
>that the cellid comes in the SMS messaging protocol and we already have
>mapping from cell id to PSAP in current systems.
>
>You send a message to the short code.  It replies with a request to text
>your address (as a civic).  It then forwards the text to the PSAP.
>
>Brian
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 19 Mar 2011 05:32:44 +0800

I think that it is also important to note, that PSAP to which the call was directed will likely only have access to exactly the same information that the original routing decision was made on. Consequently if it was the wrong PSAP that was picked, and only one result can be returned from LoST, how without something very manual can this problem be rectified?

Cheers
James

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Andrea G. Forte [[email-masked]]
Sent: Friday, March 18, 2011 4:00 PM
To: Rosen, Brian; Henning Schulzrinne
Cc: Thomson, Martin; [email-masked]
Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp

-Andrea

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Mar 2011 17:43:03 -0400

According to some local politicians that have watched too many Ayn Rand movies, government services should be privatized. Thus, we'll soon get a choice between McPolice and PoliceKing when dialing 9-1-1, both returned by LoST. (Obviously, you will only be connected to the dispatcher after leaving your credit card number at the prompt.)

Henning
(not completely serious)

More seriously, there seem to be three options:

(1) always prevent RFC 5222 from returning more than one answer, regardless of service (emergency or otherwise)
(2) one answer only, but only for sos
(3) leave such restriction to the local jurisdiction, depending on the state of mountain rescue competition and other factors

There seems to be no reason for option (1), but I wonder if there's a great advantage for (2) over (3)? (I can see the user interface interface - if you know, that you don't need to choose, you don't have to build in that functionality.)

Henning

---

From: Ted Hardie <[email-masked]>
Date: Fri, 18 Mar 2011 20:41:26 -0700

> According to some local politicians that have watched too many Ayn Rand movies, government services should be privatized. Thus, we'll soon get a choice between McPolice and PoliceKing when dialing…

This can happen, pretty easily, in situations on the border of
emergency--like calling for ambulance service to transport someone
between hospitals or to a hospital in a non-emergency situation.  I
suspect that it will only get easier in countries with private health
care.

> (3) leave such restriction to the local jurisdiction, depending on the state of mountain rescue competition and other factors
I personally think that the protocol answer is 3 and that the
jurisdictional answer should be "force it to be a single answer to
avoid choice in panic situations".  But if we make that policy
decision in the protocol, we're only likely to get in
trouble--especially if it is a special case in RFC 5222.

Just my two cents,

Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 19 Mar 2011 12:17:23 +0800

Perhaps some guidance text in phonebcp would help people think about this a bit then?

Cheers
James

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ted Hardie [[email-masked]]
Sent: Friday, March 18, 2011 10:41 PM
To: Henning Schulzrinne
Cc: Rosen, Brian; Thomson, Martin; [email-masked]
Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp

Just my two cents,

Ted

---

From: "Rosen, Brian" <[email-masked]>
Date: Sat, 19 Mar 2011 09:03:02 -0400

> trouble--especially if it is a special case in RFC 5222.
That Works For Me

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 21 Mar 2011 06:47:48 +0800

On 2011-03-19 at 04:13:56, Rosen, Brian wrote:
> In general, I think this case only occurs due to a provisioning error 
> (overlap of service boundaries).  If it does, the LoST server is 
> probably better at figuring it out.

Not so.  I've been looking at the lost-extensions draft and that suggests a different case: where the input location has uncertainty that overlaps different boundaries.

--Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 21 Mar 2011 06:50:13 +0800

> route to a specific PSAP.

While I appreciate all the reasons for this decision, that's a practice that I'd like to see ended.  There are better criterion than serving cell.

> Generally, asking for user input during a call is frowned upon.

I agree.  Particularly if the question is exceptional.  If 90% of calls don't need human input, it's even worse when the exception occurs.  (Not that many people regularly make emergency calls.)

---

From: <[email-masked]>
Date: Sun, 20 Mar 2011 23:59:07 +0000

Hopefully I'm not missing the point as I've not followed the thread closely, but responding on comments below, end-users making emergency calls are usually asked to verbally give or confirm their location by UK PSAPs as standard procedure.  

For fixed single line callers this should just be confirmation of address automatically provided, but for multiline callers within enterprise/corporate networks or callers reporting incidents at another location, it could require more than just confirmation.  For  mobile callers it will be to pinpoint a location within the cell coverage areas automatically provided (and sadly no sign of more precise locations from our networks in near future).

Regards

John

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 21 Mar 2011 08:03:18 +0800

On 2011-03-21 at 10:59:07, [email-masked] wrote:
> Hopefully I'm not missing the point as I've not followed the thread 
> closely, but responding on comments below, end-users making emergency 
> calls are usually asked to verbally give or confirm their location by 
> UK PSAPs as standard procedure.
> 
> For fixed single line callers this should just be confirmation of 
> address automatically provided, but for multiline callers within 
> enterprise/corporate networks or callers reporting incidents at 
> another location, it could require more than just confirmation.  For  
> mobile callers it will be to pinpoint a location within the cell 
> coverage areas automatically provided (and sadly no sign of more 
> precise locations from our networks in near future).
> 
> Regards
> 
> John

Hi John,

I think that Ted's suggestion is the one we're going with: let the jurisdiction decide.

Those sorts of standard procedures are not the concern - though I'd like for that sort of questioning to be made redundant, it's entirely a policy decision for the jurisdiction.

--Martin