[Sipping-emergency] New revision of proposed ECRIT charter
"Peterson, Jon" <jon.peterson@neustar.biz> Mon, 11 October 2004 06:03 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 CAA22431 for <sipping-emergency-web-archive@ietf.org>; Mon, 11 Oct 2004 02:03:36 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGtRz-00086x-Ei for sipping-emergency-web-archive@ietf.org; Mon, 11 Oct 2004 02:14:27 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGtG0-0007oF-GY; Mon, 11 Oct 2004 02:02:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGtFO-0007Tc-Ck for sipping-emergency@megatron.ietf.org; Mon, 11 Oct 2004 02:01:26 -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 CAA20040 for <sipping-emergency@ietf.org>; Mon, 11 Oct 2004 02:01:25 -0400 (EDT)
Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGtPr-00084m-Lm for sipping-emergency@ietf.org; Mon, 11 Oct 2004 02:12:15 -0400
Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i9B60sPm010547 for <sipping-emergency@ietf.org>; Mon, 11 Oct 2004 06:00:55 GMT
Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id <T32L38M8>; Mon, 11 Oct 2004 02:00:54 -0400
Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF423D@stntexch04.cis.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: sipping-emergency@ietf.org
Date: Mon, 11 Oct 2004 02:00:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="ISO-8859-1"
X-Spam-Score: 0.8 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Subject: [Sipping-emergency] New revision of proposed ECRIT charter
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: a8a20a483a84f747e56475e290ee868e
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] New revision of proposed ECRI… Peterson, Jon
- RE: [Sipping-emergency] New revision of proposed … Brian Rosen
- RE: [Sipping-emergency] New revision of proposed … Marc Linsner
- Re: [Sipping-emergency] New revision of proposed … Henning Schulzrinne
- RE: [Sipping-emergency] New revision of proposed … wilcox
- Re: [Sipping-emergency] New revision of proposed … Jonathan Rosenberg
- Re: [Sipping-emergency] New revision of proposed … Tom Taylor
- RE: [Sipping-emergency] New revision of proposed … Roger Marshall
- RE: [Sipping-emergency] New revision of proposed … Peterson, Jon
- RE: [Sipping-emergency] New revision of proposed … Roger Marshall
- RE: [Sipping-emergency] New revision of proposed … Abbott, Nadine B.
- RE: [Sipping-emergency] New revision of proposed … James M. Polk
- RE: [Sipping-emergency] New revision of proposed … Tschofenig Hannes
- RE: [Sipping-emergency] New revision of proposed … James M. Polk
- Re: [Sipping-emergency] New revision of proposed … Henning Schulzrinne
- RE: [Sipping-emergency] New revision of proposed … Tschofenig Hannes
- Re: [Sipping-emergency] New revision of proposed … Henning Schulzrinne
- Re: [Sipping-emergency] New revision of proposed … James M. Polk
- Re: [Sipping-emergency] New revision of proposed … Henning Schulzrinne
- RE: [Sipping-emergency] New revision of proposed … Abbott, Nadine B.