--- 1/draft-ietf-sipcore-proxy-feature-reqs-00.txt 2011-09-09 14:16:31.000000000 +0200 +++ 2/draft-ietf-sipcore-proxy-feature-reqs-01.txt 2011-09-09 14:16:31.000000000 +0200 @@ -1,18 +1,18 @@ SIPCORE Working Group C. Holmberg Internet-Draft I. Sedlacek Intended status: Standards Track Ericsson -Expires: December 22, 2011 June 20, 2011 +Expires: March 12, 2012 September 9, 2011 Requirements for indication of features supported by a SIP proxy - draft-ietf-sipcore-proxy-feature-reqs-00.txt + draft-ietf-sipcore-proxy-feature-reqs-01.txt Abstract 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. This document defines requirements for a mechanism that would allow SIP proxies to convey information relating to the proxy's supported features/capabilities. @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 22, 2011. + This Internet-Draft will expire on March 12, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,38 +58,38 @@ discovery . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Use-case: IMS Enhanced Service Continuity, identifying sessions subject to handover . . . . . . . 4 1.3. Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Session Initiation Protocol (SIP) "Caller Preferences" extension defined in RFC 3840 [RFC3840] provides a mechanism that allows a SIP message to convey information relating to the originator's supported features/capabilities. - It can be useful for other SIP entities indicate supported feature/ - capabilities, that might trigger actions and enable functions in by + 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 relating to the proxy's supported + SIP proxies to convey information related to the proxy's supported features/capabilities. 1.1. Use-case: IMS Service Continuity, handover of session in alerting state The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for handover of Packet Switched (PS) sessions to Circuit Switched (CS) calls. @@ -111,54 +111,58 @@ 1.2. Use-case: IMS Enhanced Service Continuity The 3rd Generation Partnership Project (3GPP) defines a IP Multimedia Subsystem (IMS) Service Continuity mechanism [3GPP.23.237] for handover of Packet Switched (PS) sessions to Circuit Switched (CS) calls. The handover can be performed by a Service Centralization and Continuity Application Server (SCC AS), or by a SCC AS together with an Access Transfer Control Function (ATCF), that acts as a SIP proxy. Delegating part of the session handover functionality to an ATCF provides advantages related to voice interruption during session - handover etc, since it is located in the same network as the user. + handover etc, since the ATCF is located in the same network as the + user. 1.2.1. Use-case: IMS Enhanced Service Continuity, ATCF discovery - In order for a SCC AS to delegate part of the session handover - functionality to an ATCF, when it receives a SIP REGISTER request, it - needs to be informed whether there is a proxy that provides ATCF - functionality in the registration path. + 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. 1.2.2. Use-case: IMS Enhanced Service Continuity, identifying sessions subject to handover In order for ATCF to perform the delegated part of the session - handover functionality, ATCF needs to know which sessions are subject - to handover as decided by SCC AS. + 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. 1.3. Use-case: IMS Inter-UE Transfer The 3rd Generation Partnership Project (3GPP) defines inter-UE transfer enhancements [3GPP.24.837] 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 another SCC AS (i.e. SCC AS of the - controller UE) is already in the signalling path. + 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. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -176,77 +180,102 @@ 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. + meaning of, the feature/capability, or even support the proxy + feature/capability indication mechanism as a whole. - REQ-5: It MUST be possible to indicate whether indicated support of a + 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, to all dialogs created within a session, or to dialogs - associated with other sessions. + 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-6: It MUST be possible to assign additional parameter (either as + 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-7: If a SIP entity receives a feature support indication that it + REQ-8: If a SIP entity receives a feature support indication that it does not understand, it MUST act as if it hadn't received the indication. - REQ-8: Other SIP entities MUST be able to make routing decisions + 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: Other SIP entities MUST be able to make routing decisions based on received feature/capability support indications. - REQ-9: A feature/capability support indicator MUST only be used to + 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-10: A procedure for registering feature/capability indication + REQ-12: A procedure for registering feature/capability indication values with IANA MUST be defined. 4. Security Considerations 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. 5. IANA Considerations None identified. 6. Acknowledgements Thanks to Paul Kyzivat and Robert Sparks for their comments and - guidance on the mailing list. + 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 Robert Sparks, Adam Roach and Paul Kyzivat for giving working procedure guidance. 7. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] - Changes from draft-ietf-sipcore-proxy-feature-reqs-xx o Add text + Changes from draft-ietf-sipcore-proxy-feature-reqs-00 + o New REQ-5 added (IETF#81). + o New REQ-9 added (Dale Worley). + o 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). + o Usage of "session establishment transactions" terminology in + REQ-6, in order to avoid misunderstanding of "session" (Dale + Worley). + o Editorial correction in REQ-7: "additional parameter"->"additional + parameters" + o Editorial clarifications to use-cases. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References