idnits 2.17.00 (12 Aug 2021) /tmp/idnits46715/draft-jesske-dispatch-reason-in-responses-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 10, 2011) is 4148 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-sipcore-199 has been published as RFC 6228 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dispatch R. Jesske 3 Internet-Draft L. Liess 4 Intended status: Informational Deutsche Telekom 5 Expires: July 14, 2011 January 10, 2011 7 Reason header filed in Session Initiation Protocol (SIP) responses 8 draft-jesske-dispatch-reason-in-responses-03 10 Abstract 12 Although the use of the Reason header field in responses is 13 considered in RFC3326, doing so is not specified for any existing 14 response code. Nonetheless, the Reason header field has been widely 15 used in responses to carry Q.850 reason codes for failure responses 16 to INVITEs that have been gatewayed to PSTN systems. This document 17 specifies and formally permits the use of the Reason header field in 18 SIP responses to carry Q.850 reason codes for this and other 19 purposes. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 14, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Overall Applicability . . . . . . . . . . . . . . . . . . . . . 4 70 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 5.1. Procedures at the UA . . . . . . . . . . . . . . . . . . . 4 73 5.2. Procedures at a SIP proxy . . . . . . . . . . . . . . . . . 4 74 5.3. Procedures at an application server . . . . . . . . . . . . 5 75 6. Procedures at an interworking point with ISUP . . . . . . . . . 5 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 78 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 80 1. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 This document uses terms from [RFC3261]. 88 2. Overview 90 With introducing the Session Initiation Protocol [RFC3261]into the IP 91 Multimedia Subsystem (IMS) which is defined by the 3rd Generation 92 Partnership Project the it was required to interoperate with the 93 PSTN/ISDN. The European Telecommunication Standards Institute (ETSI) 94 has defined a Next Generation Network (NGN) where a substantial part 95 of it is based on the IMS. 97 ETSI has developed a number of requirements to support the usage of 98 SIP in Next Generation Networks that interoperate, at the service 99 level, with the Public Switched Telephone Network (PSTN), the 100 Integrated Services Digital Network (ISDN), the 3GPP IP Multimedia 101 Subsystem (IMS), and SIP networks and terminals that implement the 102 service logic. 104 Also ITU-T has specified an interworking between SIP and PSTN/ISDN 105 networks [ITU.Q1912.5.2004] and [TS29.163] where reason within 106 responses are already supported. 108 In order to provide full support in SIP of existing services, 109 extensions to SIP are needed. 111 This document proposes the use of the Reason header field in 112 responses. This is needed for creating services that must be 113 interoperable with the PSTN/ISDN network and the interoperability of 114 traversing communications through SIP not using SIP-I. 116 The main used case for reason header within responses are 117 interworking situations with PSTN/ISDN networks where the ISUP cause 118 In many cases the mapping of specific cause values will result in a 119 generic SIP Response. 121 [RFC3398] and other Interworking specifications like [RFC3326] are 122 describing the mapping of ISUP Cause Values to SIP and vice versa. 123 Looking on the specific mapping shows that information will be lost 124 when the call traverses ISUP without using SIP-T. 126 3. Overall Applicability 128 The SIP procedures specified in this document are foreseen for 129 networks providing simulation services and/or interworking to the 130 PSTN/ISDN. 132 The document is describing the use of the Reason header in SIP 133 responses. These procedures are only valuable if the reason 134 contained in the element "protocol" is "Q.850". A inclusion of a SIP 135 reason (protocol="SIP") is not helpful due to the fact that the 136 response already provides the SIP reason. The Release Causes are 137 described within [Q.850]. (Note: The ETSI specifications can be 138 downloaded under http://pda.etsi.org/pda/queryform.asp free of 139 charge.) 141 The appearance of the Reason header is applicable to final responses 142 3xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses 143 [I-D.ietf-sipcore-199]. 145 4. Requirements 147 A UA may have the ability to display ISUP specific release causes or 148 show a equivalent text. 150 In SIP-to-PSTN gateway scenarios, it is desirable to provide the UAC 151 with the specific call release reason provided by the PSTN. To 152 support this: 154 REQ-1: Provide in SIP responses a way to carry PSTN call release 155 codes, along with indication of any context or variant identification 156 needed to interpret the code unambiguously. 158 REQ-2: Provide an extensibility mechanism so that further information 159 about the call release can be specified. 161 5. Procedures 163 5.1. Procedures at the UA 165 A UA that supports the Reason header field can process the [Q.850] 166 Cause Value and display it or an equivalent text. The inclusion of a 167 Reason header field by UA is only for B2B UA interworking with the 168 PSTN/ISDN or providing services foreseen. 170 5.2. Procedures at a SIP proxy 172 SIP proxies that receive a response containing a Reason header field 173 is forwarding the response without changing the reason. 175 A SIP proxy receiving a request that includes a Reason header field 176 can route the request to an application server for further analysis 177 and base services on it. 179 Based on network policy a Proxy can remove a Reason header field send 180 from a UAC. 182 5.3. Procedures at an application server 184 An application server that receives a SIP request that contains a 185 response including a Reason header MAY analyze the SIP Reason and 186 base further procedures on this analyses. 188 For Example the application server could use the reason for sending a 189 announcement towards the originating entity of the session. 191 As an example the Anonymous Communication Rejection (ACR) service 192 defined by ETSI Telecommunications and Internet converged Services 193 and Protocols for Advanced Networking (TISPAN) 195 6. Procedures at an interworking point with ISUP 197 For interoperability reasons the Q.850 Cause Value of a Release shall 198 be mapped to the Reason Header. 200 7. Security Considerations 202 The presence of the Reason header in a response does not affect the 203 treatment of the response. 205 Including such a header by an untrusted entity could adulterate the 206 reactions of the originating entities. E.G. sending back a cause 207 value "87" can cause an announcement within the PSTN/ISDN saying that 208 the call was rejected due to the Closed User Group service. 210 Therefore it is RECOMMENDED to include the Reason header information 211 in Responses only by trusted entities as it is described within 212 [RFC3325]. 214 8. IANA Considerations 216 This document describes the use of the Reason header field described 217 within [RFC3326] . No additional SIP elements are defined within 218 this document. Therefore, this document does not provide any action 219 to IANA. 221 9. Normative References 223 [I-D.ietf-sipcore-199] Holmberg, C., "Session Initiation Protocol 224 (SIP) Response Code for Indication of 225 Terminated Dialog", draft-ietf-sipcore-199-03 226 (work in progress), December 2010. 228 [ITU.Q1912.5.2004] International Telecommunications Union, 229 "Interworking between Session Initiation 230 Protocol (SIP) and Bearer Independent Call 231 Control protocol or ISDN User Part [ITU-T 232 Recommendation Q.1912.5 (2004)]", 233 ITU Recommendation Q.1912.5, April 2004. 235 [Q.850] "Usage of cause and location in the Digital 236 Subscriber Signalling System No. 1 and the 237 Signalling System No. 7 ISDN User Part [ITU-T 238 Recommendation Q.850]", ITU Recommendation 239 Q.850, April 1998. 241 [RFC2119] Bradner, S., "Key words for use in RFCs to 242 Indicate Requirement Levels", BCP 14, 243 RFC 2119, March 1997. 245 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, 246 G., Johnston, A., Peterson, J., Sparks, R., 247 Handley, M., and E. Schooler, "SIP: Session 248 Initiation Protocol", RFC 3261, June 2002. 250 [RFC3325] Jennings, C., Peterson, J., and M. Watson, 251 "Private Extensions to the Session Initiation 252 Protocol (SIP) for Asserted Identity within 253 Trusted Networks", RFC 3325, November 2002. 255 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, 256 "The Reason Header Field for the Session 257 Initiation Protocol (SIP)", RFC 3326, 258 December 2002. 260 [RFC3398] Camarillo, G., Roach, A., Peterson, J., and 261 L. Ong, "Integrated Services Digital Network 262 (ISDN) User Part (ISUP) to Session Initiation 263 Protocol (SIP) Mapping", RFC 3398, 264 December 2002. 266 [TS29.163] "3rd Generation Partnership Project; 267 Technical Specification Group Core Network 268 and Terminals; Interworking between the IP 269 Multimedia (IM) Core Network (CN) subsystem 270 and Circuit Switched (CS) networks (Release 271 8)". 273 Authors' Addresses 275 Roland Jesske 276 Deutsche Telekom 277 Heinrich-Hertz-Strasse 3-7 278 Darmstadt, 64307 279 Germany 281 Phone: +4961516282766 282 EMail: r.jesske@telekom.de 284 Laura Liess 285 Deutsche Telekom 286 Heinrich-Hertz-Strasse 3-7 287 Darmstadt, 64307 288 Germany 290 Phone: +4961516282761 291 EMail: Laura.Liess@telekom.de