Magnus, You might want to add-
draft-polk-tsvwg-signaled-domain-id-00.txt and draft-polk-ecrit-local-emergency-rph-namespace-01.txt (Both were on the agenda and discussed.) And maybe draft-carlberg-trip-attribute-rp-02 (though I did not see it on the agenda) Janet PS, My spelling checker says "Liaision" should be "Liaison", but it may be a US centric dictionary. J Magnus Westerlund <[EMAIL PROTECTED]> wrote on 07/31/2007 11:21:20 AM: > Hi > > This is the draft for a liaison response to be sent to SG 13 of the > ITU-T from the TSVWG, NSIS, SIP and SIPPING WGs. Please provide any > comments at the latest by the 14th of August. After that we will address > any raised comments and send the liaison to ITU-T before the end of August. > > Submission > Date: <tbd>, 2007 > > From: IETF Working groups TSVWG, NSIS, SIP and SIPPING > > To: Georges Sebek <[EMAIL PROTECTED]> , > Keith Knightson <[EMAIL PROTECTED]> > > Cc: Magnus Westerlund <[EMAIL PROTECTED]>, > Lars Eggert <[EMAIL PROTECTED]>, > James Polk <[EMAIL PROTECTED]>, > Martin Stiemerling <[EMAIL PROTECTED]>, > John Loughney <[EMAIL PROTECTED]> > Dean Willis <[EMAIL PROTECTED]>, > Keith Drage <[EMAIL PROTECTED]>, > Mary Barnes <[EMAIL PROTECTED]>, > Gonzalo Camarillo <[EMAIL PROTECTED]>, > Scott Bradner <[EMAIL PROTECTED]>, > Kimberly King <[EMAIL PROTECTED]>, > Scott Brim <[EMAIL PROTECTED]> > > Response > Contact: TSV WG ([EMAIL PROTECTED]) > NSIS ([EMAIL PROTECTED]) > SIPPING ([EMAIL PROTECTED]) > SIP ([EMAIL PROTECTED]) > > 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 Q3/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 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 for anyone. Allowing participants in Q.3/13 > to keep them selves 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 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. > > 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. > > > > SIPPING Working Group > > The below two documents are proposed work items not yet accepted as > IETF WG items but 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. > > 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. > > -- > > 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: [EMAIL PROTECTED] > ---------------------------------------------------------------------- > >
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
