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

[Hadriel Kaplan <[e-mail]>]

Part of me feels like this makes a lot of sense, because indicating proxy capabilities in a Path/Rec-route is similar to Contact, and it would be nice to be able to indicate some capabilities.  

The other part of me thinks "what the heck capabilities can a *PROXY* possibly have"?  A B2BUA would have lots, sure.  But not a real Proxy.  (and frankly every 3GPP "proxy" is a B2BUA in all but name)  So if we're talking about B2BUA's indicating capabilities, I've got some comments but I'll send them separately.

But for this service continuity use in particular: I don't know why 3gpp's bothering to go this route - the ATCF/P-CSCF/whatever is a B2BUA.  It can change the Contact, so have it insert the feature tag in the Contact of the REGISTER, and delete it in the response.  Problem solved.

-hadriel


On Sep 27, 2010, at 10:46 AM, Paul Kyzivat wrote:

> [as chair]
> 
> To all sipcore participants:
> 
> Christer has been looking for a way to accomplish a particular function 
> that 3gpp wants. This proposal seems a plausible way to do that. But it 
> is of necessity defining a more general mechanism.
> 
> I'd really appreciate comments from others (including people in no way 
> involved with 3gpp) regarding this mechanism. For instance, do you 
> consider the semantics to be well defined? Do you see need for more 
> about security implications?
> 
> How many would find this useful to have?
> 
> 	Thanks,
> 	Paul
>