RE: [Sipping-emergency] proposed charter, new wg on emergency calling and routing
"Brian Rosen" <br@brianrosen.net> 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 RAA11295 for <sipping-emergency-web-archive@ietf.org>; Mon, 27 Sep 2004 17:33:53 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3Fp-000107-NP for sipping-emergency-web-archive@ietf.org; Mon, 27 Sep 2004 17:41:54 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC2tI-0003t9-7L; Mon, 27 Sep 2004 17:18:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC2Bt-0003Lk-V9 for sipping-emergency@megatron.ietf.org; Mon, 27 Sep 2004 16:33:46 -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 QAA00586 for <sipping-emergency@ietf.org>; Mon, 27 Sep 2004 16:33:43 -0400 (EDT)
Message-Id: <200409272033.QAA00586@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 1CC2Ja-00060t-8l for sipping-emergency@ietf.org; Mon, 27 Sep 2004 16:41:42 -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 1CC2Bo-0005fs-C1; Mon, 27 Sep 2004 15:33:40 -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 16:33:37 -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: AcSkxXTmmCEkcjN4RAuSCNbECjVxvwAAMVUAAAC2ZOAAAF7kwAABIjcOAAB6ODA=
In-Reply-To: <B4D8D0C58294F54DA9DB6C6A9AEF38502A971B@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: 7268a2980febc47a9fa732aba2b737ba
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: a3f7094ccc62748c06b21fcf44c073ee
Content-Transfer-Encoding: 7bit
Aha! I've been calling it an AIP=Access Infrastructure Provider, i.e. the service provider that has the "last mile" infrastructure and thus normally knows where you are. Brian > -----Original Message----- > From: wilcox@e911.psd.state.vt.us [mailto:wilcox@e911.psd.state.vt.us] > Sent: Monday, September 27, 2004 4:19 PM > To: Brian Rosen; Marc Linsner; sipping-emergency@ietf.org > Subject: RE: [Sipping-emergency] proposed charter,new wg on emergency > calling and routing > > 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
- 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