OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: FYI: IETF WG Action: Emergency Context Resolution with Internet Technologies(ecrit)

Here is a proposed IETF Working Group that may be of interest to this 
community. Also, any individual can participate in an IETF WG. Simply need 
to sign up. No fees. All volunteer. I do not know the Chairs but I have 
worked with both Allison and Jon. They are very knowledgeable about 
"location" payloads and the internet.



----- Original Message ----- 
From: "The IESG" <iesg-secretary@ietf.org>
To: <IETF-Announce@ietf.org>
Cc: "Marc Linsner" <mlinsner@cisco.com>; <sipping-emergency@ietf.org>; 
"Hannes Tschofenig" <hannes.tschofenig@siemens.com>
Sent: Wednesday, February 09, 2005 1:43 PM
Subject: WG Action: Emergency Context Resolution with Internet 

>A new IETF working group has been formed in the Transport Area. For 
> information, please contact the Area Directors or the WG Chairs.
> +++
> Emergency Context Resolution with Internet Technologies (ecrit)
> ===============================================================
> Currect Status: Ctive Working Group
> Chair(s):
> Hannes Tschofenig <hannes.tschofenig@siemens.com>
> Marc Linsner <mlinsner@cisco.com>
> Transport Area Director(s):
> Allison Mankin <mankin@psg.com>
> Jon Peterson <jon.peterson@neustar.biz>
> Transport Area Advisor:
> Jon Peterson <jon.peterson@neustar.biz>
> Mailing Lists:
> General Discussion: sipping-emergency@ietf.org
> To Subscribe: https://www1.ietf.org/mailman//listinfo/sipping-emergency
> Archive: http://www.ietf.org/mail-archive/web/sipping-emergency/index.html
> Description of Working Group:
> 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 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 groups
> such as NENA and ETSI EMTEL, 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 independent.
> This working group cares about privacy and security concerns, and will
> address them within its documents.
> Goals and Milestones:
> Apr 2005  Informational RFC containing terminology definitions and the 
> requirements.
> May 2005  An Informational document describing the threats and security
> considerations.
> Aug 2005  A BCP describing how to identify a session set-up request is to 
> an emergency
> response center.
> Aug 2005  A BCP describing strategies for associating session originators 
> with
> physical locations.
> Aug 2005  A BCP or Standards Track RFC describing how to route an 
> emergency call
> based on location information.
> Nov 2005  A BCP describing how to discover the media stream types an ERC 
> supports.
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf-announce

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]