Requirements for indication of features supported by a SIP proxy

The Session Initiation Protocol (SIP) "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP message to convey information relating to the originator's supported features/capabilities. It can be useful for SIP proxies to indicate supported feature/capabilities, that might trigger actions and enable functions in other SIP entities. This document defines requirements for a mechanism that would allow SIP proxies to convey information related to the proxy's supported features/capabilities.

The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia Subsystem (IMS) Service Continuity mechanism for handover of Packet Switched (PS) sessions to Circuit Switched (CS) calls. The handover is controlled by a Service Centralization and Continuity Application Server (SCC AS). When a session is established the User Equipment (UE) needs to determine whether SCC AS in signalling path of the session supports handover of session in alerting state (i.e. 180 Ringing response has already been sent or received but the dialog is not confirmed dialog yet) or not. When handover occurs and a session in alerting state exists and both UE and SCC AS indicated support of the handover of session in alerting state, then the UE and SCC AS perform handover for the session in alerting state. NOTE: The UE indicates the support of the handover of session in alerting state by the feature tag included in Contact header field.

In order for an SCC AS to delegate part of the session handover functionality to an ATCF, when the SCC AS is informed by the registrar about an accepted REGISTER transaction, the SCC AS needs to determine whether a proxy supporting the ATCF functionality is in the registration path.

In order for ATCF to perform the delegated part of the session handover functionality, when a session is set up, the ATCF needs to determine whether a SIP proxy supporting the SCC AS functionality is in the signalling path of the session.

As the session handover functionality has been specified over several 3GPP releases, some subfeatures of the handover functionality are optional. Examples are: - The handover of sessions with audio on hold (called the MSC server assisted mid-call feature); and - The handover of sessions where a 180 Ringing response to the initial SIP INVITE request has already been sent or received but a final response has not been sent or received yet (called the SRVCC for calls in alerting phase). The SCC AS needs to be aware of support of those subfeatures in ATCF, in order for the UE and the SCC AS to execute the correct handling when the handover occurs. When ATCF receives a SIP REGISTER request, the ATCF indicates the support of those subfeatures along the indication of ATCF functionality. When SCC AS is informed about the new/updated binding where a proxy indicated support of ATCF functionality along with support of those subfeatures, the SCC AS discovers the support of those subfeatures in the ATCF.

The 3rd Generation Partnership Project (3GPP) defines inter-UE transfer enhancements which enhance delivery of media of a session to several User Equipments (UE). The Service Centralization and Continuity Application Server (SCC AS) serving one of the UEs acts as local hub for the session. The UE controls the media of the session and is called controller UE. Triggered by requests from the controller UE, the SCC AS serving the controller UE transfers media of the session to other UEs, called controlee UEs, by sending INVITE request offering the media to be transferred. When an INVITE request is routed to the UE, the SCC AS serving the UE needs to determine whether a SIP proxy supporting the inter-UE transfer enhancements functionality (i.e. SCC AS of the controller UE) is already in the signalling path. If so, the SCC AS proxies the signalling without further handling as there is already an existing local hub for the session. If not, the SCC AS acts as local hub for the session.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 .

REQ-1: It MUST be possible for a SIP proxy to indicate, and convey to other SIP entities in the signalling path of a registration request, support of a particular feature/capability. REQ-2: It MUST be possible for a SIP proxy to indicate, and convey to other SIP entities in the signalling path of a dialog-forming request, support of a particular feature/capability. REQ-3: It MUST be possible for a SIP proxy to indicate that the indicated support of a feature/capability only applies to other SIP entities in the direction towards one of the SIP endpoints in the signalling path. REQ-4: A SIP proxy MUST NOT, when indicating support of a feature/capability, make any assumptions that SIP entities in the signalling path that receive the indicator will support, or understand the meaning of, the feature/capability, or even support the proxy feature/capability indication mechanism as a whole. REQ-5: A SIP proxy MUST be able to indicate support of a feature/capability to other SIP entities in the signaling path, even if some SIP entities in the signaling path (possibly including the UAC and/or UAS) do not support, or understand the meaning of, the feature/capability, or even support the proxy feature/capability indication mechanism as a whole. REQ-6: It MUST be possible to indicate whether indicated support of a feature/capability applies to specific registration, to a specific dialog, or to all dialogs created as part of INVITE transaction. NOTE: This requirement might be fully implemented as part of the protocol mechanism, or parts might be left to be specified in a feature/capability specification, or it might be left to be specified in a feature/capability specification completely. REQ-7: It MUST be possible to assign additional parameters (either as a single value, or a list of values) to a feature/capability indicator, in order to provide additional information about the feature/capability. REQ-8: If a SIP entity that supports the proxy feature/capability indication mechanism receives a feature support indication that it does not understand, it MUST act as if it hadn't received the indication. REQ-9: If a SIP entity that does not support the proxy feature/capability indication mechanism receives a feature support indication, it MUST act as if it hadn't received the indication. REQ-10: SIP entities on the path of the SIP message MUST be able to inspect the feature/capability support indicators introduced by other entities. REQ-11: A feature/capability support indicator MUST only be used to indicate support of a feature/capability, and MUST NOT be used to indicate whether procedures associated with the feature/capability have been applied or not. REQ-12: It MUST be possible to determine which features/capabilities are supported by the same proxy. REQ-13: A SIP proxy that indicates support of a feature/capability associated with a dialog MUST take the necessary steps to ensure it is part of the signaling path of the remainder that dialog, by indicating the support of the feature/capability as part of a dialog forming transaction, or as part of a target refresh request within a dialog. REQ-14: A procedure for registering feature/capability indication values, which prevents name collisions of indicators, with IANA MUST be defined.

Feature/capability support indications can provide sensitive information about a SIP entity. RFC 3840 cautions against providing sensitive information to another party. Once this information is given out, any use may be made of it.

None identified.

Thanks to Paul Kyzivat and Robert Sparks for their comments and guidance on the mailing list. Thanks to Andrew Allen and Dale Worley for providing text on additional use-cases. Thanks to Cullen Jennings for providing text on additional requirements. Thanks to Dale Worley for providing comments and text improvement suggestions. Thanks to Hadriel Kaplan for telling us how SBCs mess up the mechanisms we try to specify. Thanks to Robert Sparks, Adam Roach and Paul Kyzivat for giving working procedure guidance.

[RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-sipcore-proxy-feature-reqs-02 Changes based on comments from Robert Sparks at IETF#82 (http://www.ietf.org/mail-archive/web/sipcore/current/msg04473.html). REQ-10: now talks about having access to the information, rather than talking specifically about making routing decisions. REQ-8: editorial modification, to better distinguish it from REQ-9. New REQ-13 (old REQ-13 becomes REQ-14) added. REQ-14: indication that the IANA registration procedure will prevent name collision between feature indications. Changes from draft-ietf-sipcore-proxy-feature-reqs-01 New REQ-12 added (old REQ-12 becomes REQ-13). New use-case added (section 1.2.3). Changes from draft-ietf-sipcore-proxy-feature-reqs-00 New REQ-5 added (IETF#81). New REQ-9 added (Dale Worley). Text added to REQ-4 and REQ-5, indicating that the requirement applies also in cases where an entity does not support the mechanism as a whole (Dale Worley). Usage of "session establishment transactions" terminology in REQ-6, in order to avoid misunderstanding of "session" (Dale Worley). Editorial correction in REQ-7: "additional parameter"->"additional parameters" Editorial clarifications to use-cases.