Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]

[Dean Willis <[e-mail]>]

On Oct 25, 2010, at 1:32 AM, Christer Holmberg wrote:
>>
>>
>> Specifically, Christer has identified a use case where it is  
>> important
>> for other nodes to understand the options supported by a proxy in the
>> registration path, when that proxy is reasonably expected to be on  
>> the
>> request path for future requests using that registration.
>>
>> If, OTOH, we're really talking "feature tags" that refer to vendor-
>> tree specific feature identification -- well, then we're back to the
>> old service-identifier problem.
>
> Actually, the draft DOES talk about feature tags.
>

So you mean "RFC 3840 media feature tags"?

In your model, do they indicate that a particular feature is supported  
by the node, or do they indicate that a particular feature is being  
enforced by the node? Or do they indicate a request for delivery of  
functionality by other nodes -- that is, do they inform other nodes so  
that routing decisions can be made?

The reason I ask is that I think we're talking about a family of  
"features" that are not really consistent with RFC 3840/41 media  
feature tags.

That said, I'm fairly convinced that the whole capability negotiation  
model(s) in SIP is(are) an () ugly hack(s).

--
Dean