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

[Christer Holmberg <[e-mail]>]

Hi,

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

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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>