Subject: [sipcore] Motivation for submission of RFC

From: Shrawan Khatri <[email-masked]>
Date: Thu, 11 Mar 2021 18:11:02 +0000

Hello SIPCORE Chair and SIPCORE team,
Please find the motivation behind this RFC draft.

Regards,
Shrawan Khatri and team

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,
o             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.
o             The existing SIP response codes do not accurately convey the reason for the call transfer failure.

*             With the new mechanism
o             A specific behavior can be defined for the new SIP response code.
o             Unnecessary SIP signaling may be avoided.
o             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.

Name:                  draft-khatri-sipcore-call-transfer-fail-response

Revision:              00

Title:                      A SIP Response Code (497) for Call Transfer Failure

Document date:               2021-03-11

Group:                  Individual Submission

Pages:                   10

URL:            https://www.ietf.org/archive/id/draft-khatri-sipcore-call-transfer-fail-response-00.txt

Status:         https://datatracker.ietf.org/doc/draft-khatri-sipcore-call-transfer-fail-response/

Htmlized:       https://datatracker.ietf.org/doc/html/draft-khatri-sipcore-call-transfer-fail-response

Htmlized:       https://tools.ietf.org/html/draft-khatri-sipcore-call-transfer-fail-response-00

Subject: [EXT] New Version Notification for draft-khatri-sipcore-call-transfer-fail-response-00.txt
From: "[email-masked]" <[email-masked]>
To: Simon Hsu <[email-masked]>, Marcelo Pazos <[email-masked]>, Shrawan Khatri <[email-masked]>, "Vikram Singh (IMS)" <[email-masked]>, Yong Xie <[email-masked]>
Date: Thu, 11 Mar 2021 17:51:02 +0000

A new version of I-D, draft-khatri-sipcore-call-transfer-fail-response-00.txt
has been successfully submitted by Shrawan Khatri and posted to the
IETF repository.

Name:           draft-khatri-sipcore-call-transfer-fail-response
Revision:       00
Title:          A SIP Response Code (497) for Call Transfer Failure
Document date:  2021-03-11
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/archive/id/draft-khatri-sipcore-call-transfer-fail-response-00.txt
Status:         https://datatracker.ietf.org/doc/draft-khatri-sipcore-call-transfer-fail-response/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-khatri-sipcore-call-transfer-fail-response
Htmlized:       https://tools.ietf.org/html/draft-khatri-sipcore-call-transfer-fail-response-00

Abstract:
   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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ranjit Avasarala <[email-masked]>
Date: Thu, 11 Mar 2021 14:17:06 -0600

Hi Shrawan

So essentially you are trying to propose a new SIP 4xx response code with
optional warning code to indicate to UA the reason why the network did not
accept the call transfer request.  Though it may be useful, it may not be
like an essential feature that many network vendors and service providers
may be willing to support.

Still we can try and see how the reaction is from experts

Regards
Ranjit

On Thu, Mar 11, 2021 at 12:16 PM Shrawan Khatri <[email-masked]>
wrote:

> *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*
>
> •             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,
>
> o             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.
>
> •             With the new mechanism
> o             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.
>
>
>
> URL:
> https://www.ietf.org/archive/id/draft-khatri-sipcore-call-transfer-fail-response-00.txt
>
> Status:
> https://datatracker.ietf.org/doc/draft-khatri-sipcore-call-transfer-fail-response/
>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-khatri-sipcore-call-transfer-fail-response
>
> Htmlized:
> https://tools.ietf.org/html/draft-khatri-sipcore-call-transfer-fail-response-00
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Mar 2021 08:23:11 +0000

Hi Shrawan,
A couple of initial comments:
Q1: Please add references to the 3GPP specifications that define the procedure you are referring to.
Q2: It would help people not familiar with the 3GPP procedures if you could include a couple of simple call flows showing the call push and call pull procedures.
Q3: I don't understand why you include the 497 feature-tag in a SUBSCRIBE. Since it is a response code to an INVITE request, you should include the feature-tag in the INVITE request.
Q4: 5 listed editors on a 10 page draft looks a little strange :) While I personally don't care, you may get some feedback on that.
Regards,
Christer

From: sipcore <[email-masked]> On Behalf Of Shrawan Khatri
Sent: torstai 11. maaliskuuta 2021 20.11
To: [email-masked]; [email-masked]
Cc: Waqar Zia <[email-masked]>; Simon Hsu <[email-masked]>; Marcelo Pazos <[email-masked]>; Yong Xie <[email-masked]>; Lena Chaponniere <[email-masked]>; Vikram Singh (IMS) <[email-masked]>
Subject: [sipcore] Motivation for submission of RFC

Regards,
Shrawan Khatri and team

The purpose of the draft

Intended target audience

Benefit

*             With the new mechanism

Revision:              00

Pages:                   10

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Mar 2021 08:54:30 +0000

Hi,
A couple of additional comments:
Q5: Please note that RFC 3261 does not define usage for 4xx warning codes. It says "The first digit of warning codes beginning with "3" indicates warnings specific to SIP. ".
Q6: I think you should use a media feature tag (RFC 3840), not a feature capability indicator.
Regards,
Christer

From: sipcore <[email-masked]> On Behalf Of Christer Holmberg
Sent: perjantai 26. maaliskuuta 2021 10.23
To: Shrawan Khatri <[email-masked]>; [email-masked]; [email-masked]
Cc: Lena Chaponniere <[email-masked]>; Simon Hsu <[email-masked]>; Marcelo Pazos <[email-masked]>; Yong Xie <[email-masked]>; Waqar Zia <[email-masked]>; Vikram Singh (IMS) <[email-masked]>
Subject: Re: [sipcore] Motivation for submission of RFC

Hi Shrawan,

From: sipcore <[email-masked]<mailto:[email-masked]>> On Behalf Of Shrawan Khatri
Sent: torstai 11. maaliskuuta 2021 20.11
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Waqar Zia <[email-masked]<mailto:[email-masked]>>; Simon Hsu <[email-masked]<mailto:[email-masked]>>; Marcelo Pazos <[email-masked]<mailto:[email-masked]>>; Yong Xie <[email-masked]<mailto:[email-masked]>>; Lena Chaponniere <[email-masked]<mailto:[email-masked]>>; Vikram Singh (IMS) <[email-masked]<mailto:[email-masked]>>
Subject: [sipcore] Motivation for submission of RFC

Regards,
Shrawan Khatri and team

The purpose of the draft

Intended target audience

Benefit

*             With the new mechanism

Revision:              00

Pages:                   10