RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing

wilcox@e911.psd.state.vt.us Mon, 27 September 2004 21:33 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 RAA11197 for <sipping-emergency-web-archive@ietf.org>; Mon, 27 Sep 2004 17:33:21 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3FI-0000yY-D0 for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 17:41:21 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC2sS-0002z3-TX; Mon, 27 Sep 2004 17:17:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1vt-0004qz-BX for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 16:17:14 -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 QAA28054 for <sipping-emergency@ietf.org>; Mon, 27 Sep 2004 16:17:10 -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 1CC23Z-0005CS-R9 for sipping-emergency@ietf.org; Mon, 27 Sep 2004 16:25:10 -0400
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Mon, 27 Sep 2004 16:19:05 -0400
Message-ID: <B4D8D0C58294F54DA9DB6C6A9AEF38502A971B@artemis.vt911.local>
Thread-Topic: [Sipping-emergency] proposed charter, new wg on emergency calling and routing
thread-index: AcSkxXTmmCEkcjN4RAuSCNbECjVxvwAAMVUAAAC2ZOAAAF7kwAABIjcO
To: Brian Rosen <br@brianrosen.net>, Marc Linsner <mlinsner@cisco.com>, sipping-emergency@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
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="===============0226401041=="
Sender: sipping-emergency-bounces@ietf.org
Errors-To: sipping-emergency-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f

IAP - Infrastructure Access Provider - whomever is aware of a) the physical location of the end user and b) provides Internet access to the end user.
 
Your second question introduces the notion of default call routing - this is important to consider as well, not onlyfor  this reason but also  for other process failures that may occur. How this information gets to the end device - whether it is pre-determined and statically entered or, assigned at a lower level than the IAP  - I don't know - maybe both? 
 
Nate Wilcox

	-----Original Message----- 
	From: Brian Rosen [mailto:br@brianrosen.net] 
	Sent: Mon 9/27/2004 3:46 PM 
	To: wilcox@e911.psd.state.vt.us; 'Marc Linsner'; sipping-emergency@ietf.org 
	Cc: 
	Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency calling and routing
	
	

	What's an IAP?
	
	Agree, you send the call, validated or not.
	
	Of course if the validation fails, where do you send the call?
	
	Brian
	
	> -----Original Message-----
	> From: wilcox@e911.psd.state.vt.us [mailto:wilcox@e911.psd.state.vt.us]
	> Sent: Monday, September 27, 2004 3:45 PM
	> To: Brian Rosen; Marc Linsner; sipping-emergency@ietf.org
	> Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency
	> calling and routing
	>
	> While validation is important as described by both of you, this should in
	> no way intefere with the processing of a call to an ERC. Feedback should
	> be provided to the end user or IAP if the location information  is out of
	> acceptable parameters (e.g. out of street range, wrong spelling etc.) and
	> also provided to an ERC or ERC service provider as a method to ensure that
	> the erroneous information is corrected BEFORE an emergency call is ever
	> placed. However, the ability for that particular device to place an
	> emergency call should not be restricted by this process (didn't see it
	> anywhere in the proposal but I wanted to make sure that it is stated) -
	> this mirrors the current process of validation here in North America for
	> PSTN originated calls.
	>
	> Nate Wilcox
	>
	> -----Original Message-----
	> From: Brian Rosen [mailto:br@brianrosen.net]
	> Sent: Monday, September 27, 2004 3:20 PM
	> To: 'Marc Linsner'; sipping-emergency@ietf.org
	> Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency
	> calling and routing
	>
	>
	> Agreed that you COULD change the way the system works now to have a
	> translation from postal address to dispatch address.  They don't do that
	> now, but they could.  In that regard, maybe a bad example.  If you were to
	> propose that the system have a translation, then some kind of spec would
	> have to be written that said that, which might be a new deliverable.
	>
	> Misspellings, missing or extra directionals (North, Southwest, ..),
	> confusion between Main Street and Main Drive, etc. are better examples.
	> The point is to make sure that the call will be routed correctly,
	> and responders will be dispatched correctly BEFORE the location is needed
	> to
	> do so, and the only way we know how to do that is to compare the address
	> against some kind of master list.
	>
	> Brian
	>
	> > -----Original Message-----
	> > From: Marc Linsner [mailto:mlinsner@cisco.com]
	> > Sent: Monday, September 27, 2004 3:09 PM
	> > To: 'Brian Rosen'; sipping-emergency@ietf.org
	> > Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency
	> > calling and routing
	> >
	> > In-line.....
	> >
	> > > -----Original Message-----
	> > > From: sipping-emergency-bounces@ietf.org
	> > > [mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Brian Rosen
	> > > Sent: Monday, September 27, 2004 12:04 PM
	> > > To: 'James M. Polk'; 'Peterson, Jon'; sipping-emergency@ietf.org
	> > > Cc: mankin@psg.com
	> > > Subject: RE: [Sipping-emergency] proposed charter,new wg on
	> > > emergency calling and routing
	> > > Importance: Low
	> > >
	> > >
	> > > When you place an emergency call, the location is used to
	> > > determine where to send the call, and it is used to dispatch
	> > > responders.  If the location you supply does not match
	> > > anything the call center recognizes, the wrong thing may
	> > > happen.  What you want to do is to compare the address you
	> > > have against a list maintained by the emergency response
	> > > system to make sure they know where that is.
	> > >
	> > > An example is illustrative.  If you ask me my home address,
	> > > I'd tell you that it is 470 Conrad Drive, Mars, PA.  However,
	> > > that is NOT the address that should be used to determine
	> > > where to send an emergency call from my home.  That is
	> > > because the post office boundary is not the same as the
	> > > emergency call system boundary.
	> >
	> > So?  As long as '470 Conrad Drive, Mars, PA.' is unique, modern data
	> > processing can handle it.
	> >
	> > If you were to determine the
	> > > serving ERC without validation, you would send my emergency
	> > > call to the Butler County ERC, which serves Mars, rather than
	> > > to the NEWCOM center that serves Pine Township, where I live.
	> >
	> > Validation and routing are 2 separate issues.  If in fact, 470
	> > Conrad.....,
	> > is a good address, the routing function (which will be based on data
	> from
	> > the ERC entities) better get it right and send the call the NEWCOM
	> center
	> > as
	> > you describe.  All that validation *may* offer is to verify that you
	> (the
	> > end-user) didn't spell Conrad as Conard (or put Street instead of Drive,
	> > etc.)!  I realize there are locales that utilize a different 'location'
	> > address for emergency purposes than the postal address, but the IETF
	> can't
	> > fix this.
	> >
	> > I'm not against validation, but your example isn't the real reason for
	> > validation.
	> >
	> > >
	> > [snip]
	> >
	> > -Marc Linsner-
	> >
	> >
	>
	>
	>
	>
	> _______________________________________________
	> Sipping-emergency mailing list
	> Sipping-emergency@ietf.org
	> https://www1.ietf.org/mailman/listinfo/sipping-emergency
	>
	>
	>
	
	
	
	
	_______________________________________________
	Sipping-emergency mailing list
	Sipping-emergency@ietf.org
	https://www1.ietf.org/mailman/listinfo/sipping-emergency
	
	
	

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