Re: [sipcore] WG adoption Request

Brian Rosen <> Wed, 31 May 2023 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D1ABC14CE3F for <>; Wed, 31 May 2023 11:24:26 -0700 (PDT)
X-Quarantine-ID: <h05GdBFO1oHi>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BANNED, message contains image/,.image,.png,favicon.ico
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h05GdBFO1oHi for <>; Wed, 31 May 2023 11:24:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 11C7BC15109B for <>; Wed, 31 May 2023 11:24:22 -0700 (PDT)
Received: by with SMTP id 3f1490d57ef6-bac6f8325b5so895243276.0 for <>; Wed, 31 May 2023 11:24:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1685557461; x=1688149461; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=ayXVQgItVFelNnh2eiqx7rUTyacRGc1vX2Ws8avYAnk=; b=HqcU9xvkGyUxgU3HYzFVt4UU0KExotc1EkbX8SRweFrqBq4D6a0wFMTM+YAzGX5f/W bVbNdiCzcpjI7+8RTdpJPvWvy6AsKrYVYZ1C16xN5FnH3tIr5qE2ZoFXAG1G0kZ8XLGY C+fx0a24OV1/A4StqICYzakymRVKz6T3+39Qg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1685557461; x=1688149461; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ayXVQgItVFelNnh2eiqx7rUTyacRGc1vX2Ws8avYAnk=; b=lwwluzxjRYItquhQBCRjtQKrz8hkQ53yUFKEBfnDFxt3C/tjHzFTu0vGWym+gvdP4q 21zdfLxgZNecsTxUi+Vj1rEbqXuHAF7HhYY3as15kyMpqoWl19obeVT+c4Xv2EtehmVw Kllo4XX7znwLruHlc3J80LqU+fLXnYUYeess3BEZDGuBj4iIZHj5X+0cVQddFjwb43oW HLx+YUW6TvrI9YtRMZGmgl2Yrl/NtuZFqsJzAkgbtzyWKEDMoxc0MmcTPXwrT7dSuc7j fJd68NVYUOlhNitRcmTRI7/6JN9Xq5apX39nbLsqlGEIC4YH5kbqjXrDJS5ldI8KtgiJ gksA==
X-Gm-Message-State: AC+VfDyqliFpNff6sX93k0B3fmLxFJLYM9YFaB3KLlzq+XYOrWMs0WBj 1ysY1hNcZW3JUWkp94XpBoB7TQ==
X-Google-Smtp-Source: ACHHUZ4uUt2gGiNAJ7zaYVcgQ8RLGl6pgaaSi5KUWF0u9573xUUoYRuowj8/Wzba4H/4st/eFiuwTA==
X-Received: by 2002:a81:1702:0:b0:561:7d47:8441 with SMTP id 2-20020a811702000000b005617d478441mr3247644ywx.0.1685557461003; Wed, 31 May 2023 11:24:21 -0700 (PDT)
Received: from ( []) by with ESMTPSA id n207-20020a0dcbd8000000b00565eae9cb5asm3538378ywd.130.2023. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2023 11:24:20 -0700 (PDT)
From: Brian Rosen <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_65E1FDB7-F90C-4E46-8C34-137ADDF49E14"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
Date: Wed, 31 May 2023 14:24:09 -0400
In-Reply-To: <>
Cc: "" <>, "" <>, Lena Chaponniere <>
To: Shrawan Khatri <>
References: <> <>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <>
Subject: Re: [sipcore] WG adoption Request
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 May 2023 18:24:26 -0000

Answering my own question:´┐╝
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?


> On May 31, 2023, at 1:44 PM, Brian Rosen <> wrote:
> Is this draft on the IETF-3GPP tracking list?
>> On May 31, 2023, at 1:37 PM, Shrawan Khatri <> 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: 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