[Docs] [txt|pdf|xml] [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: April 30, 2012                                 October 28, 2011


               Indication of features supported by proxy
              draft-holmberg-sipcore-proxy-feature-03.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 features and
   capabilities.  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.

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 April 30, 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



Holmberg & Sedlacek      Expires April 30, 2012                 [Page 1]

Internet-Draft                proxy feature                 October 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  User Agent (UA) Behavior  . . . . . . . . . . . . . . . . . . . 3
     4.1.  General . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     4.2.  Registrar Behavior  . . . . . . . . . . . . . . . . . . . . 4
   5.  Proxy behavior  . . . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Feature-Caps Header Field Definition  . . . . . . . . . . . . . 5
     6.1.  General . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.2.  SIP Dialog  . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.3.  SIP Registration (REGISTER) . . . . . . . . . . . . . . . . 5
     6.4.  SIP Stand-Alone Transactions  . . . . . . . . . . . . . . . 5
     6.5.  SIP Capability Query (OPTIONS)  . . . . . . . . . . . . . . 6
   7.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  General . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Feature Tag Usage With Feature-Caps . . . . . . . . . . . . . . 6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   12. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     13.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     13.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8




















Holmberg & Sedlacek      Expires April 30, 2012                 [Page 2]

Internet-Draft                proxy feature                 October 2011


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 features
   and capabilities.

   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.


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

   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.

   Downstream SIP entity: SIP entity in the direction towards which a
   SIP request is sent.

   Upstream SIP entity: SIP entity in the direction from which a SIP
   request is received.


4.  User Agent (UA) Behavior

4.1.  General

   A UA MUST NOT, except when it acts as a SIP registrar, insert a
   Feature-Caps header field in a SIP request or response.

   NOTE: Feature-caps header field values of a request are not copied to
   the associated responses.

   When a UA receives a SIP request, or response, that contains one or
   more Feature-Caps header fields, the feature tags in the header field
   inform the UA is about the features supported by the proxies that



Holmberg & Sedlacek      Expires April 30, 2012                 [Page 3]

Internet-Draft                proxy feature                 October 2011


   inserted the header fields.  Procedures how features are invoked are
   outside the scope of this specification, and MUST be described by
   individual feature tag specifications.

   When the UA receives the SIP request or the response, the feature
   tags in the topmost Feature-Caps header field will represent the
   supported features "closest" to the UA.

4.2.  Registrar Behavior

   If a SIP registrar wants to indicate support of features towards its
   upstream SIP entities, it can insert a Feature-Caps header field,
   together with feature tags associated with the supported features, in
   a REGISTER response.


5.  Proxy behavior

   When a proxy receives a SIP request, if the proxy wants to indicate
   support of features towards its downstream SIP entities, it adds a
   Feature-Caps header field to the request, together with one or more
   feature tags associated with the supported features, before it
   forwards the request.

   When a proxy adds a Feature-Caps header field to a SIP request, it
   MUST place the header field before any existing Feature-Caps header
   field in the request.

   When a proxy receives a SIP response, if the proxy wants to indicate
   support of features towards its upstream SIP entities, it adds a
   Feature-Caps header field to the response, together with one or more
   feature tags associated with the supported features, before it
   forwards the response.

   When a proxy adds a Feature-Caps header field to a SIP response, it
   MUST place the header field before any existing Feature-Caps header
   field in the response.

   Each value of a Feature-Caps header field MUST contain a "*" value,
   followed by one or more feature tags, associated with the supported
   features, separated by semicolon (";").

   A "*" value means that no information regarding which proxy, or
   domain, that support the features associated with the feature tags,
   is provided.

   NOTE: When used in a Contact header field, a "*" value has an "any
   URI" meaning.  When used in a Feature-Caps header field, it simply



Holmberg & Sedlacek      Expires April 30, 2012                 [Page 4]

Internet-Draft                proxy feature                 October 2011


   means that no URI information is provided.


6.  Feature-Caps Header Field Definition

6.1.  General

   This section describes how the Feature-Caps header field is used, and
   the associated semantics, with different SIP methods and response
   codes.

   NOTE: Future specification can define usage semantics of the Feature-
   Caps header fields for SIP methods, response codes and request types
   not specified in this specification.

6.2.  SIP Dialog

   The Feature-Caps header field can be used within an initial SIP
   request for a dialog, and within any provisional or successful final
   response (18x and 2xx) associated with such request.

   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.

6.3.  SIP Registration (REGISTER)

   The Feature-Caps header field can be used within a SIP REGISTER
   request, and within the 200 (OK) response of such request.

   If a feature tag is inserted in a Feature-Caps header field of a SIP
   REGISTER request or response, the feature associated with the feature
   tag MUST be supported for the registration, and all SIP transactions
   associated with the registration, until the registration is re-
   freshed or terminated.

6.4.  SIP Stand-Alone Transactions

   The Feature-Caps header field can be used within an request for
   standalone SIP transaction, and within any provisional or successful
   final response (18x and 2xx) associated with such request.

   If a feature tag is inserted in a Feature-Caps header field of an
   request or response for a standalone transaction, the feature
   associated with the feature tag MUST be supported for the standalone
   transaction.




Holmberg & Sedlacek      Expires April 30, 2012                 [Page 5]

Internet-Draft                proxy feature                 October 2011


6.5.  SIP Capability Query (OPTIONS)


7.  Syntax

7.1.  General

7.2.  ABNF

   The ABNF for the Feature-Caps header fields is:


           Feature-Caps = ("Feature-Caps" / "fc") HCOLON fc-value
                          *(COMMA fc-value)
           fc-value     = "*" *(SEMI feature-param)
                          ;;feature-param from RFC 3840


                              Figure 1: ABNF


8.  Feature Tag Usage With Feature-Caps

   Feature tags inserted in a Feature-Caps header field indicate that
   the SIP entity that inserted the header field support of the
   associated features.

   In order to use a feature tag in a Feature-Caps header field, the
   feature tag 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
   used in a Feature-Caps header field.

   Within a given Feature-Caps header field, features are listed in a
   non-priority order, and for a given header field the the order of
   listed features have the same meaning.  For example, "foo;bar" and
   "bar;foo" have the same meaning (i.e. that the entity that inserted
   the feature tags support the features associated with the "foo" and
   "bar" feature tags.


9.  IANA Considerations

   This specification registers a new SIP header field, Feature-Caps,
   according to the process of RFC 3261 [RFC3261].

   The following is the registration for the Feature-Caps header field:




Holmberg & Sedlacek      Expires April 30, 2012                 [Page 6]

Internet-Draft                proxy feature                 October 2011


   RFC Number: RFC XXX

   Header Field Name: Feature-Caps

   Compact Form: fc


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 and Dale Worley for their comments and
   guidance on the mailing list.

   The usage of a new header field, and the header field name, were
   suggested by Hadriel Kaplan.


12.  Change Log

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

   Changes from draft-holmberg-sipcore-proxy-feature-02
   o  Definition, and usage of, a new header field, instead of Path,
      Record-Route, Route and Service-Route.

   Changes from draft-holmberg-sipcore-proxy-feature-01
   o  Requirement section added
   o  Use-cases and examples updated based on work in 3GPP

   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.




Holmberg & Sedlacek      Expires April 30, 2012                 [Page 7]

Internet-Draft                proxy feature                 October 2011


   [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.7.0, September 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












Holmberg & Sedlacek      Expires April 30, 2012                 [Page 8]


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