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

From: [email-masked]
Date: Thu, 19 Feb 2004 09:03:29 EST

In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, [email-masked] 
writes:

> So any kind of regular, scheduled test should be designed so it does  NOT
> tie up the operators.
> 
I believe the test must be devised so that it does not involve the emergency 
center or any of the equipment directly supporting the emergency center at all.

Mike

---

From: Michael Hammer <[email-masked]>
Date: Fri, 20 Feb 2004 09:41:42 -0500

At 09:03 AM 2/19/2004 -0500, [email-masked] wrote:
>In a message dated 2/19/2004 1:58:18 AM Eastern Standard Time, 
>[email-masked] writes:
>
>
>I believe the test must be devised so that it does not involve the 
>emergency center or any of the equipment directly supporting the emergency 
>center at all.
>
>Mike

Then there is not much point in doing any test.  As Brian points out, the 
question is how do you stage these reachability tests so that they scale, 
ie. you don't have millions of users pinging the ECC directly.  But, 
instead of the proxies pinging the ECC, which might reduce the load, but 
might not make the burstiness more deterministic, perhaps a presence 
subscription would be more appropriate.  The proxies could subscribe to the 
presence of the ECC, and the ECC could periodically Notify those proxies 
that it is still there and able to receive calls.  The ECC could then 
control the scheduling and load distribution for sending the 
Notifies.  Failing to receive the notifications beyond some interval could 
provide an indication that something is wrong and trigger an inquiry.  You 
might even be able to extend this to the users, where emergency help is a 
"buddy" you subscribe to on the local proxy.  I haven't thought this 
through, but thought I'd throw that out.

Mike H.

_______________________________________________
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: Fri, 20 Feb 2004 10:00:26 -0500

I think there are five goals, somewhat contradictory:

(1) make it as realistic as possible, to make sure you are really 
testing the emergency calling system, not the testing system; after all, 
the fire safety officer doesn't go around ringing a cowbell instead of 
the real fire alarms.

(2) do not impose any additional operator involvement; this is solved by 
the OPTIONS mechanism proposed;

(3) allow for reasonable scaling;

(4) avoid interfering with real emergency calls

(5) allow user on-demand testing.

With the proxy-based testing I proposed, we get very close to all goals. 
In the worst case, i.e., every device does this once a day, we get 
roughly 100 million calls a day in the US, or 1157/second. That's about 
10 proxy servers worth of equipment, i.e., about $20k. This hardly seems 
worth spending inordinate engineering resources on avoiding, 
particularly since the likely load is going to be lower by probably a 
factor of 1000 or more (I'm assuming that most residential users will 
use a cable or DSL provider for this, for example).

With even a few hundred systems, you'll get almost perfect smoothing and 
very little burstiness.

I know protocol design is fun, but I'm very worried about adding 
complexity to solve largely a non-problem.

Michael Hammer wrote:

>> emergency center or any of the equipment directly supporting the 
>> emergency center at all.
>>
>> Mike
> 
> 
> Then there is not much point in doing any test.  As Brian points out, 
> the question is how do you stage these reachability tests so that they 
> scale, ie. you don't have millions of users pinging the ECC directly.  
> But, instead of the proxies pinging the ECC, which might reduce the 
> load, but might not make the burstiness more deterministic, perhaps a 
> presence subscription would be more appropriate.  The proxies could 
> subscribe to the presence of the ECC, and the ECC could periodically 
> Notify those proxies that it is still there and able to receive calls.  
> The ECC could then control the scheduling and load distribution for 
> sending the Notifies.  Failing to receive the notifications beyond some 
> interval could provide an indication that something is wrong and trigger 
> an inquiry.  You might even be able to extend this to the users, where 
> emergency help is a "buddy" you subscribe to on the local proxy.  I 
> haven't thought this through, but thought I'd throw that out.
> 
> Mike H.

---

From: Michael Hammer <[email-masked]>
Date: Fri, 20 Feb 2004 10:41:45 -0500

Henning,

The reality of deployment would be that every ECC would have it's own 
proxy, so that would be more like 1000 x $2k = $2 million.  But, the 
corresponding distribution of load across those servers means it is even 
more of a non-problem at any given site.

One question:  A real successful test to a wrong ECC doesn't buy you 
much.  I hope that mobility is addressed in the solution as well.  Many of 
those 100 million phones are mobile, which might become SIP-based some time 
in the future.  so I would add a 6) "works with mobile terminals" to your 
list below.

Mike

At 10:00 AM 2/20/2004 -0500, Henning Schulzrinne wrote:
>(1) make it as realistic as possible, to make sure you are really testing 
>the emergency calling system, not the testing system; after all, the fire 
>safety officer doesn't go around ringing a cowbell instead of the real 
>fire alarms.
>
>In the worst case, i.e., every device does this once a day, we get roughly 
>100 million calls a day in the US, or 1157/second. That's about 10 proxy 
>servers worth of equipment, i.e., about $20k. This hardly seems worth 
>spending inordinate engineering resources on avoiding, particularly since 
>the likely load is going to be lower by probably a factor of 1000 or more 
>(I'm assuming that most residential users will use a cable or DSL provider 
>for this, for example).
>
>>ie. you don't have millions of users pinging the ECC directly.
>>But, instead of the proxies pinging the ECC, which might reduce the load, 
>>but might not make the burstiness more deterministic, perhaps a presence 
>>subscription would be more appropriate.  The proxies could subscribe to 
>>the presence of the ECC, and the ECC could periodically Notify those 
>>proxies that it is still there and able to receive calls.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Feb 2004 14:03:54 -0500

