[Sipping] Re: [Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 28 August 2007 07:33 UTC
Return-path: <sipping-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPva4-0007BN-Jy; Tue, 28 Aug 2007 03:33:44 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1IPva2-0007Ak-Fg for sipping-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 03:33:42 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvZy-00078U-2t; Tue, 28 Aug 2007 03:33:38 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPvZw-0008UK-Bj; Tue, 28 Aug 2007 03:33:37 -0400
Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1B9C210F1; Tue, 28 Aug 2007 09:33:35 +0200 (CEST)
X-AuditID: c1b4fb3e-b0835bb0000007e1-42-46d3cfcfa7e9
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7CCBF203FB; Tue, 28 Aug 2007 09:33:35 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200
Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200
Message-ID: <46D3CFCF.6070308@ericsson.com>
Date: Tue, 28 Aug 2007 09:33:35 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> <XFE-SJC-211IFprhMOg0000051a@xfe-sjc-211.amer.cisco.com>
In-Reply-To: <XFE-SJC-211IFprhMOg0000051a@xfe-sjc-211.amer.cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
X-OriginalArrivalTime: 28 Aug 2007 07:33:35.0545 (UTC) FILETIME=[BE24DA90:01C7E945]
X-Brightmail-Tracker: AAAAAA==
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 4d9ae72af46718088458d214998cc683
Cc: sip@ietf.org, dime@ietf.org, IETF SIPPING WG <sipping@ietf.org>, tsvwg <tsvwg@ietf.org>, NSIS <nsis@ietf.org>
Subject: [Sipping] Re: [Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org
Hi again, I have received some more comments. So here is an updated version adding DIME documents and correcting origin of documents. Submission Date: <tbd>, 2007 From: IETF Working groups TSVWG, NSIS, DIME, SIP and SIPPING To: Georges Sebek <tsbsg13@itu.int> , Keith Knightson <kgk@igs.net> Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, Lars Eggert <lars.eggert@nokia.com>, James Polk <jmpolk@cisco.com>, Martin Stiemerling <stiemerling@netlab.nec.de>, John Loughney <john.loughney@nokia.com> Dean Willis <dean.willis@softarmor.com>, Keith Drage <drage@alcatel-lucent.com>, Mary Barnes <mary.barnes@nortel.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, Scott Bradner <sob@harvard.edu>, Kimberly King <ksking@mitre.org>, Scott Brim <swb@employees.org>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, David Frascone <dave@frascone.com> Response Contact: TSV WG (tsv-chairs@tools.ietf.org) NSIS (nsis-chairs@tools.ietf.org) SIPPING (sipping-chairs@tools.ietf.org) SIP (sip-chairs@tools.ietf.org) DIME (dime-chairs@tools.ietf.org) Purpose: Response to Liaison Request Deadline: None Title: Response to liaison request from ITU-T Study Group 13 work on emergency telecommunications This is a response to the liaison request made by Q.3/13 regarding emergency telecommunications (REF: NGN-GSI/DOC – 60 Rev.2). We would first like to apologize for failing to meet the deadline in responding. We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG): IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has concluded. In addition to the WGs from which information was requested, we also think that work performed by the DIME, SIP and SIPPING WG may be of relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and related work in the IETF regarding emergency communications, we list below RFCs and works in progress that we feel may be of interest to your group. Some of the completed work is Informational, and others are in the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in regards to emergency telecommunications. In those regards we would like to make you aware that IETF mailing list participation and document information is free and open to anyone, allowing participants in Q.3/13 to keep themselves informed of any developments. If Q.3/13 desire to get further information about specific ongoing work, then please send a liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from which the work has been done within the IETF. SIP Working Group RFC 4412 Title: Communications Resource Priority for the Session Initiation Protocol (SIP) Abstract: This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. The below two documents are proposed work items accepted to become IETF WG items are likely of interest as they update RFC 4412. Work In Progress: draft-polk-sip-rph-in-responses-00 Title: Allowing SIP Resource Priority Header in SIP Responses Abstract: The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent client to process the Resource-Priority Header in a response. Work In Progress: draft-polk-sip-rph-new-namespaces--00 Title: New Session Initiation Protocol Resource-Priority Header Namespaces for the Defense Information Systems Agency Abstract: This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. SIPPING Working Group RFC 4411 Title: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events Abstract: This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. IEPREP Working Group RFC 3487 Title: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) Abstract: This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. RFC 4190 Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony Abstract: This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. RFC 4375 Title: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. TSV Working Group RFC 4542 Title: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite Abstract: RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt Title: Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Abstract: An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. NSIS Working Group Work In Progress: draft-ietf-nsis-qos-nslp-14.txt Title: NSLP for Quality-of-Service Signaling Abstract: This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. DIME Working Group Work In Progress: draft-ietf-dime-diameter-qos-01.txt Title: Diameter Quality of Service Application Abstract: This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. Work In Progress: draft-ietf-dime-qos-parameters-00.txt Title: Quality of Service Parameters for Usage with the AAA Framework Abstract: This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. Work In Progress: draft-ietf-dime-qos-attributes-01.txt Title: Quality of Service Attributes for Diameter and RADIUS Abstract: This document extends the functionality of the Diameter Base protocol and other Diameter applications with respect to their ability to convey Quality of Service information. The AVPs defined in this document are also available for Remote Authentication Dial In User Service (RADIUS). Non-WG Documents Approved for publication: draft-carlberg-trip-attribute-rp-02.txt Title: TRIP Attribute for Resource Priority Abstract: This document defines a new attribute for the TRIP protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the PSTN are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tupple defined for the SIP resource Priority field. Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- [Sipping] Draft Liaision response to SG13 on Emer… Magnus Westerlund
- [Sipping] Re: [Tsvwg] Draft Liaision response to … Janet P Gunn
- [Sipping] Re: [Tsvwg] Draft Liaision response to … Magnus Westerlund
- [Sipping] Re: [Tsvwg] Draft Liaision response to … Janet P Gunn
- [Sipping] Re: [Sip] Draft Liaision response to SG… Dale.Worley
- [Sipping] Re: [Sip] Draft Liaision response to SG… Magnus Westerlund
- [Sipping] RE: [Sip] Re: [Tsvwg] Draft Liaision re… DRAGE, Keith (Keith)
- [Sipping] Re: Draft Liaison response to SG13 on E… Magnus Westerlund
- [Sipping] Re: [Sip] Re: Draft Liaison response to… James M. Polk
- [Sipping] Re: [Tsvwg] Re: [Sip] Re: Draft Liaison… Magnus Westerlund
- [Sipping] Re: [NSIS] Re: [Tsvwg] Re: [Sip] Re: Dr… James M. Polk