SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                               I. Sedlacek
Intended status: Standards Track                                Ericsson
Expires: December 22, 2011                                 June 20, 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.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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. 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
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Use-case: IMS Service Continuity, handover of session
           in alerting state . . . . . . . . . . . . . . . . . . . . . 3
     1.2.  Use-case: IMS Enhanced Service Continuity . . . . . . . . . 3
       1.2.1.  Use-case: IMS Enhanced Service Continuity, ATCF
               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 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6 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 proxies to indicate supported feature/
   capabilities, that might trigger actions and enable functions in by
   other SIP entities.

   This document defines requirements for a mechanism that would allow
   SIP proxies to convey information relating 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.

   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.

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 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 an SCC AS to delegate part of the session handover
   functionality to an ATCF, when it receives a SIP the SCC AS is informed by the
   registrar about an accepted REGISTER request, it transaction, the SCC AS needs to be informed
   determine whether there is a proxy that provides 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, when a session is set up, the ATCF needs to know which sessions are subject
   to handover as decided by
   determine whether a SIP proxy supporting the SCC AS. 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 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
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

3.  Requirements

   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. 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 within a session, or to dialogs
   associated with other sessions. 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:

   REQ-7: It MUST be possible to assign additional parameter 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:

   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:

   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:

   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:

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

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

   [3GPP.23.237]
              3GPP, "IP Multimedia Subsystem (IMS) Service Continuity;
              Stage 2", 3GPP TS 23.237 10.6.0, June 2011.

   [3GPP.24.837]
              3GPP, "IP Multimedia (IM) Core Network (CN) subsystem
              inter-UE transfer enhancements; Stage 3", 3GPP TR 24.837
              10.0.0, April 2011.

Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com

   Ivo Sedlacek
   Ericsson
   Scheelevaegen 19C
   Lund  22363
   Sweden

   Email: ivo.sedlacek@ericsson.com