[sipcore] Feature-tags in the Path header field

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 17 September 2010 11:17 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 37C4C3A6B49 for <sipcore@core3.amsl.com>; Fri, 17 Sep 2010 04:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.686
X-Spam-Status: No, score=-5.686 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id StN7qmZV2lTW for <sipcore@core3.amsl.com>; Fri, 17 Sep 2010 04:17:06 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net []) by core3.amsl.com (Postfix) with ESMTP id 80E603A6BB0 for <sipcore@ietf.org>; Fri, 17 Sep 2010 04:17:05 -0700 (PDT)
X-AuditID: c1b4fb3d-b7cbeae00000772f-52-4c934e495184
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain []) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D0.B6.30511.94E439C4; Fri, 17 Sep 2010 13:17:29 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([]) by esessmw0197.eemea.ericsson.se ([]) with mapi; Fri, 17 Sep 2010 13:17:29 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Fri, 17 Sep 2010 13:17:27 +0200
Thread-Topic: Feature-tags in the Path header field
Thread-Index: ActWWelrjovgmEaZQhukSWxMBgiE2g==
Message-ID: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A058501703422ESESSCMS0356eem_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [sipcore] Feature-tags in the Path header field
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Sep 2010 11:17:07 -0000



3GPP is working on solution which improves the ability to be able to move an ongoing IMS call from an IP based access network to a legacy CS based network without dropping the call.
The solution requires a media anchoring proxy (called ATCF) in the visited network, and a signaling anchoring application server (called SCC AS) in the users home network.


The SCC AS, when it receives a REGISTER request from a UA, needs to know whether there is a proxy with ATCF functionaltiy in the registration path. The reason is that the SCC AS can then choose to delegate session handover functionality to the ATCF, which provides advantages related to voice interruption etc.

Possible solution:

During registration the ATCF inserts a Path header field, so a solution to indicate its support of the ATCF functionlaity would be to insert a feature tag in the Path header field.

However, eventhough there is no syntax issue, the usage of feature tags have only been specified for the Contact, Accept-Contact, Reject-Contact and Refer-To header fields.

So, the question is whether there are any reasons why the proxy could not use a feature tag in the Path header field for this. Entities that don't support the feature will simply see it as an unsupported Path header field parameter, and a registrar doing normal feature tag matching shouldn't even look at the Path header field. And, based on the feature tag definitions in RFC3840 and RFC2703, we don't think the usage is necessarily limited to UAs