Subject: Re: [Sipping] Other concerns within sos ID

From: [email-masked]
Date: Thu, 12 Feb 2004 15:52:01 EST

In a message dated 2/11/2004 2:18:51 PM Eastern Standard Time, 
[email-masked] writes:

In general, I think the correct long-term user interface solution is to 
have a hotkey or address book entry *with user confirmation* rather than 
having users trying to remember digit strings. The digit string model 
currently works rather badly for the PSTN - do you know, without looking 
at the hotel phone card insert, whether you need to dial 9-911, 0, 911, 
0-911 or some other combination to get emergency help in a US hotel, let 
alone in some hotel in a foreign country?

[MAP] The digit string model works badly only when there is a lack of 
standardization. The solution is to push for standards, which has been happening in 
the US for many years. I suspect that "9" is prettty much "standard" in the US 
to get an outside line from a PBX, and "911" is pretty much "standard" in the 
US, so 9-911 almost always works. (I believe some jurisdictions have mandated 
this operation.) It's easy for a PBX to also interpret 911 itself as meaning 
the same thing, since no outside number begins with "11" in the US as far as I 
know, and the PBX can't have an internal number of "911" if "9" gets an 
external line. I don't know if any PBXs do this. (I'm not going to try!)

The solution to lack of full standardization is not to create yet another 
system, and I think the emergency industry (and US regulators) would have a 
problem with this.

If the user's terminal has a hotkey for emergency, what possibilities are 
there for a "user confirmation"? A voice message that says: "If you really meant 
it, push the button again harder"? Or if you click on an icon, a confirmation 
window pops up asking if you really meant it? I really can't see any 
"confirmation" procedure as being better than simply dialing the 3-digit emergency code 
(or "9" plus the 3-digits) that the government has spent millions 
publicizing. Any such "confirmation" procedure would have serious accessibility issues 
(for blind, deaf, illiterate, etc.)

I don't think that a hotkey or address book entry, even with a "user 
confirmation", is the correct long-term user interface solution. "Remembering" digit 
strings for an emergency is not a problem that needs solving.

On the other hand, if foreign travellers in the US not knowing our emergency 
number were really a problem, then it should be solved (in the US) by pushing 
for acceptance of 112, 118, 999 and maybe a few others as emergency numbers in 
our dial plan, even without SIP phones. This is not solely an IP phone or SIP 
issue.

Mike Pierce

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Feb 2004 16:06:24 -0500

> If the user's terminal has a hotkey for emergency, what possibilities 
> are there for a "user confirmation"? A voice message that says: "If you 
> really meant it, push the button again harder"? Or if you click on an 
> icon, a confirmation window pops up asking if you really meant it? I 
> really can't see any "confirmation" procedure as being better than 
> simply dialing the 3-digit emergency code (or "9" plus the 3-digits) 
> that the government has spent millions publicizing. Any such 
> "confirmation" procedure would have serious accessibility issues (for 
> blind, deaf, illiterate, etc.)

This is a UI issue, not for the IETF to solve. Confirmation dialogs, in 
many forms, are common. Indeed, there are many existing phones that have 
such buttons: Google randomly found 
http://www.allphones.us/shop/shopexd.asp?id=180
and
http://www.gogotech.com/flypage/1086/Ameriphone_Emergency_Response_Telephones
http://www.gogotech.com/flypage/1574/none/Ameriphone_JB-20

The confirmation problem seems to be primarily one for cell phones stuck 
in back pockets.

> confirmation", is the correct long-term user interface solution. 
> "Remembering" digit strings for an emergency is not a problem that needs 
> solving.

The discussion was not about replacing 911 in your home domain. There is 
no disagreement that this should be available. Quick, what's the 
emergency number for Korea?

> 
> On the other hand, if foreign travellers in the US not knowing our 
> emergency number were really a problem, then it should be solved (in the 
> US) by pushing for acceptance of 112, 118, 999 and maybe a few others as 
> emergency numbers in our dial plan, even without SIP phones. This is not 
> solely an IP phone or SIP issue.

The current technical solution seems much better and much more likely.

> Mike Pierce

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Feb 2004 07:58:16 -0800

I think that a phone informing a user that SOS was broken is very important
for this to work when it is needed. I would like to see a bit more text
around the current text of:

   It is RECOMMENDED that user agents
   periodically automatically check for the availability of the "sos"
   identifier and alert the user if the check fails.  The period of such
   automated checks SHOULDNOT be less than once per day and MUST be
   randomly placed over the testing interval.

Some random not well thought out ideas off the top of my head...

I would prefer MUST to RECOMMENDED since a recent informal poll at sipit
made it quiet clear that most implementers view SHOULD level requirements as
something to consider in the next lifetime. I'm not arguing that this poll
means we should not use SHOULD in general, but I think due to the critical
nature of this specification, we should be a little stronger than normal. I
don't want vendors saying they support this RFC fully when they can't detect
that a safety critical system is broken.

I would prefer specific test times - something like the test should be
performed at a random time between 12 and 36 hours. Phones must prominently
display the information that 911 is broken using a display or by changing
the dial tone on all calls. Would be nice to consider the impact of every
phone doing this. Phones SHOULD not do a test immediately after booting.
Phones MAY provide a UI to allow a user to manual imitate a test - this is
very useful for someone that is trying to check a 911 system but does not
want to wait 36 hours.

Cullen

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Feb 2004 11:18:32 -0500

> that a safety critical system is broken.

Gladly obliged.

> performed at a random time between 12 and 36 hours. Phones must prominently

Currently, there are about 200 million real 911 calls a year. Testing 
once per day would essentially impose this load once per day. While I 
don't think building proxies that can handle this is a bad idea (among 
other advantages, it provides ample margin of safety and load-resistance 
since real calls are then a tiny fraction of the test traffic), it does 
need to be considered.

 From local usage, I know that fire alarm bells at Columbia are tested 
weekly, so that may be a more reasonable schedule.

> very useful for someone that is trying to check a 911 system but does not

I like the gist of this and have added appropriate text.