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

Hi, 

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

Correct.

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

Regards,

Christer

> 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
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
> 