RE: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency

wilcox@e911.psd.state.vt.us Tue, 28 September 2004 13:14 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20667 for <sipping-emergency-web-archive@ietf.org>; Tue, 28 Sep 2004 09:14:28 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHwB-000148-Rt for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 09:22:36 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCHi8-0007PK-J5; Tue, 28 Sep 2004 09:08:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCHeP-0003yr-1j for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 09:04:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19706 for <sipping-emergency@ietf.org>; Tue, 28 Sep 2004 09:04:11 -0400 (EDT)
From: wilcox@e911.psd.state.vt.us
Received: from dpvc-64-222-94-65.burl.east.verizon.net ([64.222.94.65] helo=e911.psd.state.vt.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHmD-0000lw-OQ for sipping-emergency@ietf.org; Tue, 28 Sep 2004 09:12:19 -0400
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Tue, 28 Sep 2004 09:06:03 -0400
Message-ID: <B4D8D0C58294F54DA9DB6C6A9AEF38502A9721@artemis.vt911.local>
Thread-Topic: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency
thread-index: AcSlV0rpDu1XqMjjTSeVb3PvgHagtAAA2VvU
To: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: sipping-emergency@ietf.org
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: sipping-emergency.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0148856734=="
Sender: sipping-emergency-bounces@ietf.org
Errors-To: sipping-emergency-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976

I agree with non-interfering testing end to end.

 

Ultimately, routing of a call does not stop at an ECC. For all practical purposes it also derives a means for determining the correct response, which is part of the message relay (incorporating emergency responders in the chain). Validation of location information also ensures that the correct response recommendation is assigned. Take for example two locations that reside side-by-side, one is a residence and the other is a nuclear power plant. For the residence, a standard response for fire apparatus is fine however, for the nuclear power plant an entirely different response scenario may be necessary (perhaps the fire department located at the facility itself). If the call is routed to the ECC responsible for that location without validation of that location information (and ultimately validation of responder information), there will be no indication that a different response is necessary and correct routing of the call has not been accomplished. Currently, this is accomplished in the US 9-1-1 system by assigning a special zone (ESZ) to that location and assigning an indicator (ESN) to that location that derives the correct police, fire and EMS response. 

 

To give you a real world example: Ford Motor Company just selected to replace all of their traditional phone systems with VoIP service (50,000+ end devices). You can bet that in some of the larger plants, they have their own responders for Police, Fire and EMS services.

 

Nate 
 
-----Original Message----- 
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] 
Sent: Tue 9/28/2004 8:29 AM 
To: wilcox@e911.psd.state.vt.us 
Cc: Peterson, Jon; sipping-emergency@ietf.org 
Subject: Re: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency



	This can be seen as a special case of testing. Thus, if you assume that
	there is a test mode that attempts to reach the PSAP, but does not
	actually ring, you'd have tested the full routing chain, including
	whether the civic address is indeed mappable.
	
	A separate question is whether a separate address-only validation mode
	is appropriate. This probably depends on the overall architecture. As
	we've discussed before, I think there is general agreement that you'd
	want the ability for end-to-end non-interfering testing in any event.
	
	wilcox@e911.psd.state.vt.us wrote:
	> Validating location information is implicit for routing. Otherwise,
	> all calls would be treated as "default" routed or worse, would rely
	> on other mechanisms to provide routing instructions outside the
	> control of the ECC (the ECC currently provides instructions and input
	> on the construct of the MSAG to the extent possible, which is used
	> for the validation process). Unvalidated location information could
	> reduce or even prevent a timely emergency response to a particular
	> location. As I implied before, the lack of validation should not
	> prevent delivery of a call to a geographically appropriate ECC
	> however, all efforts need to be made to ensure that end devices
	> utilize validated location information. So, if the charter of this
	> effort is to decide on how routing is accomplished than validation of
	> the information used to make that routing decision should be
	> considered in the process as well.
	>
	> Nate
	
	
	

_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency