idnits 2.17.1 draft-khatri-sipcore-call-transfer-fail-response-02.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 (January 24, 2022) is 824 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 324, but not defined == Unused Reference: 'RFC5407' is defined on line 378, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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: July 2022 January 24, 2022 9 A SIP Response Code (497) for Call Transfer Failure 10 draft-khatri-sipcore-call-transfer-fail-response-02.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 July 24, 2022. 36 Copyright Notice 38 Copyright (c) 2022 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 Internet-Draft Call Transfer Failure January 24 51 This document defines the 497 (Call Transfer Failure) SIP 52 response code, allowing Call Pull and Call Push parties to 53 indicate that the operation was rejected. Optional warning codes 54 are defined to carry granular information. SIP entities may use 55 this information to adjust how subsequent calls can be handled 56 intelligently. 58 Table of Contents 60 1. Introduction................................................. 2 61 2. Normative Language........................................... 4 62 3. Motivation................................................... 4 63 4. Theory of Operation.......................................... 5 64 5. IANA Considerations.......................................... 8 65 5.1. SIP Response Code....................................... 8 66 5.2. Warning codes........................................... 8 67 6. Security Considerations...................................... 9 68 7. References................................................... 9 69 7.1. Normative References.................................... 9 70 8. Acknowledgments............................................. 10 72 1. Introduction 74 Packet switch calls for voice, video and text applications using 75 IP Multimedia Subsystems (IMS) are anchored in the IMS core 76 network. The signaling plane and media plane of IMS calls 77 established on one device can be pushed ("Call Push") to another 78 device. Similarly, IMS calls established on one device can be 79 pulled ("Call Pull") by another device using SIP signaling. 81 The call status during the SIP transaction can be conveyed through 82 SIP response codes. RFC 3261 has defined many SIP response codes. 83 The IMS core network MAY define a policy to allow or reject the 84 Call Pull or Call Push operation. There are numerous reasons why 85 the Call Pull or Call Push operation can fail. In case of call 86 transfer failure due to policy defined by the IMS core network, 87 the IMS core network MAY want to convey the failure to the user 88 agent (UA) through a response code. Based on the response code, 89 the UA MAY determine whether and how to establish a subsequent 90 call. 92 The existing response codes in RFC 3261 are not sufficient to 93 convey the information about the call transfer failure to the UA. 94 Overloading an existing response code could lead to unnecessary 95 subsequent signaling which could burden the IMS core network. To 96 avoid possible signaling overload in the IMS core network and to 97 accurately convey the call transfer failure to the UA, a new 98 response code along with associated optional warning codes to be 99 included in a Warning header field are proposed in this RFC. 101 The following call flows illustrate the successful Call Pull. 103 UA Core Network 104 | | 105 | | 106 | 1. INVITE: | 107 | Contact-Header: +g.3gpp.iut-focus | 108 |-------------------------------------------------------->| 109 | | 110 | 2. 200 OK | 111 |<--------------------------------------------------------| 112 | | 113 Figure 1: Call Pull Success 115 1. The UA sends an INVITE to Pull the call from another device. 116 Feature Tag: +g.3gpp.iut-focus [RFC6809] is added in the 117 Contact Header field. 118 2. The call transfer request satisfied. The Core Network sends 119 200 OK. 121 The following call flows illustrate the successful Call Push. 123 UA Core Network 124 | | 125 | 1. REFER: | 126 | Contact-Header: +g.3gpp.iut-focus | 127 |-------------------------------------------------------->| 128 | | 129 | 2. 202 Accepted | 130 |<--------------------------------------------------------| 131 | | 132 Figure 2: Call Push Success 134 1. The UA sends a REFER to Push the call to another device. 135 Feature Tag: +g.3gpp.iut-focus is added in the Contact Header 136 field. 137 2. The call transfer request satisfied. The Core Network sends 138 202 Accepted. 140 2. Normative Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 143 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 144 "MAY", and "OPTIONAL" in this document are to be interpreted as 145 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 146 appear in all capitals, as shown here. 148 3. Motivation 150 Seamless transfer of the media plane of an on-going voice call 151 between devices is a legacy behavior. The signaling plane in the 152 legacy behavior resides on the originating device. 154 If the two devices can run IMS over SIP signaling, the signaling 155 plane and media plane can be transferred between these devices 156 with minimal media flow interruption. The control plane and media 157 plane transfer procedures are beyond the scope of this RFC. 159 There are various reasons why an on-going call cannot be 160 transferred between the devices. Some of these reasons are policy 161 driven, for instance: the call to be transferred is in the circuit 162 switched (CS) domain and the operator's policy does not allow 163 transfer of a CS call, the call is an emergency call and the 164 operator's policy does not allow transfer of an emergency call, 165 the call is a mobile-terminated call and the operator's policy 166 does not allow transfer of a mobile-terminated call, or the call 167 is a video call and the operator's policy does not allow transfer 168 of a video call. 170 The UA initiating the call transfer procedure will be notified of 171 any failure through a SIP response code. However the existing SIP 172 response codes are not suitable to adequately convey the 173 information regarding why the call transfer request is not 174 accepted by the network: handling of these existing response codes 175 has already been implemented by various devices, with an 176 associated device behavior defined for a specific purpose not 177 related to call transfer. For instance, upon receiving some of 178 these response code, such as 403 (Forbidden), the device MAY 179 initiate IMS re-registration procedure, which is not needed in 180 case of Call Pull/Call Push failure and will result in unnecessary 181 SIP signaling. 183 Consequently, to accurately convey the information about the call 184 transfer failure to the UA, a new response code is required along 185 with an optional warning code in a Warning header field to convey 186 the exact reason why the call could not be transferred, so that 187 the UA can determine the subsequent steps (e.g. call termination) 188 and optionally provide an indication of the reason for the failure 189 to the user. 191 Backward compatibility is maintained in both the UE and Network 192 side. The Network component that has not implemented this RFC 193 shall use the existing response code. The UE that has not 194 implemented this RFC shall handle this new response code as an 195 unknown response code. 197 4. Theory of Operation 199 Response code: 201 A new SIP response code 497 is defined. 203 Description: Call Transfer Failure 205 The server understood the call transfer request but is refusing 206 the service. The SIP response with SIP response code 497 MAY 207 include a Warning header field [RFC3261] with a warning code set 208 to one of the values listed below and the associated warning text 209 conveying granular information about the reason for the call 210 transfer failure, so as to enable the UA to develop extra logic 211 for subsequent call transfer procedure. 213 Warning header: 215 An optional Warning header will carry more granular failure 216 information as follows: 218 380. Inactive state 219 381. Local Receive-only state 220 382. Local Transmit-only state 221 383. Remote Receive-only state 222 384. Remote Transmit-only state 223 385. Hold state 224 386. Mortal state 225 387. Conference call 226 388. Emergency call 227 389. Video call 228 390. Real Time Text call 229 391. Circuit Switch call 230 392. Non existing call 231 393. Single Radio Voice Call Continuity in progress 233 Feature-tag: 235 media feature-tag:+g.3gpp.iut-focus [3GPP TS 24.337] 237 In Call Pull, INVITE method is used and media feature tag 238 "+g.3gpp.iut-focus" is included in the Contact Header field. 240 In Call Push, REFER method is used and media feature tag 241 "+g.3gpp.iut-focus" is included in the Contact Header field. 243 Call Transfer failure 245 If call transfer using INVITE or REFER method fails and 246 response code 497 is supported by the network, the SIP response 247 SHALL include SIP response code 497. 249 If a call transfer fails and response code 497 is not supported 250 by the network, the SIP response code should be chosen from 251 existing 252 SIP response codes defined in RFC 3261 254 Example: 256 Warning: 388 proxy.example.com "Call is an emergency call" 257 The following call flow illustrates the usage of SIP response 258 code 497 and the associated warning codes: 260 UA Core Network 261 | | 262 | | 263 | 1. INVITE: | 264 | Contact-Header: +g.3gpp.iut-focus | 265 |-------------------------------------------------------->| 266 | | 267 | 2. 497 Call Transfer Failure | 268 | Warning: 388 "Call is an emergency call" | 269 |<--------------------------------------------------------| 270 | | 271 Figure 3: Usage of SIP response code 497 Call Pull 273 1. The UA sends an INVITE to Pull the call from another device. 274 Feature Tag: +g.3gpp.iut-focus is added in the Contact Header 275 field. 276 2. The call transfer request cannot be satisfied due to the call 277 requested to be transferred being an emergency call. Since 278 the core network supports SIP response code 497, the core 279 network sends a 497 Call Transfer Failure with a Warning 280 header field set to: 388 "Call is an emergency call" 282 UA Core Network 283 | | 284 | 1. REFER: | 285 | Contact-Header: +g.3gpp.iut-focus | 286 |-------------------------------------------------------->| 287 | | 288 | 2. 497 Call Transfer Failure | 289 | Warning: 388 "Call is an emergency call" | 290 |<--------------------------------------------------------| 291 | | 292 Figure 4: Usage of SIP response code 497 Call Push 294 1. The UA sends a REFER to Push the call to another device. 295 Feature Tag: +g.3gpp.iut-focus is added in the Contact Header 296 field. 297 2. The call transfer request cannot be satisfied due to the call 298 requested to be transferred being an emergency call. Since 299 the core network supports SIP response code 497, the core 300 network sends a 497 Call Transfer Failure with a Warning 301 header field set to: 388 "Call is an emergency call" 303 5. IANA Considerations 305 5.1. SIP Response Code 307 This document registers a new SIP response code. This response 308 code is defined by the following information, which has been added 309 to the "Response Codes" sub-registry under the "Session Initiation 310 Protocol (SIP) Parameters" registry 311 . 313 Response Code: 497 315 Description: CALL TRANSFER FAILURE 317 The server understood the request to transfer the call but is 318 refusing the service. This response MAY include a Warning header 319 field [RFC3261] with a warning code set to one of the values 320 listed in section 5.2 and the associated warning text conveying 321 granular information about the reason for the call transfer 322 failure. 324 Reference: [RFCxxxx] 326 5.2. Warning codes 328 This document registers new warning codes. These warning codes are 329 defined by the following information, which has been added to the 330 "Warning Codes (warn-codes)" sub-registry under the "Session 331 Initiation Protocol (SIP) Parameters" registry 332 . 334 380. Inactive state 335 381. Local Receive-only state 337 382. Local Transmit-only state 339 383. Remote Receive-only state 341 384. Remote Transmit-only state 343 385. Hold state 345 386. Mortal state 347 387. Conference call 349 388. Emergency call 351 389. Video call 353 390. Real Time Text call 355 391. Circuit Switch call 357 392. Non existing call 359 393. Single Radio Voice Call Continuity in progress 361 6. Security Considerations 363 The general discussion in [RFC3261] applies. 365 7. References 367 7.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., 373 Johnston, A., Peterson, J., Sparks, R., Handley, M., 374 and E. Schooler, "SIP: Session Initiation Protocol", 375 RFC 3261, DOI 10.17487/RFC3261, June 2002, 376 . 378 [RFC5407] Hasebe, M., Koshiko, J., Suzuki, Y., Yoshikawa, T., 379 Kyzivat, P., "Example Call Flows of Race Conditions in 380 the Session Initiation Protocol (SIP)", BCP 147, RFC 381 5407, DOI 10.17487/RFC5407, December 2008, 382 . 384 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 385 2119 Key Words", BCP 14, FC 8174, DOI 10.17487/RFC8174, 386 May 2017, . 388 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism 389 to Indicate Support of Features and Capabilities in the 390 Session Initiation Protocol (SIP)", RFC 6809, DOI 391 10.17487/RFC6809, November 2012, . 394 [3GPP TS 24.337] "Universal Mobile Telecommunications System 395 (UMTS); LTE; IP Multimedia (IM) Core Network 396 (CN)subsystem IP Multimedia Subsystem (IMS) inter-UE 397 transfer 399 8. Acknowledgments 401 Lena Chaponniere, Qualcomm Inc. and Waqar Zia, Qualcomm Inc. for 402 the technical guidance. 404 Authors' Addresses 406 Shrawan Khatri 407 5775 Morehouse Drive 408 San Diego, CA 92121 409 United States of America 410 Email: skhatri@qualcomm.com 412 Vikram Singh 413 5775 Morehouse Drive 414 San Diego, CA 92121 415 United States of America 416 viksingh@qualcomm.com 418 Marcelo Pazos 419 5775 Morehouse Drive 420 San Diego, CA 92121 421 United States of America 422 mpazos@qualcomm.com 424 Cherng-Shung Hsu 425 5775 Morehouse Drive 426 San Diego, CA 92121 427 United States of America 428 simonh@qualcomm.com 430 Yong Xie 431 5775 Morehouse Drive 432 San Diego, CA 92121 433 United States of America 434 yongxie@qualcomm.com