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

"Brian Rosen" <br@brianrosen.net> Mon, 27 September 2004 19:55 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 PAA26623 for <sipping-emergency-web-archive@ietf.org>; Mon, 27 Sep 2004 15:55:00 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1i4-0004mC-Py for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 16:02:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1Y1-0000ji-DW; Mon, 27 Sep 2004 15:52:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1Sa-0006zQ-DU for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 15:46:56 -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 PAA26070 for <sipping-emergency@ietf.org>; Mon, 27 Sep 2004 15:46:54 -0400 (EDT)
Message-Id: <200409271946.PAA26070@ietf.org>
Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC1aG-0004TT-Je for sipping-emergency@ietf.org; Mon, 27 Sep 2004 15:54:53 -0400
Received: from acs-24-154-127-195.zoominternet.net ([24.154.127.195] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.42) id 1CC1SU-0001yZ-8i; Mon, 27 Sep 2004 14:46:51 -0500
From: Brian Rosen <br@brianrosen.net>
To: wilcox@e911.psd.state.vt.us, 'Marc Linsner' <mlinsner@cisco.com>, sipping-emergency@ietf.org
Subject: RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing
Date: Mon, 27 Sep 2004 15:46:47 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcSkxXTmmCEkcjN4RAuSCNbECjVxvwAAMVUAAAC2ZOAAAF7kwA==
In-Reply-To: <B4D8D0C58294F54DA9DB6C6A9AEF38502A9718@artemis.vt911.local>
X-PopBeforeSMTPSenders: br@brianrosen.net,brosen
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
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: 0.8 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Content-Transfer-Encoding: 7bit

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