Re: [sipcore] Feature-tags in the Path header field

Christer Holmberg <> Fri, 17 September 2010 15:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 011163A63CB for <>; Fri, 17 Sep 2010 08:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.714
X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[AWL=0.885, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2mtI+QSrS+Ki for <>; Fri, 17 Sep 2010 08:39:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A243D3A67F7 for <>; Fri, 17 Sep 2010 08:39:47 -0700 (PDT)
X-AuditID: c1b4fb3d-b7cbeae00000772f-b4-4c938bdb34f8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B2.D5.30511.BDB839C4; Fri, 17 Sep 2010 17:40:11 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Fri, 17 Sep 2010 17:40:11 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>
Date: Fri, 17 Sep 2010 17:40:10 +0200
Thread-Topic: [sipcore] Feature-tags in the Path header field
Thread-Index: ActWbRvWE/vHRsJtRFKoEjfOlt+q+AAEA3tC
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [sipcore] Feature-tags in the Path header field
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Sep 2010 15:39:50 -0000


>>>IIUC, you are asking if Path can be used with a new parameter
>>>without any further standards action. Is that right?
>>At this point I am asking about the usage of feature tags to indicate proxy features in general.
>Oh. I guess I missed the point.
>But when feature tags are passed, it is as header parameters.
>They have been explicitly defined to be allowed on Contact.
>Every header is different in terms of what parameters it permits.

Feature tags as such are not defined for Contact, or only for UA capabilities.

RFC 3840 defines the feature-param parameter for Contact, A-C and R-C.

RFC 4508 defines feature-param for Refer-To.

So, if the idea of carrying feature tags in Path is ok as such, I guess one option would be an RFC which defines feature-param for Path (similar to what 4508 does for Refer-To).

So, the extended Path ABNF may look something like:

Path = "Path" HCOLON path-value *( COMMA path-value )

path-value = name-addr *( SEMI rr-param / feature-param )

(Assuming feature-param fits within the syntax for rr-param)

>The fact that a parameter is defined for use on one header does not automatically usable with any other header. (Unless the two headers
>share some common definition. For instance, if the definition of rr-param was extended for Route then I believe Path would automatically
>pick that up as well.)

I agree, and that's why I sent the e-mail to the list :)



>> On 9/17/2010 7:17 AM, Christer Holmberg wrote:
>>> Hi,
>>> Introduction:
>>> -----------------
>>> 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.
>>> Problem:
>>> ------------
>>> 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 Regards, Christer
>>> _______________________________________________
>>> sipcore mailing list