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

[Paul Kyzivat <[e-mail]>]

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.

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?

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.

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.

	Thanks,
	Paul


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
>