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