Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency call

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 14:49:23 +0300

ED-3 Endpoints SHOULD recognize dial strings of emergency calls.  If
   the service provider always knows the location of the device, then
   the service provider could recognize them.

   SP-2 Proxy servers SHOULD recognize emergency dial strings if for
   some reason the endpoint does not recognize them.  This cannot be
   relied upon by the device if the service provider cannot always
   determine the location of the device.

Looking at these 2 SHOULDs I can imagine cases where neither one of them
recognizes them.

Wouldn't it be better to have a MUST with the 2nd requirement? I would
delete the 2nd sentence since in that case it would be very difficult to
route the call and to find the right PSAP as well. 

Comparing with the following requirement I recognize a mismatch: 

   ED-19/INT-10/SP-13 Where proxies provide location on behalf of
   endpoints, the service provider MUST ensure that either the end
   device is provided with the local dial strings for its current
   location (where the end device recognizes dial strings), or the
   service provider proxy MUST detect the appropriate local dial strings
   at the time of the call. 

   ED-5/SP-4 Local dial strings MUST be recognized.

"MUST" be recognized by whom? See requirements above. 

   ED-6/SP-5 Devices MUST be able to be configured with the home country
   from which the home dial string(s) can be determined.

Shouldn't this read like 
"
Devices MUST be have mechanisms to learn the user's home emergency
numbers. 
"

   ED-9 Endpoints SHOULD be able to have home dial strings provisioned
   by configuration.

I guess ED-9 should say something like "Endpoints SHOULD be able to have
home dial strings dynamically provisioned."
To refer to the case that manual configuration may also be used in order
to meet the previous requirements. 

   ED-11/SP-9 All emergency services specified in [RFC5031] MUST be
   recognized.

Should say something like: 
"
All emergency services URNs specified in .... MUST be recognized. 
"

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Oct 2008 08:50:37 -0400

The problem is that proxies don't have location, and therefore can't
recognize them in most cases.  Mobile systems with IMS, where the visited
network handles emergency calls would be an exception, but a wireline IMS
system which allowed nomading would not be able to recognize local emergency
dialstrings.  That is why SHOULD is appropriate.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Tuesday, October 14, 2008 7:49 AM
To: ECRIT
Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an emergency
call

Shouldn't this read like 
"

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 15:57:37 +0300

Hi Brian, 

I know this challenge. 

Still, you have to put a must in there to make sure that the call is
actually recognized. 

The architecture is very much build on the idea that either the end host
or the VSP (directly or indirectly) get location from somewhere. 
As we learned at the previous emergency services workshops there are
some sort of hacks one can do to bypass this need but they only work
when there is a relationship between the VSP and the ISP. Currently,
these things are being setup in individual countries and as such the
question of recognizing emergency service numbers is essentially solved.

Ciao
Hannes

>From: ext Brian Rosen [mailto:[email-masked]] 
>Sent: 14 October, 2008 15:51
>To: Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
>Subject: RE: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: 
>Identifying an emergency call
>
>The problem is that proxies don't have location, and therefore 
>can't recognize them in most cases.  Mobile systems with IMS, 
>where the visited network handles emergency calls would be an 
>exception, but a wireline IMS system which allowed nomading 
>would not be able to recognize local emergency dialstrings.  
>That is why SHOULD is appropriate.
>
>Brian
>
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
>Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying 
>an emergency call
>
>
>Looking at these 2 SHOULDs I can imagine cases where neither 
>one of them recognizes them.
>
>Wouldn't it be better to have a MUST with the 2nd requirement? 
>I would delete the 2nd sentence since in that case it would be 
>very difficult to route the call and to find the right PSAP as well. 
>
>Devices MUST be have mechanisms to learn the user's home 
>emergency numbers. 
>"
>
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Oct 2008 09:06:48 -0400

Hannes

If it's not possible in most circumstances to have proxies recognize
emergency dial strings, then it's not possible to make it a requirement that
they do so.

The fact is that the endpoint must do it.  That is the actual requirement.
The proxy text is a backstop; it's not required, it's not usually even
possible, but it's nice to have.  
If anything, you could be arguing we should delete the proxy requirement, or
at least reword it to cover the case of a guarantee that the visited network
handles emergency calls. In fact, since most emergency calls are made from
visited networks where the local emergency dial strings are the same as home
dial strings, it will actually work most of the time in most networks.
That's my argument for keeping it.

Ergo, SHOULD

Brian

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]]

