[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                           Shrawan Kumar Khatri
Internet-Draft                                          Vikram Singh
                                                       Marcelo Pazos
                                                    Cherng-Shung Hsu
                                                            Yong Xie
Intended status: Standard Track                Qualcomm Incorporated
Expires: January 2022                                  July 27, 2021


          A SIP Response Code (497) for Call Transfer Failure
        draft-khatri-sipcore-call-transfer-fail-response-01.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 January 27, 2022.

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 January 27, 2022             [Page 1]


Internet-Draft          Call Transfer Failure              July 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........................................... 4
   3. Motivation................................................... 4
   4. Theory of Operation.......................................... 5
   5. IANA Considerations.......................................... 8
      5.1. SIP Response Code....................................... 8
      5.2. Warning codes........................................... 8
   6. Security Considerations...................................... 9
   7. References................................................... 9
      7.1. Normative References.................................... 9
   8. Acknowledgments............................................. 10



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 January 27, 2022             [Page 2]


Internet-Draft          Call Transfer Failure              July 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.

    The following call flows illustrate the successful Call Pull.

   UA                                                  Core Network
    |                                                         |
    |                                                         |
    |     1. INVITE:                                          |
    |        Contact-Header: +g.3gpp.iut-focus                |
    |-------------------------------------------------------->|
    |                                                         |
    |     2. 200 OK                                           |
    |<--------------------------------------------------------|
    |                                                         |
          Figure 1: Call Pull Success

    1. The UA sends an INVITE to Pull the call from another device.
       Feature Tag: +g.3gpp.iut-focus [RFC6809] is added in the
       Contact Header field.
    2. The call transfer request satisfied. The Core Network sends
       200 OK.

    The following call flows illustrate the successful Call Push.

    UA                                                 Core Network
    |                                                         |
    |     1. REFER:                                           |
    |        Contact-Header: +g.3gpp.iut-focus                |
    |-------------------------------------------------------->|
    |                                                         |
    |     2. 202 Accepted                                     |
    |<--------------------------------------------------------|


Khatri                 Expires January 27, 2022             [Page 3]


Internet-Draft          Call Transfer Failure              July 2021

    |                                                         |
          Figure 2: Call Push Success

    1. The UA sends a REFER to Push the call to another device.
       Feature Tag: +g.3gpp.iut-focus is added in the Contact Header
       field.
    2. The call transfer request satisfied. The Core Network sends
       202 Accepted.


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 January 27, 2022             [Page 4]


Internet-Draft          Call Transfer Failure              July 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.

  Backward compatibility is maintained in both the UE and Network
  side. The Network component that has not implemented this RFC
  shall use the existing response code. The UE that has not
  implemented this RFC shall handle this new response code as an
  unknown response code.

4. Theory of Operation

  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:

  An optional Warning header will carry more granular failure
  information as follows:


  380. Inactive state
  381. Local Receive-only state


Khatri                 Expires January 27, 2022             [Page 5]


Internet-Draft          Call Transfer Failure              July 2021

  382. Local Transmit-only state
  383. Remote Receive-only state
  384. Remote Transmit-only state
  385. Hold state
  386. Mortal state
  387. Conference call
  388. Emergency call
  389. Video call
  390. Real Time Text call
  391. Circuit Switch call
  392. Non existing call
  393. Single Radio Voice Call Continuity in progress

  Feature-tag:

     media feature-tag:+g.3gpp.iut-focus [3GPP TS 24.337]

     In Call Pull, INVITE method is used and media feature tag
     "+g.3gpp.iut-focus" is included in the Contact Header field.

     In Call Push, REFER method is used and media feature tag
     "+g.3gpp.iut-focus" is included in the Contact Header field.

  Call Transfer failure

     If call transfer using INVITE or REFER method fails and
     response code 497 is supported by the network, the SIP response
     SHALL include SIP response code 497.

     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

     Example:

     Warning: 388 proxy.example.com "Call is an emergency call"





Khatri                 Expires January 27, 2022             [Page 6]


Internet-Draft          Call Transfer Failure              July 2021

     The following call flow illustrates the usage of SIP response
     code 497 and the associated warning codes:

   UA                                                  Core Network
    |                                                         |
    |                                                         |
    |     1. INVITE:                                          |
    |        Contact-Header: +g.3gpp.iut-focus                |
    |-------------------------------------------------------->|
    |                                                         |
    |     2. 497 Call Transfer Failure                        |
    |        Warning: 388 "Call is an emergency call"         |
    |<--------------------------------------------------------|
    |                                                         |
          Figure 3: Usage of SIP response code 497 Call Pull

    1. The UA sends an INVITE to Pull the call from another device.
       Feature Tag: +g.3gpp.iut-focus is added in the Contact Header
       field.
    2. 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: 388 "Call is an emergency call"



    UA                                              Core Network
    |                                                         |
    |     1. REFER:                                           |
    |        Contact-Header: +g.3gpp.iut-focus                |
    |-------------------------------------------------------->|
    |                                                         |
    |     2. 497 Call Transfer Failure                        |
    |        Warning: 388 "Call is an emergency call"         |
    |<--------------------------------------------------------|
    |                                                         |
          Figure 4: Usage of SIP response code 497 Call Push




Khatri                 Expires January 27, 2022             [Page 7]


Internet-Draft          Call Transfer Failure              July 2021

    1. The UA sends a REFER to Push the call to another device.
       Feature Tag: +g.3gpp.iut-focus is added in the Contact Header
       field.
    2. 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: 388 "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
  <http://www.iana.org/assignments/sip-parameters>.



  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
  <http://www.iana.org/assignments/sip-parameters>.

  380. Inactive state


Khatri                 Expires January 27, 2022             [Page 8]


Internet-Draft          Call Transfer Failure              July 2021

  381. Local Receive-only state

  382. Local Transmit-only state

  383. Remote Receive-only state

  384. Remote Transmit-only state

  385. Hold state

  386. Mortal state

  387. Conference call

  388. Emergency call

  389. Video call

  390. Real Time Text call

  391. Circuit Switch call

  392. Non existing call

  393. Single Radio Voice Call Continuity in progress

  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,
             <http://www.rfc-editor.org/info/rfc3261>.




Khatri                 Expires January 27, 2022             [Page 9]


Internet-Draft          Call Transfer Failure              July 2021

   [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,
             <http://www.rfc-editor.org/info/rfc5407>.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
             2119 Key Words", BCP 14, FC 8174, DOI 10.17487/RFC8174,
             May 2017, <http://www.rfc-editor.org/info/rfc8174>.

   [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, <https://www.rfc-
             editor.org/info/rfc6809>.

   [3GPP TS 24.337] "Universal Mobile Telecommunications System
             (UMTS); LTE; IP Multimedia (IM) Core Network
             (CN)subsystem IP Multimedia Subsystem (IMS) inter-UE
             transfer

8. Acknowledgments

  Lena Chaponniere, Qualcomm Inc. and Waqar Zia, Qualcomm Inc. for
  the technical guidance.

























Khatri                 Expires January 27, 2022            [Page 10]


Internet-Draft          Call Transfer Failure              July 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 January 27, 2022            [Page 11]