Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature

[Paul Kyzivat <[e-mail]>]

On 1/27/2011 12:40 PM, Christer Holmberg wrote:
>
> Hi,
>
>>>> Another hurdle you're going to face is harmonizing your
>>>> proposal with RFC 5897. All three of your examples rely on doing, just about as
>>>> vigorously as possible, precisely what RFC 5897 says not to do.
>>>
>>> Feature tags indicate support of a capability. EVERY
>>> feature tag does that - even if inserted in a Contact header
>>> field by a UA - and the feature tag specification needs to
>>> define the meaning of that capability.
>>>
>>> The important thing is that it cannot be assumed that other
>>> entities understand the meaning of the feature tag in order
>>> to progress a call (in such cases you will also need an
>>> option-tag, inserted in a Require/Proxy-Require header field).
>>>
>>> There was also an extended discussion (battle?), around the
>>> time the callerprefs came out, about the validity of using
>>> feature-tags (capabilities) to identify arbitrary *services* where the
>>> service was to be defined in some external, potentially
>>> restricted document.
>
> 3GPP specifications are as external as IETF RFCs.
>
> It is also important to remember that the proposed work is not about specifying specific feature tags, but a generic mechanism to carry proxy-inserted feature tags.

What I'm still missing is a generic definition of what it means for an 
intermediary in sip signaling (especially a proxy) to have capabilities.

With 3840/3841 I have a general understanding that:
- I can use callerprefs to suggest policies for getting my request
   to a UAS that has the stated capabilities
- that I can use fairly obvious sip signaling to make use of the
   capabilities. (E.g. if the video feature tag is present then I can
   expect that video lines in my offers will at least be understood.)

I'm not getting that level of understanding with this proposal yet. What 
I understand is that a server wanting to announce a capability is 
expected to put the feature tag on its record-route entry. I don't know 
if that is intended to convey information to the UAC or the UAS, or to 
other intermediaries on one side or the other (or both) in the 
transaction? And are these intended to apply for the dialog being 
established, or more broadly? (R-R only applies to the dialog.)

Nor do I understand *how* such features would be invoked? Again, is this 
*within* the dialog? Or is this through a new dialog or a transaction 
outside a dialog?

For instance, I suppose that if the feature were attached to an entry in 
a Service-Route header, then it would be copied into a Route header for 
requests outside an existing dialog, and them *maybe* the UAC could 
infer that something specific might happen to those requests. But that 
is strange to me - I expect that Route headers are used to steer a 
request through a sequence of proxies before getting to a particular 
destination. But I don't expect those proxies to do anything except 
ensure that the request actually reaches the R-URI and then works in 
accord with the request I sent for the UAS.

If the feature was attached to an entry in a Path header, then the same 
considerations might apply but from the perspective of the "proxy" 
associated with the registrar. These would become Route headers on 
requests outbound from it.

While there are certainly feature-specific things to be said, the 
general model of what is going on is still not clear to me.

> I have no problem to include a statement saying that feature tags specifications that use the mechanism MUST be publicly available.
>
>> The crux of the argument was whether capabilities were
>> orthogonal to one another or not. The concern was (and
>> remains) that interoperability is severely limited if there
>> are potentially many ways of specifying the same capability,
>> as part of this service or that service.
>
> Yes, but that relates to most things we do.

And its something we must constantly be mindful of.

>> (IIRC, one of the examples used was video calling, where
>> somebody might describe a capability "video-phone" that
>> implies a particular combination of audio and video. Two UAs
>> that supported this might work well together, but somebody
>> with a UA that supports exactly the same media types and
>> *could* interoperate if connected, might fail to interoperate
>> for lack of specifying the proper feature-tag.)
>>
>> We run a risk of going through the same thing here. That is
>> what 5897 was about too.
>
> The procedures associated with the 3GPP feature tags are very well documented, rather than being something general as "audio" and "video".
>
> And, take sip.instance as an example. It is useless unless entities support procedures associated with it. But, if UA_A inserts sip.instance, and UE_B does not support it, they will still be able to communicate. But, if they want to use features associated with the feature tag, they need to support the procedures defined for that feature. There is nothing in the "SIP signalling" that tells the entities what to do, if the sip.instance e.g. is going to be used outside the dialog (e.g in a REFER request).

sip.instance may have been a mistake. It makes sense as a Contact header 
parameter, but whether it is truly a capability/feature is a bit shaky. 
Even so, its not an "outbound" feature, and its inclusion does not mean 
that you want outbound functionality. It merely says "this is who I am" 
and thus can be used for many things.

	Thanks,
	Paul