Skip to main content

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

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6432.
Authors Laura Liess , Roland Jesske
Last updated 2015-10-14 (Latest revision 2011-08-10)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 6432 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Gonzalo Camarillo
Send notices to (None)
draft-jesske-dispatch-update3326-reason-responses-05
DISPATCH                                                       R. Jesske
Internet-Draft                                                  L. Liess
Intended status: Standards Track                        Deutsche Telekom
Expires: February 12, 2012                               August 11, 2011

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

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 cause
   codes for failure responses to INVITE requests that have been
   gatewayed to PSTN systems.  This document normatively describes the
   use of the Reason header field in SIP responses to carry Q.850 cause
   codes.

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 February 12, 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 February 12, 2012               [Page 1]
Internet-Draft                Reason Header                  August 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 . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 4

Jesske & Liess          Expires February 12, 2012               [Page 2]
Internet-Draft                Reason Header                  August 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] cause codes for failure responses to INVITE requests that
   have been gatewayed to PSTN systems.  This document normatively
   describes the use of the Reason header field in SIP responses to
   carry Q.850 [Q.850] cause codes.

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

   This document allows SIP responses to carry Reason header fields as
   follows:

   Any SIP Response message, with the exception of a 100 (Trying) MAY
   contain a Reason header field with a Q.850 [Q.850] cause code.

   The Reason header field is not needed in the the 100 (Trying)
   responses since they are transmitted hop-by-hop, not end-to-end.  SIP
   responses with Reason header fields carrying values other than Q.850
   [Q.850] cause code are outside of the scope of this document.

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.

Jesske & Liess          Expires February 12, 2012               [Page 3]
Internet-Draft                Reason Header                  August 2011

5.  IANA Considerations

   No IANA actions are required

6.  Acknowledgments

   Thanks to Gonzalo Camarillo and Mary Barnes 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.

   [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 February 12, 2012               [Page 4]
Internet-Draft                Reason Header                  August 2011

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

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

Jesske & Liess          Expires February 12, 2012               [Page 5]