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

[Christer Holmberg <[e-mail]>]

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

That might have been the use-cases we were aware of when writing 3840/3841, but there is nothing in the general feature tag defintion that makes that limitation.

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

On a high level, it's about indicating support of a capability to other entities.

But, as the draft also says, each feature specification has to define the usage of the feature tag, and what indicating support of the capability really means - in the same way when a UA indicates support of a capability (except for the purpose of making forking decissions, when nobody really needs to know the semantics of the feature tag).

It is also true that R-R only applies to the dialog, but I don't think it's explicitly forbidden to use information received from a dialog in other dialogs. 

But, the scope of a feature tag needs to be described in the feature tag definition.

>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?

Again, that needs to be described in the feature tag definition.

>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.

You need to define in which header fields the feature tag has a meaning, and what that meaning is.

>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.

Yes, and you would need to define that the feature tag only has meaning when present in a Path header field.

Take the "ob" parameter as an example. It's inserted in the Path header field. It may therefore be copied into the Route header fields, but it doesn't (AFAIR) really have any meaning there.

Take the Contact header field as an example. When you register the UA with the registrar, you may include features tags indicating capabilities that your support. The registrar will them insert them into the R-URI of an incoming INVITE, but they don't really have any meaning there. There are only there because the registrar copies the Contact into the R-URI. And, they are going to be there during the whole dialog, eventhough they won't be used for anything.

It's part of the SIP design that sometimes we copy paste things from one header field to another, eventhough all information as such might not be needed. We need to define what meaning, if any, the information has in specific header fields and situations.

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

The general model is pretty much the same as for UAs - indicating support of a capability - eventhough I agree that you need to consider more things (e.g. the meaning in different header fields) when defining the usage by a proxy. I try to explain that in the draft.

>> 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.

And that's why we have different review procedures etc to handle that. 3GPP is also looking for existing mechanisms first.

>>> (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.

I agree. It doesn't really indicate support of a feature, unless you would define it as "the capability to be globally reachable".

BUT, it's still one of the most used feature tags in SIP :)

>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.

Exactly.

Regards,

Christer