Re: [sipcore] WG adoption Request

Brian Rosen <> Wed, 31 May 2023 17:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 540F9C151070 for <>; Wed, 31 May 2023 10:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sc12UfpMoB8b for <>; Wed, 31 May 2023 10:44:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2c]) (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 21D97C14CEFA for <>; Wed, 31 May 2023 10:44:42 -0700 (PDT)
Received: by with SMTP id 3f1490d57ef6-bacf50c5c33so925717276.1 for <>; Wed, 31 May 2023 10:44:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1685555081; x=1688147081; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QK+mcL00QinU6oz16vU9pjPqCleQU90+YhPwnu8Nm8E=; b=RvG39rE+nsvTxMKGbyHhAGCXhPVokIQ+ewANRektiUxU+Sh5nvRAzSbB4tVy7n426p Y/Dgv6SOgsbbsl3lBq1OXe/FqcilZmxcrFVZ1bZZxy3DEsabsrbHwAy245fDwn/gYQ49 sDKrjwQMVYM7/VQ+fM4kCLwxeaHM26M5kfbzM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1685555081; x=1688147081; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QK+mcL00QinU6oz16vU9pjPqCleQU90+YhPwnu8Nm8E=; b=YMRkuHsVj/XJ6XAVgs8auSumq/KzTOxJdQz5zKYYfmcnUqgvNLPN0SJ8viqE9aFvr9 9JZPLBad9rhoA+QzpNc4nrKoXp6iG5yxAthnZxjU5rlYtlJP3zFqQCh+xdRTFcTj5tGC Xw/umEZWJjxhv2C7VuGpOY+2DIv1pgksTpHYT3GRNIRkH10np3hR832xUmE15yxb2cxo UeUzh+SVpgRy0uEzsvjIfYwXwiLiyDxu/nNrn8GL6l97rEujaPJxFbd9BCJ/UsISW8Ky LIz5Qv9HVbmcUWIB8OaTxumMvwDdeabEX/nBLBfqLSc26+a5tf4JrtsZmW/9b54qHaQT sZhw==
X-Gm-Message-State: AC+VfDwjGjcz2BCjuqNqsbnnoTSS53zcEfUyUKtotjqTohlnTBv8NmrU lMhwlxQr3LBKV7ttiNeN2hgiwA==
X-Google-Smtp-Source: ACHHUZ40CJHODsrDj+DzCBxySDOnSC91+uqqrY4Q26xC6Qn9KGevpoRInB09mGWVzI4Y4VfqfzBMjQ==
X-Received: by 2002:a25:2d27:0:b0:ba7:5d7a:54f2 with SMTP id t39-20020a252d27000000b00ba75d7a54f2mr2823999ybt.0.1685555081280; Wed, 31 May 2023 10:44:41 -0700 (PDT)
Received: from ( []) by with ESMTPSA id x204-20020a0dd5d5000000b0055a92559260sm4822857ywd.34.2023. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2023 10:44:40 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
From: Brian Rosen <>
In-Reply-To: <>
Date: Wed, 31 May 2023 13:44:28 -0400
Cc: "" <>, "" <>, Lena Chaponniere <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Shrawan Khatri <>
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 17:44:46 -0000

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