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

"Marc Linsner" <mlinsner@cisco.com> Mon, 27 September 2004 20:27 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 QAA29347 for <sipping-emergency-web-archive@ietf.org>; Mon, 27 Sep 2004 16:27:14 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC2DI-0005ek-9v for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 16:35:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1lf-0007A3-GJ for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 16:06:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1hl-00050D-QD for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 16:02:37 -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 QAA26947 for <sipping-emergency@ietf.org>; Mon, 27 Sep 2004 16:02:35 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1pQ-0004sE-T7 for sipping-emergency@ietf.org; Mon, 27 Sep 2004 16:10:34 -0400
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 27 Sep 2004 13:05:21 -0700
Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i8RK0dxQ023287; Mon, 27 Sep 2004 13:02:03 -0700 (PDT)
Received: from mlinsnerzk7abh (ssh-sjc-1.cisco.com [171.68.225.134]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA03008; Mon, 27 Sep 2004 12:52:10 -0700 (PDT)
From: Marc Linsner <mlinsner@cisco.com>
To: 'Brian Rosen' <br@brianrosen.net>, sipping-emergency@ietf.org
Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing
Date: Mon, 27 Sep 2004 15:52:08 -0400
Message-ID: <010601c4a4cb$79ec1d50$2c0d0d0a@mlinsnerzk7abh>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <200409271923.i8RJMNJ8028657@sj-inbound-4.cisco.com>
X-Spam-Score: 2.3 (++)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Content-Transfer-Encoding: 7bit
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>
Sender: sipping-emergency-bounces@ietf.org
Errors-To: sipping-emergency-bounces@ietf.org
X-Spam-Score: 2.3 (++)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Content-Transfer-Encoding: 7bit

A point I tried to make wrt your example was to say that even current MSAG
architectures allow jurisdictional lines to split streets in many different
configurations without requiring exotic things to happen (like ERC overlay
naming, etc.).

In VoIP, pre-validation of civil location prevents call routing failures.
Yes, for this reason, validation is a good thing.  I also would submit that
if the VoIP call got routed to an ERC, then it's most likely dispatchable
(so we may be able to quit using that argument).  I would purpose to the
user(s), that in areas where ERC jurisdictional lines are grossly different
from civil address lines, then loose routing based solely on city/town
would/should not be implemented.  VoIP makes it almost impossible to
'default route' due to VPN tunnels, etc. as compared to legacy mechanisms.

-Marc-

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