idnits 2.17.1 draft-khatri-sipcore-call-transfer-fail-response-00.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 date (March 11, 2021) is 1113 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 326, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Shrawan Kumar Khatri 2 Internet-Draft Vikram Singh 3 Marcelo Pazos 4 Cherng-Shung Hsu 5 Yong Xie 6 Intended status: Standard Track Qualcomm Incorporated 7 Expires: September 2021 March 11, 2021 9 A SIP Response Code (497) for Call Transfer Failure 10 draft-khatri-sipcore-call-transfer-fail-response-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as "work 26 in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on September 11, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. 48 Abstract 49 This document defines the 497 (Call Transfer Failure) SIP 50 response code, allowing Call Pull and Call Push parties to 51 indicate that the operation was rejected. Optional warning codes 52 are defined to carry granular information. SIP entities may use 53 this information to adjust how subsequent calls can be handled 54 intelligently. 56 Table of Contents 58 1. Introduction................................................. 2 59 2. Normative Language........................................... 3 60 3. Motivation................................................... 3 61 4. Theory of Operation.......................................... 4 62 5. IANA Considerations.......................................... 6 63 5.1. SIP Response Code....................................... 6 64 5.2. Warning codes........................................... 7 65 5.3. SIP Global Feature-Capability Indicator................. 8 66 6. Security Considerations...................................... 8 67 7. References................................................... 8 68 7.1. Normative References.................................... 8 69 8. Acknowledgments.............................................. 9 71 1. Introduction 73 Packet switch calls for voice, video and text applications using 74 IP Multimedia Subsystems (IMS) are anchored in the IMS core 75 network. The signaling plane and media plane of IMS calls 76 established on one device can be pushed ("Call Push") to another 77 device. Similarly, IMS calls established on one device can be 78 pulled ("Call Pull") by another device using SIP signaling. 80 The call status during the SIP transaction can be conveyed through 81 SIP response codes. RFC 3261 has defined many SIP response codes. 82 The IMS core network MAY define a policy to allow or reject the 83 Call Pull or Call Push operation. There are numerous reasons why 84 the Call Pull or Call Push operation can fail. In case of call 85 transfer failure due to policy defined by the IMS core network, 86 the IMS core network MAY want to convey the failure to the user 87 agent (UA) through a response code. Based on the response code, 88 the UA MAY determine whether and how to establish a subsequent 89 call. 91 The existing response codes in RFC 3261 are not sufficient to 92 convey the information about the call transfer failure to the UA. 93 Overloading an existing response code could lead to unnecessary 94 subsequent signaling which could burden the IMS core network. To 95 avoid possible signaling overload in the IMS core network and to 96 accurately convey the call transfer failure to the UA, a new 97 response code along with associated optional warning codes to be 98 included in a Warning header field are proposed in this RFC. 100 2. Normative Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 103 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 104 "MAY", and "OPTIONAL" in this document are to be interpreted as 105 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 106 appear in all capitals, as shown here. 108 3. Motivation 110 Seamless transfer of the media plane of an on-going voice call 111 between devices is a legacy behavior. The signaling plane in the 112 legacy behavior resides on the originating device. 114 If the two devices can run IMS over SIP signaling, the signaling 115 plane and media plane can be transferred between these devices 116 with minimal media flow interruption. The control plane and media 117 plane transfer procedures are beyond the scope of this RFC. 119 There are various reasons why an on-going call cannot be 120 transferred between the devices. Some of these reasons are policy 121 driven, for instance: the call to be transferred is in the circuit 122 switched (CS) domain and the operator's policy does not allow 123 transfer of a CS call, the call is an emergency call and the 124 operator's policy does not allow transfer of an emergency call, 125 the call is a mobile-terminated call and the operator's policy 126 does not allow transfer of a mobile-terminated call, or the call 127 is a video call and the operator's policy does not allow transfer 128 of a video call. 130 The UA initiating the call transfer procedure will be notified of 131 any failure through a SIP response code. However the existing SIP 132 response codes are not suitable to adequately convey the 133 information regarding why the call transfer request is not 134 accepted by the network: handling of these existing response codes 135 has already been implemented by various devices, with an 136 associated device behavior defined for a specific purpose not 137 related to call transfer. For instance, upon receiving some of 138 these response code, such as 403 (Forbidden), the device MAY 139 initiate IMS re-registration procedure, which is not needed in 140 case of Call Pull/Call Push failure and will result in unnecessary 141 SIP signaling. 143 Consequently, to accurately convey the information about the call 144 transfer failure to the UA, a new response code is required along 145 with an optional warning code in a Warning header field to convey 146 the exact reason why the call could not be transferred, so that 147 the UA can determine the subsequent steps (e.g. call termination) 148 and optionally provide an indication of the reason for the failure 149 to the user. 151 4. Theory of Operation 153 Feature-capability: 155 A new feature-capability is defined as iut-focus.497. 157 During the Subscribe phase, the feature-capability is notified 158 to the IMS core network indicating that response code 497 is 159 supported by the UA in Accept-Contact Header. If a call 160 transfer fails and response code 497 is not supported by the 161 network, the SIP response code should be chosen from existing 162 SIP response codes defined in RFC 3261. If a call transfer 163 fails and response code 497 is supported by the network, the 164 SIP response SHALL include SIP response code 497. 166 Response code: 168 A new SIP response code 497 is defined. 170 Description: Call Transfer Failure 172 The server understood the call transfer request but is refusing 173 the service. The SIP response with SIP response code 497 MAY 174 include a Warning header field [RFC3261] with a warning code 175 set to one of the values listed below and the associated 176 warning text conveying granular information about the reason 177 for the call transfer failure, so as to enable the UA to 178 develop extra logic for subsequent call transfer procedure. 180 Warning header: 182 An optional Warning header will carry more granular failure 183 information as follows: 185 400. Call is not in active state 187 401. Call is muted at local end 189 402. Call is muted at remote end 191 403. Call is on hold 193 404. Call is a CS call 195 405. Call does not exist on the other device 197 406. Call is a conference call 199 407. Call is an emergency call 201 408. Call is a video call 203 409. Call is an RTT (Real Time Text) call 205 410. Call is in the Mortal state [RFC5407] 207 411. Call is being handed over to the CS domain 209 412. Unspecified error 211 Example: 213 Warning: 407 proxy.example.com "Call is an emergency call" 215 The following call flow illustrates the usage of SIP response 216 code 497 and the associated warning codes: 218 UA core network 219 | | 220 | | 221 | 1. SUBSCRIBE with Accept-Contact: iut-focus.497 | 222 |-------------------------------------------------------->| 223 | | 224 | 2. 200 OK | 225 |<--------------------------------------------------------| 226 | | 227 | | 228 | | 229 | 3. INVITE | 230 |-------------------------------------------------------->| 231 | | 232 | 4. 497 Call Transfer Failure with Warning: 407 | 233 | proxy.example.com "Call is an emergency call" | 234 |<--------------------------------------------------------| 235 | | 236 Figure 1: Usage of SIP response code 497 238 1. The UA supporting SIP response code 497 sends a SUBSCRIBE with 239 an Accept-Contact header field containing feature-capability iut- 240 focus.497 242 2. The core network acknowledges the SUBSCRIBE with 200 OK 244 3. Subsequently, the UA sends an INVITE to request a call transfer 246 4. The call transfer request cannot be satisfied due to the call 247 requested to be transferred being an emergency call. Since the 248 core network supports SIP response code 497, the core network 249 sends a 497 Call Transfer Failure with a Warning header field set 250 to: 407 proxy.example.com "Call is an emergency call" 252 5. IANA Considerations 254 5.1. SIP Response Code 256 This document registers a new SIP response code. This response 257 code is defined by the following information, which has been added 258 to the "Response Codes" sub-registry under the "Session Initiation 259 Protocol (SIP) Parameters" registry 260 . 262 Response Code: 497 264 Description: CALL TRANSFER FAILURE 266 The server understood the request to transfer the call but is 267 refusing the service. This response MAY include a Warning header 268 field [RFC3261] with a warning code set to one of the values 269 listed in section 5.2 and the associated warning text conveying 270 granular information about the reason for the call transfer 271 failure. 273 Reference: [RFCxxxx] 275 5.2. Warning codes 277 This document registers new warning codes. These warning codes are 278 defined by the following information, which has been added to the 279 "Warning Codes (warn-codes)" sub-registry under the "Session 280 Initiation Protocol (SIP) Parameters" registry 281 . 283 400. Call is not in active state 285 401. Call is muted at local end 287 402. Call is muted a remote end 289 403. Call is on hold 291 404. Call is a CS call 293 405. Call does not exist on the other device 295 406. Call is a conference call 297 407. Call is an emergency call 299 408. Call is a video call 301 409. Call is an RTT (Real Time Text) call 303 410. Call is in the Mortal state [RFC5407] 305 411. Call is being handed over to the CS domain 307 412. Unspecified error 309 Reference: [RFCxxxx] 311 5.3. SIP Global Feature-Capability Indicator 313 This document defines the feature capability iut-focus.497 in the 314 "SIP Feature-Capability Indicator Registration Tree" registry 315 defined in [RFC6809]. 317 Name: iut-focus.497 319 Description: This feature-capability indicator, when included in 320 an Accept-Contact Header field of a SUBSCRIBE message, indicates 321 that the User Agent (UA) supports the 497 response code. In case 322 of call transfer failure, if response code 497 is supported by the 323 network and notified through Accept-Contact header of SUBSCRIBE 324 signaling, the network SHALL send response code 497. 326 Reference: [RFCxxxx] 328 6. Security Considerations 330 The general discussion in [RFC3261] applies. 332 7. References 334 7.1. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, March 1997. 339 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., 340 Johnston, A., Peterson, J., Sparks, R., Handley, M., 341 and E. Schooler, "SIP: Session Initiation Protocol", 342 RFC 3261, DOI 10.17487/RFC3261, June 2002, 343 . 345 [RFC5407] Hasebe, M., Koshiko, J., Suzuki, Y., Yoshikawa, T., 346 Kyzivat, P., "Example Call Flows of Race Conditions in 347 the Session Initiation Protocol (SIP)", BCP 147, RFC 348 5407, DOI 10.17487/RFC5407, December 2008, 349 . 351 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 352 2119 Key Words", BCP 14, FC 8174, DOI 10.17487/RFC8174, 353 May 2017, . 355 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism 356 to Indicate Support of Features and Capabilities in the 357 Session Initiation Protocol (SIP)", RFC 6809, DOI 358 10.17487/RFC6809, November 2012, . 361 8. Acknowledgments 363 Lena Chaponniere, Qualcomm Inc. and Waqar Zia, Qualcomm Inc. for 364 the technical guidance. 366 Authors' Addresses 368 Shrawan Khatri 369 5775 Morehouse Drive 370 San Diego, CA 92121 371 United States of America 372 Email: skhatri@qualcomm.com 374 Vikram Singh 375 5775 Morehouse Drive 376 San Diego, CA 92121 377 United States of America 378 viksingh@qualcomm.com 380 Marcelo Pazos 381 5775 Morehouse Drive 382 San Diego, CA 92121 383 United States of America 384 mpazos@qualcomm.com 386 Cherng-Shung Hsu 387 5775 Morehouse Drive 388 San Diego, CA 92121 389 United States of America 390 simonh@qualcomm.com 392 Yong Xie 393 5775 Morehouse Drive 394 San Diego, CA 92121 395 United States of America 396 yongxie@qualcomm.com