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
- Re: [Sipping-emergency] proposed charter, new wg … Tom Taylor
- Re: [Sipping-emergency] proposed charter, new wg … Henning Schulzrinne
- RE: [Sipping-emergency] proposed charter, new wg … Brian Rosen
- RE: [Sipping-emergency] proposed charter, new wg … James M. Polk
- RE: [Sipping-emergency] proposed charter, new wg … Brian Rosen
- RE: [Sipping-emergency] proposed charter, new wg … Marc Linsner
- RE: [Sipping-emergency] proposed charter, new wg … Marc Linsner
- RE: [Sipping-emergency] proposed charter, new wg … Brian Rosen
- RE: [Sipping-emergency] proposed charter, new wg … wilcox
- RE: [Sipping-emergency] proposed charter, new wg … Brian Rosen
- RE: [Sipping-emergency] proposed charter, new wg … Marc Linsner
- How to handle Validation failures was RE: [Sippin… Brian Rosen
- RE: [Sipping-emergency] proposed charter, new wg … wilcox
- RE: [Sipping-emergency] proposed charter, new wg … Brian Rosen