[sipcore] WG adoption Request

[Shrawan Khatri <[e-mail]>]

Dear SIPCore chairs and SIPCore members,

We submitted v04 of our I-D on a new SIP Response Code (497) for Call Transfer Failure (available at: https://datatracker.ietf.org/doc/draft-khatri-sipcore-call-transfer-fail-response/). This version has addressed all the comments received to date and we would therefore like to ask for WG adoption.


The purpose of the draft
Signaling plane and Media plane of an IMS calls can be transferred between devices using IMS Signaling. 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 user agent (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. This is because handling of these existing response codes 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 codes, 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.
A method is defined in this draft such that a call transfer failure SIP response code is defined 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.

Intended target audience
The following is the intended audience of this RFC:
*             IMS Core Network Planners that support IMS call transfer across multiple devices.
*             IMS System Designer and Developers of IMS Core Network and User Agent that support call transfer using IMS Signaling.
Benefit
*             In the absence of this new mechanism,

-          The IMS Core network has to rely on existing SIP response codes, for which a specific device behavior has already been defined. For instance, upon receiving some of these response codes, such as 403 (Forbidden), the device may initiate IMS re-registration procedure, which is not needed in case of call transfer failure and will result in unnecessary SIP signaling.

-          The existing SIP response codes do not accurately convey the reason for the call transfer failure.
*            With the new mechanism

-          A specific behavior can be defined for the new SIP response code.

-          Unnecessary SIP signaling may be avoided.

-          A User Agent may develop intelligent algorithms for subsequent call transfer procedure based on the warning code received in the Warning header field along with the new SIP response code.
Regards,
Shrawan Khatri