A SIP Response Code (497) for Call Transfer Failure
draft-khatri-sipcore-call-transfer-fail-response-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Shrawan Kumar Khatri , Vikram Singh , Marcelo Pazos , Cherng-Shung Hsu , Yong Xie | ||
| Last updated | 2021-03-11 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-khatri-sipcore-call-transfer-fail-response-00
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
<http://www.iana.org/assignments/sip-parameters>.
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
<http://www.iana.org/assignments/sip-parameters>.
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,
<http://www.rfc-editor.org/info/rfc3261>.
[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>.
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, <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>.
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]