One document matched: draft-jesske-dispatch-update3326-reason-responses-03.txt

Differences from draft-jesske-dispatch-update3326-reason-responses-02.txt

DISPATCH                                                       R. Jesske
Internet-Draft                                                  L. Liess
Intended status: Standards Track                        Deutsche Telekom
Expires: January 5, 2012                                    July 4, 2011


Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation
                          Protocol) Responses
          draft-jesske-dispatch-update3326-reason-responses-03

Abstract

   Although the use of the Reason header field in responses is
   considered in general in RFC3326, its use is not specified for any
   particular response code.  Nonetheless, existing deployments have
   been using Reason header fields in responses to carry Q.850 reason
   codes for failure responses to INVITE requests that have been
   gatewayed to PSTN systems.  This document specifies and formally
   permits the use of the Reason header field in SIP responses to carry
   Q.850 reason codes for this and other purposes.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 5, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Jesske & Liess           Expires January 5, 2012                [Page 1]

Internet-Draft                Reason Header                    July 2011


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 4

























Jesske & Liess           Expires January 5, 2012                [Page 2]

Internet-Draft                Reason Header                    July 2011


1.  Overview

   Although the use of the Reason header field in responses is
   considered in general in RFC3326[RFC3326], its use is not specified
   for any particular response code.  Nonetheless, existing deployments
   have been using Reason header fields in responses to carry Q.850
   [Q.850] reason codes for failure responses to INVITE requests that
   have been gatewayed to PSTN systems.  This document specifies and
   formally permits the use of the Reason header field in SIP responses
   to carry Q.850 [Q.850] cause codes for this and other purposes.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document uses terms from [RFC3261].

3.  Applicability

   RFC 3326 [RFC3326] allows the presence of the Reason header field in
   any response whose status code explicitly allows its presence.  This
   document explicitly allows any SIP response, except 100 (Trying), to
   carry a Reason header field with a Q.850 [Q.850] cause code.  SIP
   responses with Reason header fields carrying values other than Q.850
   cause code are outside of the scope of this document.

   Note that 100 (Trying) responses are transmitted hop-by-hop, not end-
   to-end.

4.  Security Considerations

   This specification allows the presence of the Reason containing Q.850
   [Q.850] cause codes in responses.  The presence of the Reason header
   field in a response does not affect the treatment of the response.
   Nevertheless, there could be situations where a wrong Q.850 [Q.850]
   cause code could, for example, cause an announcement system to play
   the wrong information.  To avoid such situations, it is RECOMMENDED
   that this header field is protected by a suitable integrity
   mechanism.  The use of transport or network layer hop-by-hop security
   mechanisms, such as TLS or IPSec with appropriate cipher suites, can
   satisfy this requirement.

5.  IANA Considerations

   No IANA actions are required




Jesske & Liess           Expires January 5, 2012                [Page 3]

Internet-Draft                Reason Header                    July 2011


6.  Acknowledgments

   Thanks to Gonzalo Camarillo for the detailed review of this document.

   Thanks to Paul Kyzivat, Mary Barnes, John Elwell, Keith Drage, Thomas
   Belling who provided helpful comments, feedback and suggestions.

7.  Normative References

   [Q.850]    "Usage of cause and location in the Digital Subscriber
              Signalling System No. 1 and the Signalling System No. 7
              ISDN User Part [ITU-T Recommendation Q.850]",
              ITU Recommendation Q.850, April 1998.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
              Extensions to the Session Initiation Protocol (SIP) for
              Asserted Identity within Trusted Networks", RFC 3325,
              November 2002.

   [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
              Header Field for the Session Initiation Protocol (SIP)",
              RFC 3326, December 2002.

Authors' Addresses

   Roland Jesske
   Deutsche Telekom
   Heinrich-Hertz-Strasse 3-7
   Darmstadt,   64307
   Germany

   Phone: +4961515812766
   EMail: r.jesske@telekom.de










Jesske & Liess           Expires January 5, 2012                [Page 4]

Internet-Draft                Reason Header                    July 2011


   Laura Liess
   Deutsche Telekom
   Heinrich-Hertz-Strasse 3-7
   Darmstadt,   64307
   Germany

   Phone: +4961515812761
   EMail: Laura.Liess@telekom.de











































Jesske & Liess           Expires January 5, 2012                [Page 5]