Subject: Re: [Sipping] Re: sos - dead or alive

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Feb 2004 14:14:58 -0500

The OPTIONS mechanism does exactly that - it's mechanical only.

Janet P Gunn wrote:

> Bear in mind that the "most scarce resource" in the emergency response
> system is usually the human operators.
> 
> So any kind of regular, scheduled test should be designed so it does  NOT
> tie up the operators.

_______________________________________________
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: Janet P Gunn <[email-masked]>
Date: Tue, 17 Feb 2004 14:09:48 -0500

Janet

----------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------

                      "Henning                                                                                                  
                      Schulzrinne"             To:      "Cullen Jennings" <[email-masked]>                                    
                      <hgs                     cc:      <[email-masked]>                                                      
                      @cs.columbia.edu         Subject: [Sipping] Re: sos - dead or alive                                       
                                                                                                                                
                      02/17/2004 11:18                                                                                          
                      AM                                                                                                        

> 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.

Gladly obliged.

>
> 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

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.

> 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.

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

> Cullen