RE: [Sipping-emergency] New revision of proposed ECRIT charter

wilcox@e911.psd.state.vt.us Mon, 11 October 2004 18:44 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 OAA02127 for <sipping-emergency-web-archive@ietf.org>; Mon, 11 Oct 2004 14:44:20 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH5KI-00068b-J4 for sipping-emergency-web-archive@ietf.org; Mon, 11 Oct 2004 14:55:18 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH52D-0005AV-73; Mon, 11 Oct 2004 14:36:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4wI-0003qv-TA for sipping-emergency@megatron.ietf.org; Mon, 11 Oct 2004 14:30:30 -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 OAA00787 for <sipping-emergency@ietf.org>; Mon, 11 Oct 2004 14:30:29 -0400 (EDT)
From: wilcox@e911.psd.state.vt.us
Received: from [64.222.94.65] (helo=e911.psd.state.vt.us) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH56n-0005iR-Da for sipping-emergency@ietf.org; Mon, 11 Oct 2004 14:41:27 -0400
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Mon, 11 Oct 2004 14:30:55 -0400
Message-ID: <B4D8D0C58294F54DA9DB6C6A9AEF385037BC4E@artemis.vt911.local>
Thread-Topic: [Sipping-emergency] New revision of proposed ECRIT charter
thread-index: AcSvvHmaT9xA0UM3SWqoY0ErriZYLQAAwxLQ
To: "Peterson, Jon" <jon.peterson@neustar.biz>
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
Content-Transfer-Encoding: quoted-printable
Cc: sipping-emergency@ietf.org
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: 1.1 (+)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Content-Transfer-Encoding: quoted-printable

I agree with all the comments so far. 

Does the statement: "This group is considering emergency services calls which might be made by any user of the PSTN or Internet" imply that, to some degree, this group will also be considering how to route and/or protocols for PSTN originated emergency calls for the ERC as well?

Nate

Peterson, Jon wrote:
> All,
> 
> Here's a new version of the ECRIT charter for your consideration, that
> attempts to incorporate the discussion over the past couple of weeks.
> 
> Any further issues?
> 
> Jon Peterson
> NeuStar, Inc.
> 
> ---
> 
> Emergency Context  Resolution with Internet Technologies (ECRIT)
> 
> Transport Area Director(s):
> Allison Mankin <mankin@psg.com>
> Jon Peterson <jon.peterson@neustar.biz>
> 
> Transport Area Advisor: TBD
> 
> Working Group Chairs:  TBD
> 
> In a number of areas the public switched telephone network (PSTN)
> has been configured to recognize an explicitly specified number (commonly
> one that is short and easily memorized) as a call for emergency services.  
> These numbers (e.g. 911, 112) relate to an emergency service context and
> depend
> on a broad, regional configuration of service contact methods and a
> geographically
> constrained context of service delivery.  These calls are intended to be
> delivered to
> special call  centers equipped to manage emergency response. Successful
> delivery
> of an emergency service call within those systems requires both an
> association of
> the physical location of the originator with  an appropriate emergency
> service
> center and call routing to deliver the call to the center.
> 
> Calls placed using Internet technologies do not use the same systems to
> achieve those goals, and the common use of overlay networks and tunnels
> (either as VPNs or for mobility) makes meeting them more challenging.  There
> are, however, Internet technologies available to describe location and to
> manage call routing.  This working group will describe when these may be
> appropriate
> and how they may be used.   Explicitly outside the scope of this group
> is the question of pre-emption or prioritization of emergency services
> traffic. This group is considering emergency services calls which might be
> made by
> any user of the PSTN or Internet, as opposed to government or military
> services that may impose very different authentication  and routing
> requirements.
> 
> The group will show how the availability of location data and call routing
> information
> at different steps in  session setup would enable communication between a
> user
> and a relevant emergency response center. Though the term "call routing" is
> used in this
> document, it should be understood that some of the mechanisms which 
> will be described might be used to enable other types of media 
> streams. Video and text messaging, for example, might be used to request
> emergency services.
> 
> While this group anticipates a close working relationship with NENA, any
> solution
> presented must be useful regardless of jurisdiction, and it must be possible
> to
> use without a single, central authority.  Further, it must be possible for
> multiple
> delegations within a jurisdiction to be handled independently, as call
> routing
> for specific emergency types may be indepdent.
> 
> Deliverables:
> 
> Informational RFC containing terminology definitions and the requirements.
> 
> A BCP describing how to identify a session set-up request is to an emergency
> response center.
> 
> A BCP describing strategies for associating session originators with 
> physical locations.
> 
> A BCP or Standards Track RFC describing how to route an emergency call
> based on location information.  Either within that document or as a separate
> document, a description of how error conditions are returned to the session
> originator and how to test for error conditions without activating an
> emergency
> response.  Privacy concerns related to that testing must be addressed
> in this document set.
> 
> A BCP describing how to discover the media stream types an ERC supports.
> 
> An Informational document describing the threats and security
> considerations.
> 
> 
> _______________________________________________
> 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