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

Comments inline.

	Thanks,
	Paul

On 9/17/2010 9:19 AM, Christer Holmberg wrote:
>
> Hi,
>
>> Didn't somebody else already bring this up a few months ago?
>
> In that case I missed it :)

Maybe I have it mixed up with something else. Had to do with media 
capabilities out at the edge upstream of the UA.

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

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

> 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",

Yes.

> which in this case would be an explicit usage of "rr-param".

I don't follow your logic. How does definition of feature-param for the 
headers that have it relate in any way to 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'm glad to hear that!

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