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

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

You put another NAPTR in the ECC entry in the DNS :)

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 3:45 PM
> To: Rosen, Brian
> Cc: 'Cullen Jennings'; [email-masked]
> Subject: Re: [Sipping] sos - dead or alive
> 
> 
> Unless this is identified in the mapping algorithm (location 
> -> ECC), I 
> don't see how a device can find the test destination.
> 
> Rosen, Brian wrote:
> 
> > If the SIP URI for a PSAP was 
> sip:[email-masked], and the
> > test
> > URI was sip:[email-masked], I don't think we have 
> any routing
> > problems.  The router for chicago.il.us would get exercised 
> for test code,
> > but not the proxy.
> > 
> > I like the scaling idea.
> > 
> > RTCP has never been tested with a billion phones randomly 
> trying anything.
> > I think we need to be careful. Very careful.
> 
> 
> _______________________________________________
> 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: Janet P Gunn <[email-masked]>
Date: Tue, 17 Feb 2004 14:24:52 -0500

Sounds good then.

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

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 <hgs         To:      Janet P Gunn <[email-masked]>                                           
                      @cs.columbia.edu         cc:      Cullen Jennings <[email-masked]>, [email-masked]                    
                      >                        Subject: Re: [Sipping] Re: sos - dead or alive                                   
                                                                                                                                
                      02/17/2004 02:14                                                                                          
                      PM                                                                                                        

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.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Feb 2004 09:29:08 -0500

I don't agree.  To be effective, you have to know you can get to a system 
that itself has certain knowledge that the call will reach an emergency 
call taker.  Since there is not necessarily any "carrier" involved, you 
have to get to a system that is run by the emergency response system in 
the jurisdiction that you are located.  It has to route (in the IP sense) 
the same as a real emergency call would route.  It doesn't have to get all 
the way to an operator, but it does have to get close.

If the result of the process (such as my suggestion in 
draft-rosen-dns-sos-00) to obtain the URL of the ECC serving the location 
of the caller is sip:[email-masked], then test 
calls might go to sip:[email-masked].  That may be 
a different host, but it would share the same router and route that a real 
emergency call would.

It could be that a jurisdiction above the ERC runs a network that handles
all emergency calls within its jurisdictions, and test calls could terminate
there.  For example, the State of Vermont could have all calls within
Vermont have a test service at sip:[email-masked], as long as it also
had all the emergency calls going to, for example,
sip:[email-masked].
That might be a proxy server that did more fine grained routing based on
location to the actual ERC that served the caller.  For example, it might
rewrite the Request-URI to sip:[email-masked] and route
the call over its network to the ERC in the city of Burlington.

Brian
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 19, 2004 9:03 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] Re: sos - dead or alive

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 20 Feb 2004 10:00:26 -0500

I think Hennings idea is the gem of the answer.

Assume that there are a couple of proxies between you and the ERC.

If the proxy closest to the ERC assures itself that it can reach the ERC,
then it can assure any proxy that routes through it to the ERC that it
can reach the ERC without the second level proxy having to actually touch
the ERC itself.  Repeat as necessary.  That scales better than having
each UA doing something that results in messages hitting the ERC itself.

There is no explicit mechanism in SIP to do this.
  It could be a Notify against some kind of event package we define
  It could be a kind of presence subscription
  It could be a kind of INVITE that returns a new error code
  It could be a new method that returns a new response code

When considering what the best mechanism is, remember that you have
a URI of the ERC, but you don't have a URI to an intermediate proxy.
We could figure out how to get you one.

The question you are asking is "If I sent a (real) INVITE to this
URI, would it get there?"  If you are subscribing to something, how do 
you know what to subscribe to?

Brian

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Friday, February 20, 2004 9:42 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> At 09:03 AM 2/19/2004 -0500, [email-masked] wrote:
> >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.
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 20 Feb 2004 14:11:25 -0500

Depending on how we end up implementing routing to the
correct ERC, the service boundary information will be available
to either the UA or a proxy.  When the mobile device roams
beyond the boundary, it could trigger a new test.

Agree that it would up the load.  Not clear that it will make
a tremendous increase, especially if Henning's idea prevails.

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, February 20, 2004 2:04 PM
> To: Michael Hammer
> Cc: Henning Schulzrinne; [email-masked]; [email-masked];
> [email-masked]
> 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:
> > 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:
> > 
> >> 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:
> >>
> >>>>> So any kind of regular, scheduled test should be 
> designed so it does
> >>>>> NOT
> >>>>> tie up the operators.
> >>>>
> >>>>
> >>>>
> >>>> emergency center or any of the equipment directly supporting the 
> >>>> emergency center at all.
> >>>>
> >>>> Mike
> >>>
> >>>
> 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: Janet P Gunn <[email-masked]>
Date: Fri, 20 Feb 2004 11:20:31 -0500

From a different perspective-  and this is a US centric comment but the
principle is applicable worldwide.

In the US, the Government "mandated" E-911  (911 with location info for
mobile phones, among other things) by imposing requirements on the
manufacturers of the switching equipment, and on the service providers.
However, there was no mechanism to require the PSAPs to do anything with
the information, as there was no direct jurisdiction.

As a result, the vast majority of the PSAPs simply "throw it on the floor".
They have no GIS, and no mechanism to DO anything with the location
information.  Furthermore , a large number of the PSAPs have no plans to do
anything with the location information.

Therefore, I would be VERY cautious about basing any solution  on the
expectation, that the PSAPs will make ANY additional investment that is not
required by law.

For instance, when I saw  "$2k per proxy, one proxy per  ECC", it threw up
a red flag for me.

Janet

                                                                                                                                 
                      Michael Hammer                                                                                             
                      <mhammer                 To:      Henning Schulzrinne <[email-masked]>                                
                      @cisco.com>              cc:      [email-masked], Janet P Gunn/FED/CSC@CSC, [email-masked]             
                                               Subject: Re: [Sipping] Re: sos - dead or alive                                    
                      02/20/2004 10:41                                                                                           
                      AM                                                                                                         

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