Re: [sipcore] WG adoption Request

[Ranjit Avasarala <[e-mail]>]

Hi Shrawan

while a new SIP response for call transfer failure may make sense, but
adding it to existing SIP implementations would be quite overwhelming and
kind of unnecessary.  Also like Brian suggests,  history-info header would
be useful to know what happened to the call - while transfer was being
attempted.

Also e.g. A calls B and B sends REFER to A with Refer-To: C, then A calls
C,  then a call from A to C is essentially a new call.  So why do we really
need 487?
in another scenario, when A calls B and B transfers the call to C,  then
say transfer to C fails, then here again, the call from B to C is like a
regular call.  so here too I don't see the need for 487.

comments?


On Mon, Sep 25, 2023 at 1:26 PM Shrawan Khatri <[e-mail]>
wrote:

> Hello Roland,
>
>
>
> The UE’s subsequent behavior is defined by carriers based on the SIP
> response code, not based on the accompanying History-Info header or cause
> in the Reason header that comes with along with the SIP Response code, and
> the UE’s behavior for existing SIP response codes has already been defined
> by carriers. None of the existing SIP response codes are suitable to handle
> the case of call transfer failure. For instance, receiving SIP response
> code 403 might cause the UE to perform IMS re-registration, which would be
> pointless if the call transfer failed due to the carrier’s policy. The
> purpose of the draft is to enable the definition of a specific UE behavior
> for this new type of failure to meet new automotive use cases.
>
>
>
> Note that in the past, similar drafts were submitted to introduce new SIP
> response codes for new use cases, in particular:
>
>
>
>                                                 - RFC 8197: A SIP Response
> Code for Unwanted Calls (From https://www.rfc-editor.org/rfc/rfc8197.html
> )
>
>                                                                 Response
> Code Number:  607
>
>
>
>                                                 - RFC 3329:  Security
> Mechanism Agreement for the Session Initiation Protocol (SIP)
>
>                                                                 - Response
> Code Number:  494  From https://datatracker.ietf.org/doc/html/rfc3329
>
>
>
> Regards,
>
> Shrawan
>
>
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* Wednesday, May 31, 2023 9:13 PM
> *To:* Shrawan Khatri <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; [e-mail]; Lena Chaponniere <
> [e-mail]>
> *Subject:* AW: WG adoption Request
>
>
>
> *WARNING:* This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
>
> Hi shrawan,
>
> looking into the meeting notes I see that this was one of the comments
> that the draft needs to be more mature.
>
> But there were also comments going along that the Cause Values/Reason
> Header existing are proper enough.
>
>
>
> I have some problems with adopting a draft for transfer failures while we
> have the history info header which may also contain such information where
> and why the call was broken.
>
>
>
> Did you have discussed such alternative in 3GPP.
>
>
>
> Thank you and Best Regards
>
>
>
> Roland
>
>
>
> *Von:* sipcore <[e-mail]> *Im Auftrag von *Shrawan Khatri
> *Gesendet:* Mittwoch, 31. Mai 2023 21:31
> *An:* Brian Rosen <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; Lena Chaponniere <
> [e-mail]>
> *Betreff:* Re: [sipcore] WG adoption Request
>
>
>
> Hi Brian,
>
> A related proposal was submitted in 3GPP CT WG1 (see C1-221242
> <https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_134e/Docs/C1-221242.zip>)
> but the feedback was that the group preferred the draft to be adopted by
> the SIPCore WG before being referenced in 3GPP specifications.
>
>
>
> Regards,
>
> Shrawan
>
>
>
>
>
> *From:* Brian Rosen <[e-mail]>
> *Sent:* Wednesday, May 31, 2023 11:24 AM
> *To:* Shrawan Khatri <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; Lena Chaponniere <
> [e-mail]>
> *Subject:* Re: WG adoption Request
>
>
>
> *WARNING:* This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
>
> Answering my own question:
>
>
>
> 3GPP Dependencies on IETF Drafts
> <https://whatthespec.net/3gpp/ietfdependencies.php>
>
> whatthespec.net <https://whatthespec.net/3gpp/ietfdependencies.php>
>
> [image: favicon.ico] <https://whatthespec.net/3gpp/ietfdependencies.php>
>
>
>
> Doesn't list it.
>
>
>
> Could some of the other 3GPP sip folks please comment on whether is likely
> to be added to the dependency list?
>
>
>
> Brian
>
>
>
>
>
> On May 31, 2023, at 1:44 PM, Brian Rosen <[e-mail]> wrote:
>
>
>
> Is this draft on the IETF-3GPP tracking list?
>
> On May 31, 2023, at 1:37 PM, Shrawan Khatri <[e-mail]>
> wrote:
>
> 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
>
>
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>