[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-ietf-sipcore-proxy-feature

SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                               I. Sedlacek
Intended status: Standards Track                                Ericsson
Expires: June 10, 2011                                  December 7, 2010


               Indication of features supported by proxy
              draft-holmberg-sipcore-proxy-feature-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 capabilities.  This
   document makes it possible for SIP proxies to convey similar
   information, by extending the rr-param rule defined in RFC 3261, so
   that the header field parameter can be used to convey feature tags
   that indicate features supported by the proxy.

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 June 10, 2011.

Copyright Notice

   Copyright (c) 2010 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



Holmberg & Sedlacek       Expires June 10, 2011                 [Page 1]

Internet-Draft                proxy feature                December 2010


   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  . . . . . . . . . . . . . 3
     1.2.  Use-case: IMS Enhanced Service Continuity . . . . . . . . . 3
     1.3.  Use-case: IMS Inter-UE Transfer . . . . . . . . . . . . . . 4
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  User Agent behavior . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Proxy behavior  . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Feature tag semantics . . . . . . . . . . . . . . . . . . . . . 5
   7.  Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Example: IMS Service Continuity . . . . . . . . . . . . . . 6
     8.2.  Example: IMS Enhanced Service Continuity  . . . . . . . . . 7
     8.3.  Example: IMS Inter-UE Transfer  . . . . . . . . . . . . . . 7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   10. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   12. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     13.1. Normative References  . . . . . . . . . . . . . . . . . . . 9
     13.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9























Holmberg & Sedlacek       Expires June 10, 2011                 [Page 2]

Internet-Draft                proxy feature                December 2010


1.  Introduction

   The SIP "Caller Preferences" extension defined in RFC 3840 [RFC3840]
   provides a mechanism that allows a SIP message to convey information,
   using feature tags, relating to the originator's capabilities.

   Feature information can be useful for other SIP entities, that might
   trigger actions and enable functions based on features supported by
   other SIP entities.

   This document extends the rr-param rule defined in RFC 3261
   [RFC3261], so that it can be used to convey feature tags indicating
   support of features in SIP proxies.  The rr-param rule is used in the
   SIP Path, Route, Record-Route and Service-Route header fields.

1.1.  Use-case: IMS 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 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 is in signalling
   path of the session or not.

   When handover occurs, the UE and SCC AS perform handover for the
   sessions which contain a SCC AS in the signaling path.  Other
   sessions are not affected.

   Section 8.1 shows an example flow for this use-case.

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.

   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



Holmberg & Sedlacek       Expires June 10, 2011                 [Page 3]

Internet-Draft                proxy feature                December 2010


   functionality in the registration path.

   Section 8.2 shows an example flow for this use-case.

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.

   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.

   Section 8.3 shows an example flow for this use-case.


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

   The rr-param rule defined in RFC 3261 [RFC3261]:

   rr-param = generic-param

   is extended to:

   rr-param = generic-param / feature-param



Holmberg & Sedlacek       Expires June 10, 2011                 [Page 4]

Internet-Draft                proxy feature                December 2010


   where feature-param is defined in Section 9 of RFC 3840 [RFC3840].


4.  User Agent behavior

   This specification does not specify any new User Agent behavior.


5.  Proxy behavior

   When a proxy inserts a Path header field (during registration), a
   Service-Route header field (during registration) or a Record-Route
   header field (during a dialog establishment), it MAY insert a feature
   tag in the header field.

   If a feature tag is inserted in a Path or Service-Route header field
   during registration, the resource identified by the URI in the header
   field MUST provide support for the associated feature for all dialogs
   associated with the registration, until the registration is
   terminated or re-freshed.

   If a feature tag is inserted in a Record-Route header field during a
   dialog establishment, the resource identified by the URI in the
   header field MUST provide support for the associated feature until
   the dialog is terminated.


6.  Feature tag semantics

   The feature tag in a header field constructed using rr-param rule
   indicates support of the feature in the resource identified by the
   URI in the header field.

   In order to insert a feature tag in a SIP header field constructed by
   using rr-param rule, the feature specification MUST specify the
   semantics of the feature tag when inserted in that specific header
   field.  Unless the feature specification defines such semantics, a
   the feature tag MUST NOT be included in that specific header field.

   NOTE: If a route set is built using Path, Record-Route or Service-
   Route header fields, any inserted feature tag will be copied into the
   associated Route header fields, together with other header field
   parameters.  This specification does not define any specific meaning
   of the feature tags present in Route header fields in such cases.







Holmberg & Sedlacek       Expires June 10, 2011                 [Page 5]

Internet-Draft                proxy feature                December 2010


7.  Direction

   When a proxy inserts a feature tag in order to indicate support of a
   capability, the indicated capability might be indicated both towards
   downstream and upstream SIP entities.

   In order to indicate a capability only towards SIP entities in one
   direction, either the feature tag semantics need to be defined in a
   way so that SIP entities know whether the indicated capability
   applies to them or not, or alternatively, the SIP entity that inserts
   the feature tag needs to ensure that the feature tag is only sent
   towards the direction for which the capability applies.


8.  Examples

8.1.  Example: IMS Service Continuity

   Based on the presence of g.3gpp.access-transfer feature tag in a
   Record-Route header field Alice determines that SCC AS serving Alice
   is in signalling path of the session and when hand over occurs, this
   specific session can be handed over.

   NOTE: As P1 only wants to indicate the capability towards Alice, it
   only inserts the feature tag in the Record-Route header field of the
   response sent towards Alice.

   NOTE: The Contact header field of the 200 OK response to the INVITE
   request contains the GRUU of Bob, so it would be inappropriate to
   indicate the SCC AS support of handover feature in the Contact header
   field.

        Alice                    P1 (SCC AS                      Bob
                                   of Alice)
          |                           |                           |
          |--- INVITE---------------->|                           |
          |                           |                           |
          |                           |--- INVITE---------------->|
          |                           |    Record-Route: P1       |
          |                           |                           |
          |                           |                           |
          |                           |<-- 200 OK ----------------|
          |                           |    Record-Route: P1       |
          |                           |                           |
          |<-- 200 OK ----------------|                           |
          |    Record-Route: P1;g.3gpp.access-transfer            |
          |                           |                           |




Holmberg & Sedlacek       Expires June 10, 2011                 [Page 6]

Internet-Draft                proxy feature                December 2010


                        Figure 1: Example call flow

8.2.  Example: IMS Enhanced Service Continuity

   Based on the presence of g.3gpp.atcf feature tag in a Path header
   field the REGISTRAR (and SCC AS invoked by REGISTRAR) determines that
   ATCF is in the path for terminating requests sent to Alice.

   NOTE: The Contact header field of the REGISTER request contains a URI
   at which Alice can be directly reached, so it would be inappropriate
   to indicate the ATCF support of handover feature in the Contact
   header field.

        Alice                        P1 (ATCF)                REGISTRAR
          |                           |                           |
          |--- REGISTER-------------->|                           |
          |                           |                           |
          |                           |--- REGISTER-------------->|
          |                           |    Path: P1;+g.3gpp.atcf  |
          |                           |                           |
          |                           |                           |
          |                           |<-- 200 OK ----------------|
          |                           |    Path: P1;+g.3gpp.atcf  |
          |                           |    Service-Route: REG     |
          |<-- 200 OK ----------------|                           |
          |    Path: P1;+g.3gpp.atcf  |                           |
          |    Service-Route: REG     |                           |
          |                           |                           |


                        Figure 2: Example call flow

8.3.  Example: IMS Inter-UE Transfer

   Based on the presence of g.3gpp.iut-focus feature tag in a Record-
   Route header field the SCC AS serving Cecil determines that the
   session already has a local hub.

   NOTE: The Contact header field of the INVITE request contains the
   GRUU of Bob, so it would be inappropriate to indicate the SCC AS
   support of the handover feature in the Contact header field.










Holmberg & Sedlacek       Expires June 10, 2011                 [Page 7]

Internet-Draft                proxy feature                December 2010


        Alice Cecil          P1 (SCC AS    P2 (SCC AS               Bob
                              of Alice)     of Cecil)
          |     |                 |             |                    |
          | Session of audio and video between Alice and Bob where   |
          | SCC AS of Alice is in signalling path                    |
          |<======================+=================================>|
          |     |                 |             |                    |
          |--move audio to Cecil->|             |                    |
          |     |                 |             |                    |
          |     |                 |-INVITE----> |                    |
          |     |                 | Record-Route: P1;g.3gpp.iut-focus
          |     |                 |             |                    |
          |     |                 |             |                    |
          |     |                 |             |                    |
          |     |<-INVITE-----------------------|                    |
          |     |  Record-Route: P2             |                    |
          |     |  Record-Route: P1;g.3gpp.iut-focus                 |
          |     |                 |             |                    |
          |     |                 |             |                    |
          |     |                 |             |                    |
          |     |                 |             |                    |
          |     |                 |             |                    |
          |     |                 |             |                    |
          |     |                 |             |                    |


                        Figure 3: Example call flow


9.  IANA Considerations

   TBD


10.  Security Considerations

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


11.  Acknowledgements

   Thanks to Paul Kyzivat for his comments and guidance on the mailing
   list.





Holmberg & Sedlacek       Expires June 10, 2011                 [Page 8]

Internet-Draft                proxy feature                December 2010


12.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]

   Changes from draft-holmberg-sipcore-proxy-feature-00
   o  Additional use-cases added
   o  Direction section added


13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

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

13.2.  Informative References

   [3GPP.23.237]
              3GPP, "IP Multimedia Subsystem (IMS) Service Continuity;
              Stage 2", 3GPP TS 23.237 10.3.0, September 2010.

   [3GPP.24.837]
              3GPP, "IP Multimedia Subsystem (IMS) SCC Inter UE Transfer
              Extensions; Stage 3", 3GPP TR 24.837 0.4.0, October 2010.


Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com






Holmberg & Sedlacek       Expires June 10, 2011                 [Page 9]

Internet-Draft                proxy feature                December 2010


   Ivo Sedlacek
   Ericsson
   Scheelevaegen 19C
   Lund  22363
   Sweden

   Email: ivo.sedlacek@ericsson.com












































Holmberg & Sedlacek       Expires June 10, 2011                [Page 10]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/