Subject: RE: [Ecrit] Issue 30: Summary

From: "Brian Rosen" <[email-masked]>
Date: Wed, 1 Feb 2006 07:27:06 -0500

I think incidence will be higher that you think, but I'll also agree that as
overlap dialing decreases, the problem decreases.

I can live with punting this problem for now; we don't really have the
expertise to decide, as long as we do standardize the mechanisms to learn
the home and visited emergency dialstrings.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Schulzrinne
Sent: Tuesday, January 31, 2006 8:59 PM
To: Stark, Barbara
Cc: [email-masked]
Subject: Re: [Ecrit] Issue 30: Summary

While this is an interesting debate, I think we need to recognize that 
we're worrying about a very small fraction of users, with a likely 
decrease to zero over time, namely:

- overlap dialing (i.e., ATA-style devices rather than mobile)
- roaming or using a foreign VSP
- likely to be residential rather than office (PBX) use; I just don't 
see that many businesses deploying a PBX with a foreign VSP (and those 
businesses are likely to hand-tune their dial plan in any event)

I think the most common use of foreign dial plans will be *inbound* 
calls, e.g., from relatives and friends in the old home country.

Since this is indeed a rare case, we need to make sure it works 
correctly, precisely because visitors, babysitters and the like will 
have no clue, like Brian noted. However, it is probably less important 
that these rare emergency calls are delayed by a few seconds. The 
time-out delay noted seems well within the standard answer delay budget 
of most PSAPs.

On the other hand, given that the owner of the phone is likely to be 
aware of the special status of the foreign dial plan, I don't see much 
of a practical problem if he has to dial #9112345 for the rare cases of 
collision with a local number. Yes, there might be a mistake made and an 
accidental 911 call placed, but the number of such arrangements will be 
so small, that it is unlikely to matter.

Given that there is no perfect solution, I don't think we need to make a 
decision on this now; operational experience can dictate whether 911T 
(timeout) or 911. (immediate) is the right dial plan (or maybe even 
911C, where C stands for confirmation). We just need to design discovery 
protocols that allow for both options. By the time this stuff gets 
widely deployed, this may be about as relevant as rotary dials.

Stark, Barbara wrote:
> This seems generally reasonable to me, also.
> However, there is an implicit expectation in the description below that 
> I'm not quite comfortable with, in the "precedence" statement. That is, 
> whether or not end of dialing string is automatically recognized for 
> visited emergency numbers.
> 
> For devices that use a "Send" button, this isn't a problem. "Send" must 
> always be pressed to indicate "end of dialing". For these, there would 
> be no clash between a US "911" and UK "911xxx" dial string. If the user 
> enters "911xxx" + "Send", then this must never be interpreted as "911". 
> Similarly, "911" + "Send" is equally unambiguous (in this example).
> 
> SIP devices without a "Send" button generally employ a variety of 
> mechanisms to recognize "end of dialing".
>  1. Some strings are automatically recognized; for example, when a user 
> dials any "N11" string and has an ATA configured for US dialing plans, 
> the ATA recognizes this string and automatically sends the SIP Invite 
> without waiting any further.
> 
>  2. The user can usually press "#" to indicate end of dialing. Many 
> users are unaware of this fact.
>  3. If the user does not press another digit in 4 or 5 seconds (differs 
> by device), this is interpreted as end of dialing, and the SIP Invite is 
> sent.
> 
> What this means, is that, if a user enters a string that is not 
> automatically recognized as being "complete", and the user doesn't press 
> "#", there will be a 4 or 5 second delay between the time when the last 
> digit is pressed and SIP signaling begins.
> 
> While I realize that this delay is generally undesirable, I would prefer 
> that there be no requirement to automatically recognize "end of dialing" 
> for visited emergency strings.
> 
> The flip side of this is that if the ATA's current dialing plan has an 
> automatically escaped string that is shorter than the visited emergency 
> number (e.g., an ATA might automatically recognize "00" as a complete 
> string, and the visited emergency number is "000"), then the ATA logic 
> needs to stop recognizing "00" as a complete string. I'm fine with this. 
> The user can then dial "00" (+ timeout) or "00#", and also "000" (+ 
> timeout) or "000#".
> 
> If done this way, the only clashes would be for exact matches.
> Barbara
> ========================================
> On Jan 28, 2006, at 12:25 PM, Stastny Richard wrote:
> 
>       1. By default, the device is set to use the home dialplan
>       and home emergency numbers, either directly or via
>       the home provider.
>       2. If not at home, the device get its location and also
>       the visited emergency numbers via some means
>       3. The visited emergency numbers take precendence
>       over the home dialling plan, if a clash occurs.
>       (Note: your home provider may provide you with an
>       escape code to override this, but then you definitely know
>       what you are doing - e.g. to reach 911xxx local numbers in UK
>       if you happen to be in the US.)
>       Note: this may cause some emergency calls done wrong,
>       but this is preferrable to missroute some real emergency calls
> 
> *****
> 
> 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. 117
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit

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

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