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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 17 Feb 2004 15:11:39 -0500

Probably need a separate URI for this; don't want to have even a 
possibility for overwhelming the real proxy server.  It would be easy
for the test one to heartbeat the real one to keep them in sync.

We could define a more precise algorithm based on lsbs of IP address to
randomize test times.

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 10:58 AM
> To: Henning Schulzrinne; [email-masked]
> Subject: [Sipping] sos - dead or alive
> 
> 
> 
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Feb 2004 15:27:32 -0500

> for the test one to heartbeat the real one to keep them in sync.

While you can obviously do method-based routing, I would worry about 
building any such knowledge into the UA. After all, you want to test as 
much of the whole chain as you can.

To improve scaling, an outbound proxy could answer all such OPTIONS 
requests to keep testing load local, depending on our perception of 
where the likely failures are. (The emergency-call-aware outbound proxy 
could then in turn exercise the path from itself to the ECCs of 
interest, but you'd then have one per company or provider, instead of 
10,000 tests per campus.)

> We could define a more precise algorithm based on lsbs of IP address to

I don't think that helps much beyond simple randomization. We have 
reasonably good experience with randomization in RTCP after all.