[Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications

["James M. Polk" <[e-mail]>]

Magnus

comments in-line below about from which WG certain documents originated

At 10:04 AM 8/27/2007, Magnus Westerlund wrote:
>Hi,
>
>I have now updated this liaison reply to take 
>the comments into account. According to the 
>ECRIT chairs they don't think what they are 
>working is related to the ongoing work Q.3/13 is 
>working on. If you have any final comments 
>please provide them no later then the Wednesday 29th at 16.00 CEST.
>
>Magnus Westerlund
>
>
>Submission
>Date:           <tbd>, 2007
>
>From:           IETF Working groups TSVWG, NSIS, SIP and SIPPING
>
>To:             Georges Sebek  <[e-mail]> ,
>                 Keith Knightson <[e-mail]>
>
>Cc:             Magnus Westerlund <[e-mail]>,
>                 Lars Eggert <[e-mail]>,
>                 James Polk <[e-mail]>,
>                 Martin Stiemerling <[e-mail]>,
>                 John Loughney <[e-mail]>
>                 Dean Willis <[e-mail]>,
>                 Keith Drage <[e-mail]>,
>                 Mary Barnes <[e-mail]>,
>                 Gonzalo Camarillo <[e-mail]>,
>                 Scott Bradner <[e-mail]>,
>                 Kimberly King <[e-mail]>,
>                 Scott Brim <[e-mail]>
>
>Response
>Contact:        TSV WG ([e-mail])
>                 NSIS ([e-mail])
>                 SIPPING ([e-mail])
>                 SIP ([e-mail])
>
>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 woould 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 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 4411

RFC4411 is from SIPPING


>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

both IDs below are SIP WG items, not SIPPING


>         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.
>
>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.
>
>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 [phone]
>Torshamsgatan 23           | Fax   [phone]
>S-164 80 Stockholm, Sweden | mailto: [e-mail]
>----------------------------------------------------------------------
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [e-mail] for questions on current sip
>Use [e-mail] for new developments on the application of sip