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

Christer Holmberg <> Fri, 17 September 2010 13:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA0723A695B for <>; Fri, 17 Sep 2010 06:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.701
X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XxASaR4lJMTR for <>; Fri, 17 Sep 2010 06:18:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4192E3A6956 for <>; Fri, 17 Sep 2010 06:18:55 -0700 (PDT)
X-AuditID: c1b4fb39-b7b0bae000000f9a-e3-4c936ad64736
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 70.95.03994.6DA639C4; Fri, 17 Sep 2010 15:19:18 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Fri, 17 Sep 2010 15:19:18 +0200
From: Christer Holmberg <>
To: Paul Kyzivat <>
Date: Fri, 17 Sep 2010 15:19:18 +0200
Thread-Topic: [sipcore] Feature-tags in the Path header field
Thread-Index: ActWaLRy68U4RXwOQg+4umNtJtiohQAAM9IA
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 13:18:56 -0000


>Didn't somebody else already bring this up a few months ago?

In that case I missed it :)

>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.

Whether it would require some standards actions needs to be checked.

>If I go back to the definition of Path in 3327, I find that 
>it allows multiple parameters of type "rr-param". It doesn't 
>define rr-param, but does say the Path header field values 
>must conform to the syntax of the Path element from 3261, 
>which defines rr-param as generic-param.
>So *syntactically* you can put whatever parameters you want 
>in there, and sip parsers should not be troubled. But 
>legalistically, new parameters can only be introduced via 
>standards action.


>From a pure syntax perspective it is not a problem.

But, for Contact, A-C, R-C and Refer-To we have defined "feature-param", which in this case would be an explicit usage of "rr-param".

>I suspect the problem 3gpp is trying to address may be of 
>more general interest. But its hard to decipher from your 
>brief description. Can you provide a more complete 
>description of the problem and the proposed solution? For 
>instance, diagrams of the signaling and media paths before 
>and after the handoff of the call.

Well, I was trying to keep the handover description as short as possible, because the intention was not to discuss it. But, for sure I can provide references if people want to read the details.

The idea was to provide some background information to show that there is a problem, to avoid questions like "You have a solution - where is the problem?" :)

I do, however, agree that the possibility to provide proxy features may be of more general interest, and that is also one reason I raised this issue on 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
> >
> >