Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported

["Worley, Dale R (Dale)" <[e-mail]>]

________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Cullen Jennings [[e-mail]]

But given this would be used by a B2BUA, I don't see why you need anything more than just normal option tags. Say a SIP message comes from A to B to C and now the response is coming back. C says it supports feature c1, c2, and c3. B knows that it can transparently forward on whatever is needed for c1, c2, but not c3 and it knows that in additional to this it can do features b4 and b5. It modifies the Supported header to have c1,c2,b4, and b5. and sends that back to A.
_______________________________________________

The use cases seem to revolve around the dialog passing through a chain of quasi-proxies, where one quasi-proxy needs to know if it should perform a particular function, or if it can delegate performing the function to a downstream quasi-proxy.  (A quasi-proxy is an element that generally acts like a proxy, but at times performs actions that a proxy is forbidden to perform.)

The "feature tags" seem to be envisioned to be from the same namespace as caller-preference feature tags, but to describe entirely independent features.  So it's not entirely clear why that particular namespace is chosen as the features aren't intended to be UA features.

I think Cullen's suggestion is a good one.  If quasi-proxy C implements a feature, it can insert "Supported: feature-foo" into the response to an INVITE.  Then quasi-proxy B can see that it can delegate feature-foo actions downstream.  B doesn't need to know *which* downstream quasi-proxy will implement the feature.

Dale