Sent: Tuesday, October 14, 2008 8:58 AM
To: ext Brian Rosen; ECRIT
Subject: RE: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an
emergency call

Hi Brian, 

I know this challenge. 

Ciao
Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 14 Oct 2008 11:35:23 -0400

In general, we SHOULD always qualify the SHOULD with the condition of  
when the obligation cannot be met. ED-3 kind of does this, but the  
causal connection is not obvious. Thus, we want something

"If a proxy knows the caller's location, it MUST recognize the local  
emergency dial string. If not, ?"

We need to then decide whether the ? should be

- proxy can guess at the location and recognize based on a guess
- recognize certain numbers always (e.g., those numbers where most of  
its customers reside)
- never recognize anything

(and it could be all of the above).

This provides much more useful guidance to implementors than a SHOULD.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Oct 2008 11:41:40 -0400

Yes, you are correct.

I'd suggest a) and b) in your list.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, October 14, 2008 11:35 AM
To: Brian Rosen
Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an
emergency call

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 14 Oct 2008 11:53:04 -0400

(a) and (b) can probably be combined into one case, as they  
essentially involve guessing. Something like

---

If a proxy can reasonably guess the location of the caller, it MAY use  
that location to recognize applicable emergency numbers. For example,  
a proxy may base this estimate on the fact that most of the VSPs  
customers reside in a small set of countries.

---

(Since we can't dictate what reasonable is, anything stronger than a  
MAY doesn't really help.)

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Oct 2008 12:05:57 -0400

Works for me

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, October 14, 2008 11:53 AM
To: Brian Rosen
Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an
emergency call

---

---

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 14 Oct 2008 13:56:12 -0400

So long as we understand and accept that the most likely form of
"guessing" will be to simply recognize the "home" emergency dial strings
associated with that caller. Which is what we have today, so it isn't a
problem. Feel free to say "MUST", for that, if you like. I think the
comment about "a small set of countries" could be misinterpreted. If
those countries all use different dial strings, the VSP is likely not to
try to recognize all strings from all of the countries, but to only
recognize the strings of the country that caller is associated with
(billing location, or perhaps even a static emergency location).
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Tuesday, October 14, 2008 12:06 PM
To: 'Henning Schulzrinne'
Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying
anemergency call

Works for me

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, October 14, 2008 11:53 AM
To: Brian Rosen
Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an
emergency call

---

---

*****

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: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Oct 2008 21:04:02 +0300

Hi Brian, 

>Hannes
>
>If it's not possible in most circumstances to have proxies 
>recognize emergency dial strings, then it's not possible to 
>make it a requirement that they do so.
>

Quoting the document: 

>The proxy text is a backstop; it's not required, it's not 
>usually even possible, but it's nice to have.  
>If anything, you could be arguing we should delete the proxy 
>requirement, or at least reword it to cover the case of a 
>guarantee that the visited network handles emergency calls. In 
>fact, since most emergency calls are made from visited 
>networks where the local emergency dial strings are the same 
>as home dial strings, it will actually work most of the time 
>in most networks.

Henning already made a suggestion for text and I will take a look at
that one to see how it works out. 

Ciao
Hannes

>Still, you have to put a must in there to make sure that the 
>call is actually recognized. 
>
>The architecture is very much build on the idea that either 
>the end host or the VSP (directly or indirectly) get location 
>from somewhere. 
>As we learned at the previous emergency services workshops 
>there are some sort of hacks one can do to bypass this need 
>but they only work when there is a relationship between the 
>VSP and the ISP. Currently, these things are being setup in 
>individual countries and as such the question of recognizing 
>emergency service numbers is essentially solved.
>
>
>Ciao
>Hannes
>
>>recognize them in most cases.  Mobile systems with IMS, where the 
>>visited network handles emergency calls would be an exception, but a 
>>wireline IMS system which allowed nomading would not be able to 
>>recognize local emergency dialstrings.
>>Subject: [Ecrit] draft-ietf-ecrit-phonebcp-05.txt: Identifying an 
>>emergency call
>>
>>
>>Looking at these 2 SHOULDs I can imagine cases where neither one of 
>>them recognizes them.
>>
>>I would delete the 2nd sentence since in that case it would be very 
>>difficult to route the call and to find the right PSAP as well.
>>
>>I guess ED-9 should say something like "Endpoints SHOULD be able to 
>>have home dial strings dynamically provisioned."
>>To refer to the case that manual configuration may also be used in 
>>order to meet the previous requirements.
>>
>>