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

Roger Marshall <RMarshall@seattle.telecomsys.com> Thu, 14 October 2004 00:43 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 UAA29203 for <sipping-emergency-web-archive@ietf.org>; Wed, 13 Oct 2004 20:43:29 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHttL-0004R2-4n for sipping-emergency-web-archive@ietf.org; Wed, 13 Oct 2004 20:54:54 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHtUi-0003Zr-4F; Wed, 13 Oct 2004 20:29:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHtO2-0001pj-QZ for sipping-emergency@megatron.ietf.org; Wed, 13 Oct 2004 20:22: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 UAA28058 for <sipping-emergency@ietf.org>; Wed, 13 Oct 2004 20:22:31 -0400 (EDT)
Received: from [206.173.41.176] (helo=sea-mailsweep-1.telecomsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHtZ4-00046m-Js for sipping-emergency@ietf.org; Wed, 13 Oct 2004 20:33:56 -0400
Received: from sea-exchange-1.xypoint.com (unverified [10.32.12.12]) by sea-mailsweep-1.telecomsys.com (Content Technologies SMTPRS 4.3.14) with ESMTP id <T6c9fb829c70a20001fc98@sea-mailsweep-1.telecomsys.com>; Wed, 13 Oct 2004 17:21:54 -0700
Received: by sea-exchange-1.telecomsys.com with Internet Mail Service (5.5.2656.59) id <4RC23PLN>; Wed, 13 Oct 2004 17:22:05 -0700
Message-ID: <8C837214C95C864C9F34F3635C2A6575C8376E@SEA-EXCHVS-2.telecomsys.com>
From: Roger Marshall <RMarshall@seattle.telecomsys.com>
To: "Peterson, Jon" <jon.peterson@neustar.biz>, sipping-emergency@ietf.org
Subject: RE: [Sipping-emergency] New revision of proposed ECRIT charter
Date: Wed, 13 Oct 2004 17:21:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
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: 287c806b254c6353fcb09ee0e53bbc5e

Jon:
Does the mention of NENA imply a formal relationship of approval by either
entity in any way, or rather an informal exchange of ideas and/or
information between the two?

Roger Marshall
TeleCommunication Systems, Inc.

-----Original Message-----
From: sipping-emergency-bounces@ietf.org
[mailto:sipping-emergency-bounces@ietf.org] On Behalf Of Peterson, Jon
Sent: Sunday, October 10, 2004 11:01 PM
To: sipping-emergency@ietf.org
Subject: [Sipping-emergency] New revision of proposed ECRIT charter


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