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

Christer,

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

IIUC, you are asking if Path can be used with a new parameter without 
any further standards action. Is that right?

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.

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.

	Thanks,
	Paul

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