Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field)

[Christer Holmberg <[e-mail]>]

Hi,

> Here are comments on the new version.
>
> From the introduction:
>
>    This document defines a new SIP header field, Feature-Caps, that can
>   be used by entities to indicate support of features and capabilities,
>    in case they cannot use the Contact header field for that purpose.
>
> This is really loose!!!
> Its not limited to proxies. It could be any UA that "cannot use the
> Contact header field for that purpose". What constitutes a such a reason?
>
> The Definitions section has a very non-standard definition of Proxy:
>
>    Proxy: Within this specification, a "proxy" refers to an entity that
>   does not indicate supported features using the Contact header field.
>    Normally, however, entities that indicate support of features do not
>    act as pure proxies, as defined by RFC 3261, but rather contain
>    different levels of B2BUAs functionality.
>
> IMO Proxy should be defined only as it is in 3261.

As I said when I submitted the draft, and which Hadriel also indicated, we DO need to sort out the terminology :)

(I think Hadriel even had some proposed alternative wording).


-------------


>Section 4.1 says:
>
>    A UA MUST NOT, except when it acts as a SIP registrar, insert a
>    Feature-Caps header field in a SIP request or response.
>
> By this do you intend that a B2BUA/SBC cannot use this?
>
> Or are you drawing a fine line, where an element nominally acting as a
> proxy inserts this, even if it describes a feature that will require it
> starting to act as a B2BUA in the same dialog?

The issue is not whether the entity is a proxy or a B2BUA, or a registrar.

It's about an entity which is not "represented" by the Contact header field, or an entity which is not allowed (by SIP rules) to use the Contact header field.

And, again, I totally agree that we need to use other wording than "proxy" and "UA", to make that clear :)


-------------


>In section 6.2:
>
>    If a feature tag is inserted in a Feature-Caps header field of an
>    initial SIP request or response for a dialog, the feature associated
>    with the feature tag MUST be supported for the dialog, until the
>    dialog is terminated.
>
> Do you mean that it cannot be changed by subsequent signaling within the
> dialog? If Feature-Caps can be used by a 3pcc (b2bua) controller (can
> it?) then this limitation could break 3pcc transfers, where the
> transfer-target has different features.

The limitation seems to be a left-over from when the draft used Record-Route. 

If needed, for Feature-Caps, we can always specify that entities must include it e.g. also in target refresh requests within a session.


-------------


> Section 8:
>
> Since this is using feature tags, it has to live with the IANA
> registration mechanism defined in 2506. I think that means, at best, you
> can require that certain material be included in the "Related standards
> or documents" that can optionally be included in a feature tag
> registration. That means it won't be possible to discern from a feature
> tag registration whether it applicable for use in Feature-Caps.

I don't know remember whether the references are optional or not, but at least 3GPP has provided them for all feature tags.

But, in general, I still think we can provide guidance and recommendations in the spec on what kind of information needs to be provided in the definition/registration.

Regards,

Christer






On 10/28/11 6:09 AM, Christer Holmberg wrote:
>
> Hi,
>
> I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-feature, which suggests a solution based on the proxy feature requirements.
>
> The MAJOR CHANGE, based on the list discussions, is that the mechanism now uses a new header field, Feature-Caps, rather than existing header fields (Record-Route, Path etc).
>
> I did not include the "SIP-URI alternative" at this point.
>
> We will also have to think about the "proxy" terminology, as it has been indicated that entities using the mechanism might not be pure proxies. But, I don't think that should prevent us from moving forward the the mechanism as such.
>
> Thanks to everyone who has provided feedback and input!
>
> Regards,
>
> Christer
>