Network Working Group Shrawan Kumar Khatri Internet-Draft Vikram Singh Marcelo Pazos Cherng-Shung Hsu Yong Xie Intended status: Standard Track Qualcomm Incorporated Expires: September 2021 March 11, 2021 A SIP Response Code (497) for Call Transfer Failure draft-khatri-sipcore-call-transfer-fail-response-00.txt 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 11, 2021. Copyright Notice Copyright (c) 2021 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. Abstract Khatri Expires September 11, 2021 [Page 1] Internet-Draft Call Transfer Failure March 2021 This document defines the 497 (Call Transfer Failure) SIP response code, allowing Call Pull and Call Push parties to indicate that the operation was rejected. Optional warning codes are defined to carry granular information. SIP entities may use this information to adjust how subsequent calls can be handled intelligently. Table of Contents 1. Introduction................................................. 2 2. Normative Language........................................... 3 3. Motivation................................................... 3 4. Theory of Operation.......................................... 4 5. IANA Considerations.......................................... 6 5.1. SIP Response Code....................................... 6 5.2. Warning codes........................................... 7 5.3. SIP Global Feature-Capability Indicator................. 8 6. Security Considerations...................................... 8 7. References................................................... 8 7.1. Normative References.................................... 8 8. Acknowledgments.............................................. 9 1. Introduction Packet switch calls for voice, video and text applications using IP Multimedia Subsystems (IMS) are anchored in the IMS core network. The signaling plane and media plane of IMS calls established on one device can be pushed ("Call Push") to another device. Similarly, IMS calls established on one device can be pulled ("Call Pull") by another device using SIP signaling. The call status during the SIP transaction can be conveyed through SIP response codes. RFC 3261 has defined many SIP response codes. The IMS core network MAY define a policy to allow or reject the Call Pull or Call Push operation. There are numerous reasons why the Call Pull or Call Push operation can fail. In case of call transfer failure due to policy defined by the IMS core network, the IMS core network MAY want to convey the failure to the user agent (UA) through a response code. Based on the response code, the UA MAY determine whether and how to establish a subsequent call. Khatri Expires September 11, 2021 [Page 2] Internet-Draft Call Transfer Failure March 2021 The existing response codes in RFC 3261 are not sufficient to convey the information about the call transfer failure to the UA. Overloading an existing response code could lead to unnecessary subsequent signaling which could burden the IMS core network. To avoid possible signaling overload in the IMS core network and to accurately convey the call transfer failure to the UA, a new response code along with associated optional warning codes to be included in a Warning header field are proposed in this RFC. 2. Normative Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Motivation Seamless transfer of the media plane of an on-going voice call between devices is a legacy behavior. The signaling plane in the legacy behavior resides on the originating device. If the two devices can run IMS over SIP signaling, the signaling plane and media plane can be transferred between these devices with minimal media flow interruption. The control plane and media plane transfer procedures are beyond the scope of this RFC. There are various reasons why an on-going call cannot be transferred between the devices. Some of these reasons are policy driven, for instance: the call to be transferred is in the circuit switched (CS) domain and the operator's policy does not allow transfer of a CS call, the call is an emergency call and the operator's policy does not allow transfer of an emergency call, the call is a mobile-terminated call and the operator's policy does not allow transfer of a mobile-terminated call, or the call is a video call and the operator's policy does not allow transfer of a video call. The UA initiating the call transfer procedure will be notified of any failure through a SIP response code. However the existing SIP response codes are not suitable to adequately convey the information regarding why the call transfer request is not accepted by the network: handling of these existing response codes Khatri Expires September 11, 2021 [Page 3] Internet-Draft Call Transfer Failure March 2021 has already been implemented by various devices, with an associated device behavior defined for a specific purpose not related to call transfer. For instance, upon receiving some of these response code, such as 403 (Forbidden), the device MAY initiate IMS re-registration procedure, which is not needed in case of Call Pull/Call Push failure and will result in unnecessary SIP signaling. Consequently, to accurately convey the information about the call transfer failure to the UA, a new response code is required along with an optional warning code in a Warning header field to convey the exact reason why the call could not be transferred, so that the UA can determine the subsequent steps (e.g. call termination) and optionally provide an indication of the reason for the failure to the user. 4. Theory of Operation Feature-capability: A new feature-capability is defined as iut-focus.497. During the Subscribe phase, the feature-capability is notified to the IMS core network indicating that response code 497 is supported by the UA in Accept-Contact Header. If a call transfer fails and response code 497 is not supported by the network, the SIP response code should be chosen from existing SIP response codes defined in RFC 3261. If a call transfer fails and response code 497 is supported by the network, the SIP response SHALL include SIP response code 497. Response code: A new SIP response code 497 is defined. Description: Call Transfer Failure The server understood the call transfer request but is refusing the service. The SIP response with SIP response code 497 MAY include a Warning header field [RFC3261] with a warning code set to one of the values listed below and the associated warning text conveying granular information about the reason for the call transfer failure, so as to enable the UA to develop extra logic for subsequent call transfer procedure. Warning header: Khatri Expires September 11, 2021 [Page 4] Internet-Draft Call Transfer Failure March 2021 An optional Warning header will carry more granular failure information as follows: 400. Call is not in active state 401. Call is muted at local end 402. Call is muted at remote end 403. Call is on hold 404. Call is a CS call 405. Call does not exist on the other device 406. Call is a conference call 407. Call is an emergency call 408. Call is a video call 409. Call is an RTT (Real Time Text) call 410. Call is in the Mortal state [RFC5407] 411. Call is being handed over to the CS domain 412. Unspecified error Example: Warning: 407 proxy.example.com "Call is an emergency call" The following call flow illustrates the usage of SIP response code 497 and the associated warning codes: UA core network | | Khatri Expires September 11, 2021 [Page 5] Internet-Draft Call Transfer Failure March 2021 | | | 1. SUBSCRIBE with Accept-Contact: iut-focus.497 | |-------------------------------------------------------->| | | | 2. 200 OK | |<--------------------------------------------------------| | | | | | | | 3. INVITE | |-------------------------------------------------------->| | | | 4. 497 Call Transfer Failure with Warning: 407 | | proxy.example.com "Call is an emergency call" | |<--------------------------------------------------------| | | Figure 1: Usage of SIP response code 497 1. The UA supporting SIP response code 497 sends a SUBSCRIBE with an Accept-Contact header field containing feature-capability iut- focus.497 2. The core network acknowledges the SUBSCRIBE with 200 OK 3. Subsequently, the UA sends an INVITE to request a call transfer 4. The call transfer request cannot be satisfied due to the call requested to be transferred being an emergency call. Since the core network supports SIP response code 497, the core network sends a 497 Call Transfer Failure with a Warning header field set to: 407 proxy.example.com "Call is an emergency call" 5. IANA Considerations 5.1. SIP Response Code This document registers a new SIP response code. This response code is defined by the following information, which has been added to the "Response Codes" sub-registry under the "Session Initiation Protocol (SIP) Parameters" registry . Khatri Expires September 11, 2021 [Page 6] Internet-Draft Call Transfer Failure March 2021 Response Code: 497 Description: CALL TRANSFER FAILURE The server understood the request to transfer the call but is refusing the service. This response MAY include a Warning header field [RFC3261] with a warning code set to one of the values listed in section 5.2 and the associated warning text conveying granular information about the reason for the call transfer failure. Reference: [RFCxxxx] 5.2. Warning codes This document registers new warning codes. These warning codes are defined by the following information, which has been added to the "Warning Codes (warn-codes)" sub-registry under the "Session Initiation Protocol (SIP) Parameters" registry . 400. Call is not in active state 401. Call is muted at local end 402. Call is muted a remote end 403. Call is on hold 404. Call is a CS call 405. Call does not exist on the other device 406. Call is a conference call 407. Call is an emergency call 408. Call is a video call 409. Call is an RTT (Real Time Text) call 410. Call is in the Mortal state [RFC5407] 411. Call is being handed over to the CS domain 412. Unspecified error Khatri Expires September 11, 2021 [Page 7] Internet-Draft Call Transfer Failure March 2021 Reference: [RFCxxxx] 5.3. SIP Global Feature-Capability Indicator This document defines the feature capability iut-focus.497 in the "SIP Feature-Capability Indicator Registration Tree" registry defined in [RFC6809]. Name: iut-focus.497 Description: This feature-capability indicator, when included in an Accept-Contact Header field of a SUBSCRIBE message, indicates that the User Agent (UA) supports the 497 response code. In case of call transfer failure, if response code 497 is supported by the network and notified through Accept-Contact header of SUBSCRIBE signaling, the network SHALL send response code 497. Reference: [RFCxxxx] 6. Security Considerations The general discussion in [RFC3261] applies. 7. References 7.1. Normative References [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, DOI 10.17487/RFC3261, June 2002, . [RFC5407] Hasebe, M., Koshiko, J., Suzuki, Y., Yoshikawa, T., Kyzivat, P., "Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)", BCP 147, RFC 5407, DOI 10.17487/RFC5407, December 2008, . Khatri Expires September 11, 2021 [Page 8] Internet-Draft Call Transfer Failure March 2021 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, FC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP)", RFC 6809, DOI 10.17487/RFC6809, November 2012, . 8. Acknowledgments Lena Chaponniere, Qualcomm Inc. and Waqar Zia, Qualcomm Inc. for the technical guidance. Khatri Expires September 11, 2021 [Page 9] Internet-Draft Call Transfer Failure March 2021 Authors' Addresses Shrawan Khatri 5775 Morehouse Drive San Diego, CA 92121 United States of America Email: skhatri@qualcomm.com Vikram Singh 5775 Morehouse Drive San Diego, CA 92121 United States of America viksingh@qualcomm.com Marcelo Pazos 5775 Morehouse Drive San Diego, CA 92121 United States of America mpazos@qualcomm.com Cherng-Shung Hsu 5775 Morehouse Drive San Diego, CA 92121 United States of America simonh@qualcomm.com Yong Xie 5775 Morehouse Drive San Diego, CA 92121 United States of America yongxie@qualcomm.com Khatri Expires September 11, 2021 [Page 10]