The mobile issue is interesting. I would think that a mobile phone might 
want to test connectivity every time it moved into a different 
geographical area, or every time it roamed to a cell under different 
administration. That could up the load considerably.

	Paul

Michael Hammer wrote:
> much.  I hope that mobility is addressed in the solution as well.  Many 
> of those 100 million phones are mobile, which might become SIP-based 
> some time in the future.  so I would add a 6) "works with mobile 
> terminals" to your list below.
> 
> Mike
> 
>> testing the emergency calling system, not the testing system; after 
>> all, the fire safety officer doesn't go around ringing a cowbell 
>> instead of the real fire alarms.
>>
>> (2) do not impose any additional operator involvement; this is solved 
>> by the OPTIONS mechanism proposed;
>>
>> With the proxy-based testing I proposed, we get very close to all 
>> goals. In the worst case, i.e., every device does this once a day, we 
>> get roughly 100 million calls a day in the US, or 1157/second. That's 
>> about 10 proxy servers worth of equipment, i.e., about $20k. This 
>> hardly seems worth spending inordinate engineering resources on 
>> avoiding, particularly since the likely load is going to be lower by 
>> probably a factor of 1000 or more (I'm assuming that most residential 
>> users will use a cable or DSL provider for this, for example).
>>
>> With even a few hundred systems, you'll get almost perfect smoothing 
>> and very little burstiness.
>>
>>> the question is how do you stage these reachability tests so that 
>>> they scale, ie. you don't have millions of users pinging the ECC 
>>> directly.
>>> sending the Notifies.  Failing to receive the notifications beyond 
>>> some interval could provide an indication that something is wrong and 
>>> trigger an inquiry.  You might even be able to extend this to the 
>>> users, where emergency help is a "buddy" you subscribe to on the 
>>> local proxy.  I haven't thought this through, but thought I'd throw 
>>> that out.
>>> Mike H.
>>
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Feb 2004 20:41:36 -0500

Clearly, this has to work with mobile terminals. However, the mobility 
indication leads me to re-think the testing approach a bit and consider 
a more modular solution:

(1) Make sure that a device has recent location information;

(2) Make sure that it can look up a DNS record for that information or, 
ask its outbound proxy to do that (MaxForwards=1). There is no 
particular reason for everybody who resolves psap.ny.ny.gov to go and 
send it a SIP request - the result is likely the same.

(3) Have a testing application (e.g., run by some government agency or 
large providers) that walks the sos.arpa DNS tree and does sanity 
checks. For example, we might want to include in the OPTIONS response 
the area that a PSAP covers. If the DNS entry and the OPTIONS response 
differ on that, there's a problem that needs to be fixed - but that's 
probably best dealt with not by grandma or Vonage, but by an agency that 
knows whom to contact to fix such issues. (Such systematic tests could 
presumably also be used to gather availability statistics and discover 
routing problems.)

Having an end-to-end test doesn't really add much value beyond the 
component tests except for testing network reachability. However, 
network reachability changes fairly quickly, so the fact that I can or 
can't reach an IP address now doesn't say much as to whether I can reach 
it a few hours from now.

Doing a true end-to-end check is helpful for NATted devices, but then 
we'd also have to do an RTP echo test. Doing a NAT test isn't really 
necessary on a daily basis, as the configuration doesn't tend to change 
that often.

Thus, I think we should either use component testing or think of a more 
comprehensive test.

I think a manual 'test' function is useful in any event, probably with 
an RTP echo. (This could be done via INVITE with caller preferences 
indication of sos.test; the remote site would then 'pick up' and say 
'Your test call to the Hickstown emergency call center has been 
successful. If this is a real emergency, please hang up and dial 911 - 
and please remember to change your smoke detector batteries.')

Henning

Paul Kyzivat wrote:

>> corresponding distribution of load across those servers means it is 
>> even more of a non-problem at any given site.
>>
>> much.  I hope that mobility is addressed in the solution as well.  
>> Many of those 100 million phones are mobile, which might become 
>> SIP-based some time in the future.  so I would add a 6) "works with 
>> mobile terminals" to your list below.
>>
>> Mike
>>
>>>> Then there is not much point in doing any test.  As Brian points 
>>>> out, the question is how do you stage these reachability tests so 
>>>> that they scale, ie. you don't have millions of users pinging the 
>>>> ECC directly.
>>>> load, but might not make the burstiness more deterministic, perhaps 
>>>> a presence subscription would be more appropriate.  The proxies 
>>>> could subscribe to the presence of the ECC, and the ECC could 
>>>> periodically Notify those proxies that it is still there and able to 
>>>> receive calls.
>>>> some interval could provide an indication that something is wrong 
>>>> and trigger an inquiry.  You might even be able to extend this to 
>>>> the users, where emergency help is a "buddy" you subscribe to on the

---

From: Tom Taylor <[email-masked]>
Date: Mon, 23 Feb 2004 15:17:50 -0500

This discussion is relevant to the case where the ECC is IP-reachable, but what 
about legacy ECCs reachable through gateways?  What happens when some node along 
the chain tries to run a reachability test in this case?  Bear in mind that only 
the gateway is likely to know that the call is going to the PSTN.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Feb 2004 17:15:11 -0500

If it's an OPTIONS and/or sos.test request, it will get to the last SIP 
hop, but no further. I don't think we can do more than that unless ISUP 
or Q.931 has a 'just testing' request.

Tom Taylor wrote:

> This discussion is relevant to the case where the ECC is IP-reachable, 
> but what about legacy ECCs reachable through gateways?  What happens 
> when some node along the chain tries to run a reachability test in this 
> case?  Bear in mind that only the gateway is likely to know that the 
> call is going to the PSTN.