dispatch R. Jesske
Internet-Draft L. Liess
Intended status: Informational Deutsche Telekom
Expires: July 14, 2011 January 10, 2011
Reason header filed in Session Initiation Protocol (SIP) responses
draft-jesske-dispatch-reason-in-responses-03
Abstract
Although the use of the Reason header field in responses is
considered in RFC3326, doing so is not specified for any existing
response code. Nonetheless, the Reason header field has been widely
used in responses to carry Q.850 reason codes for failure responses
to INVITEs 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 July 14, 2011.
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
to this document. Code Components extracted from this document must
Jesske & Liess Expires July 14, 2011 [Page 1]
Internet-Draft Reason Header January 2011
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overall Applicability . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Procedures at the UA . . . . . . . . . . . . . . . . . . . 4
5.2. Procedures at a SIP proxy . . . . . . . . . . . . . . . . . 4
5.3. Procedures at an application server . . . . . . . . . . . . 5
6. Procedures at an interworking point with ISUP . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Jesske & Liess Expires July 14, 2011 [Page 2]
Internet-Draft Reason Header January 2011
1. 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].
2. Overview
With introducing the Session Initiation Protocol [RFC3261]into the IP
Multimedia Subsystem (IMS) which is defined by the 3rd Generation
Partnership Project the it was required to interoperate with the
PSTN/ISDN. The European Telecommunication Standards Institute (ETSI)
has defined a Next Generation Network (NGN) where a substantial part
of it is based on the IMS.
ETSI has developed a number of requirements to support the usage of
SIP in Next Generation Networks that interoperate, at the service
level, with the Public Switched Telephone Network (PSTN), the
Integrated Services Digital Network (ISDN), the 3GPP IP Multimedia
Subsystem (IMS), and SIP networks and terminals that implement the
service logic.
Also ITU-T has specified an interworking between SIP and PSTN/ISDN
networks [ITU.Q1912.5.2004] and [TS29.163] where reason within
responses are already supported.
In order to provide full support in SIP of existing services,
extensions to SIP are needed.
This document proposes the use of the Reason header field in
responses. This is needed for creating services that must be
interoperable with the PSTN/ISDN network and the interoperability of
traversing communications through SIP not using SIP-I.
The main used case for reason header within responses are
interworking situations with PSTN/ISDN networks where the ISUP cause
In many cases the mapping of specific cause values will result in a
generic SIP Response.
[RFC3398] and other Interworking specifications like [RFC3326] are
describing the mapping of ISUP Cause Values to SIP and vice versa.
Looking on the specific mapping shows that information will be lost
when the call traverses ISUP without using SIP-T.
Jesske & Liess Expires July 14, 2011 [Page 3]
Internet-Draft Reason Header January 2011
3. Overall Applicability
The SIP procedures specified in this document are foreseen for
networks providing simulation services and/or interworking to the
PSTN/ISDN.
The document is describing the use of the Reason header in SIP
responses. These procedures are only valuable if the reason
contained in the element "protocol" is "Q.850". A inclusion of a SIP
reason (protocol="SIP") is not helpful due to the fact that the
response already provides the SIP reason. The Release Causes are
described within [Q.850]. (Note: The ETSI specifications can be
downloaded under http://pda.etsi.org/pda/queryform.asp free of
charge.)
The appearance of the Reason header is applicable to final responses
3xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses
[I-D.ietf-sipcore-199].
4. Requirements
A UA may have the ability to display ISUP specific release causes or
show a equivalent text.
In SIP-to-PSTN gateway scenarios, it is desirable to provide the UAC
with the specific call release reason provided by the PSTN. To
support this:
REQ-1: Provide in SIP responses a way to carry PSTN call release
codes, along with indication of any context or variant identification
needed to interpret the code unambiguously.
REQ-2: Provide an extensibility mechanism so that further information
about the call release can be specified.
5. Procedures
5.1. Procedures at the UA
A UA that supports the Reason header field can process the [Q.850]
Cause Value and display it or an equivalent text. The inclusion of a
Reason header field by UA is only for B2B UA interworking with the
PSTN/ISDN or providing services foreseen.
5.2. Procedures at a SIP proxy
SIP proxies that receive a response containing a Reason header field
is forwarding the response without changing the reason.
Jesske & Liess Expires July 14, 2011 [Page 4]
Internet-Draft Reason Header January 2011
A SIP proxy receiving a request that includes a Reason header field
can route the request to an application server for further analysis
and base services on it.
Based on network policy a Proxy can remove a Reason header field send
from a UAC.
5.3. Procedures at an application server
An application server that receives a SIP request that contains a
response including a Reason header MAY analyze the SIP Reason and
base further procedures on this analyses.
For Example the application server could use the reason for sending a
announcement towards the originating entity of the session.
As an example the Anonymous Communication Rejection (ACR) service
defined by ETSI Telecommunications and Internet converged Services
and Protocols for Advanced Networking (TISPAN)
6. Procedures at an interworking point with ISUP
For interoperability reasons the Q.850 Cause Value of a Release shall
be mapped to the Reason Header.
7. Security Considerations
The presence of the Reason header in a response does not affect the
treatment of the response.
Including such a header by an untrusted entity could adulterate the
reactions of the originating entities. E.G. sending back a cause
value "87" can cause an announcement within the PSTN/ISDN saying that
the call was rejected due to the Closed User Group service.
Therefore it is RECOMMENDED to include the Reason header information
in Responses only by trusted entities as it is described within
[RFC3325].
8. IANA Considerations
This document describes the use of the Reason header field described
within [RFC3326] . No additional SIP elements are defined within
this document. Therefore, this document does not provide any action
to IANA.
Jesske & Liess Expires July 14, 2011 [Page 5]
Internet-Draft Reason Header January 2011
9. Normative References
[I-D.ietf-sipcore-199] Holmberg, C., "Session Initiation Protocol
(SIP) Response Code for Indication of
Terminated Dialog", draft-ietf-sipcore-199-03
(work in progress), December 2010.
[ITU.Q1912.5.2004] International Telecommunications Union,
"Interworking between Session Initiation
Protocol (SIP) and Bearer Independent Call
Control protocol or ISDN User Part [ITU-T
Recommendation Q.1912.5 (2004)]",
ITU Recommendation Q.1912.5, April 2004.
[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.
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and
L. Ong, "Integrated Services Digital Network
(ISDN) User Part (ISUP) to Session Initiation
Protocol (SIP) Mapping", RFC 3398,
December 2002.
[TS29.163] "3rd Generation Partnership Project;
Technical Specification Group Core Network
and Terminals; Interworking between the IP
Jesske & Liess Expires July 14, 2011 [Page 6]
Internet-Draft Reason Header January 2011
Multimedia (IM) Core Network (CN) subsystem
and Circuit Switched (CS) networks (Release
8)".
Authors' Addresses
Roland Jesske
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt, 64307
Germany
Phone: +4961516282766
EMail: r.jesske@telekom.de
Laura Liess
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt, 64307
Germany
Phone: +4961516282761
EMail: Laura.Liess@telekom.de
Jesske & Liess Expires July 14, 2011 [Page 7]