[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                   M. Garcia-Martin
Internet-Draft                                                     Nokia
Expires: January 2, 2006                                    July 1, 2005


Private Header (P-Header) Extensions to the Session Initiation Protocol
(SIP) in support of the European Telecommunications Standards Institute
                 (ETSI) Next Generation Networks (NGN)
               draft-garcia-sipping-etsi-ngn-p-headers-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a private SIP header field (P-header) used by
   the European Telecommunications Standards Institte (ETSI) in Next
   Generation Networks (NGN).  The P-header is used for triggering
   services.






Garcia-Martin            Expires January 2, 2006                [Page 1]


Internet-Draft           ETSI NGN SIP P- headers               July 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overall Applicability  . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  SIP Private Headers  . . . . . . . . . . . . . . . . . . . . .  3
     4.1   The SIP P-AoC header field . . . . . . . . . . . . . . . .  3
       4.1.1   Applicability statement of the P-AoC header field  . .  4
       4.1.2   Usage of the SIP P-AoC header field  . . . . . . . . .  4
       4.1.3   Syntax of the P-AoC header field . . . . . . . . . . .  5
       4.1.4   Table of methods . . . . . . . . . . . . . . . . . . .  6
     4.2   Security Considerations  . . . . . . . . . . . . . . . . .  6
     4.3   IANA Considerations  . . . . . . . . . . . . . . . . . . .  6
     4.4   Acknowledgements . . . . . . . . . . . . . . . . . . . . .  7
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1   Normative References . . . . . . . . . . . . . . . . . . .  7
     5.2   Informative References . . . . . . . . . . . . . . . . . .  7
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements . . . . . . . .  9
































Garcia-Martin            Expires January 2, 2006                [Page 2]


Internet-Draft           ETSI NGN SIP P- headers               July 2005


1.  Introduction

   The European Telecommunication Standards Institute (ETSI) is
   defininig a Next Generation Network (NGN) where a substantial part of
   it is based on the IP Multimedia Subsystem (IMS) defined by the
   Third-Generation Partnership Project (3GPP).  IMS is largely based on
   the Session Initiation Protocol [RFC3261].

   ETSI has developed a number of requirements [I-D.jesske-sipping-
   tispan-requirements] to support the usage of SIP in Next Generation
   Networks that interoperate, at the service level, with the Public
   Switched Telephone Network (PSTN), the Integrated Services Digital
   Network (ISDN), the 3GPP IP Multimedia Subsystem (IMS), and SIP
   networks and terminals that implement the service logic.

   In order to provide full support in SIP of existing services,
   extensions to SIP are needed.  This document defines a number of
   Private headers (P- headers) to support those services.

2.  Overall Applicability

   The SIP extensions specified in this document make certain
   assumptions regarding network topology, linkage between SIP and lower
   layers, and the availability of transitive trust.  These assumptions
   are generally NOT APPLICABLE in the Internet as a whole.  The
   mechanisms specified here were designed to satisfy the requirements
   specified by ETSI NGN [I-D.jesske-sipping-tispan-requirements] for
   which either no general-purpose solution was planned, where
   insufficient operational experience was available to understand if a
   general solution is needed, or where a more general solution is not
   yet mature.  An analysis of these requirements is documented in the
   ETSI NGN Analysis ID [I-D.jesske-sipping-tispan-analysis].  For more
   details about the assumptions made about these extensions, consult
   the Applicability subsection for each extension.

3.  Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [RFC2119].

4.  SIP Private Headers

4.1  The SIP P-AoC header field

   This extension allows a User Agent Client (UAC) to request, at the
   time of sending a request, that an Application Server provides
   charging information related to the request where the header field is



Garcia-Martin            Expires January 2, 2006                [Page 3]


Internet-Draft           ETSI NGN SIP P- headers               July 2005


   included.  The actual information to be delivered to the UAC is
   outside the scope of this specification, but in general, it is
   supposed to contain detailed information related to the session,
   subscription, messaging or any other SIP request that may incur
   charges to the user.

   The scope of this document is limited to defining the header field
   that provides a hint to an application server that the user is
   willing to receive advice of charge information.  The actual
   mechanism and the contents of the advice of charging information
   delivered to the user are outside the scope of this document, but as
   an example, the application sender can send an instant message with
   the advice of charge information, or the instant message can contain
   a link to a web page that contains more detailed and accurate data.
   The actual information to be delivered to the UAC is supposed to
   contain detailed information related to the session, subscription,
   messaging or any other SIP request that may incur charges to the
   user, but once more, its acquisition and formatting is outside the
   scope of this document.

   The mechanism assumes that a SIP proxy is forwarding SIP requests
   that contain the P-AoC header field to an application server that is
   delivering the service.  The application sever receives the request,
   analyzes and process it, and based on the available information
   produces the appropriate content and sends it in a separate request
   to the user.  The application server also forwards the request to its
   destination.

4.1.1  Applicability statement of the P-AoC header field

   This mechanism is appropriate in environments where a service
   provider is collecting charging events related to the establishment
   of SIP sessions, subscriptions, messages, and other related SIP
   activities.  Since SIP systems available in the public Internet will
   typically not be subjected to this type of charging, this SIP
   extension is not deemed to be of general interest.

4.1.2  Usage of the SIP P-AoC header field

   When a User Agent (UA) generates a non-mid dialog request, and the
   user wants to receive information about the potential charges
   incurred by the SIP event, the UAC inserts a P-AoC header field in
   the SIP request with the value set to 'inform'.  The presence of this
   header field in the request allows the network SIP proxies to route
   the SIP request through an application server that can be analyzing
   the request, collecting charging information, and generating some
   sort of feedback to the user.




Garcia-Martin            Expires January 2, 2006                [Page 4]


Internet-Draft           ETSI NGN SIP P- headers               July 2005


4.1.2.1  Procedures at the UA

   A UAC that supports this extension and is willing to receive advice
   of charge information related to the request MAY insert a P-AoC
   header in a non mid-dialog request (e.g., initial INVITE, initial
   SUBSCRIBE, MESSAGE outside a dialog, etc.).  The presence of this
   header is a request to the network to provide charging information,
   if available, although there is not guarantee that the network nodes
   are able or willing to honor the request for this information.

   In general a User Agent Server (UAS) will not receive requests
   containing a P-AoC header field.  However, if the service is not
   supported by the caller's network, then it is possible that the UAS
   receives a SIP request containing a P-AoC header filed.  User Agent
   Servers that support this extension and receive a request that
   contains a P-AoC header field SHOULD ignore the header field.

4.1.2.2  Procedures at a SIP proxy

   Generally speaking, SIP proxies that receive a request containing a
   P-AoC header field should include the header when the request is
   forwarded downstream.  Note that this is also the default proxy
   behaviour for unknown header fields.

   A SIP proxy that receives a request that includes a P-AoC header
   field can route the request to an application server for further
   analysis and generation of advice of charging information.  Besides
   that, SIP proxies do not do any other action on the header field.

4.1.2.3  Procedures at an application server

   An application server that receives a SIP request that contains a
   P-AoC header field MAY analyze the SIP request for the purpose of
   collecting charging data.  If the service is provided, the
   application server SHOULD remove the P-AoC header field from the
   request before forwarding downstream.  But no matter whether the
   service is provided or not the application server MUST forward the
   request downstream.

   Additionally, the application server can deliver the charging
   information to the user, however, the nature and procedures of this
   information is outside the scope of this memo.

4.1.3  Syntax of the P-AoC header field

   The syntax of the P-AoC header field is described according to the
   Augmented Backus-Naur Form (BNF) defined in RFC 2234 [RFC2234] and
   extended by RFC 3261 [RFC3261].



Garcia-Martin            Expires January 2, 2006                [Page 5]


Internet-Draft           ETSI NGN SIP P- headers               July 2005


   P-Advice-of-Charge  = "P-AoC" HCOLON p-aoc-spec *(COMMA p-aoc-spec)
   p-aoc-spec          = "inform" / token *(SEMI aoc-param)
   aoc-param           = generic-param

   The 'inform' value requests an application server to deliver
   information of the potential charges associated with the request, and
   at the same time request the application server to proceed processing
   the request downstream.  Other values or parameters can be added in
   the future as needed.

4.1.4  Table of methods

   Table 1 shows the occurance of the P-AoC header field in different
   SIP methods.

   Header field          where  proxy  ACK BYE CAN INV OPT REG
   ___________________________________________________________
   P-AoC                   R      dr    -   -   -   o   o   o


   Header field                    SUB NOT PRA INF UPD MSG REF
   ___________________________________________________________
   P-AoC                   R        o   -   -   -   -   o   o

                 Table 1: Summary of methods


4.2  Security Considerations

   The presence of the P-AoC header in a request does not affect the
   treatment of the request, and thus, the actions of rogue proxies that
   deliberately insert or remove this header in SIP requests do not have
   an action on the session, subscription, message, etc. itself.

4.3  IANA Considerations

   This memo requests IANA to include a new P-AoC header field in the
   Header Fields subregistry of the Session Initiation Protocol (SIP)
   Parameters registry, as follows:

   Header Name        compact    Reference
   -----------------  -------    ---------
   P-AoC                         [RFCXXXX]

   Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC
   number of this memo.





Garcia-Martin            Expires January 2, 2006                [Page 6]


Internet-Draft           ETSI NGN SIP P- headers               July 2005


4.4  Acknowledgements

   The author would like to thank the members of the ETSI TISPAN WG3 for
   their comments to this memo.

5.  References

5.1  Normative References

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

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 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.

5.2  Informative References

   [I-D.jesske-sipping-tispan-requirements]
              Jesske, R., "Input Requirements for the Session Initiation
              Protocol (SIP) in support for  the European
              Telecommunications Standards Institute (ETSI) Next
              Generation Network (NGN) simulation services",
              draft-jesske-sipping-tispan-requirements-01 (work in
              progress), June 2005.

   [I-D.jesske-sipping-tispan-analysis]
              Jesske, R., "Analysis of the Input Requirements for the
              Session Initiation Protocol (SIP)  in support for the
              European Telecommunications Standards Institute (ETSI)
              Next Generation Networks (NGN) simulation service",
              draft-jesske-sipping-tispan-analysis-00 (work in
              progress), June 2005.














Garcia-Martin            Expires January 2, 2006                [Page 7]


Internet-Draft           ETSI NGN SIP P- headers               July 2005


Author's Address

   Miguel A. Garcia-Martin
   Nokia
   P.O. Box 407
   NOKIA GROUP, FIN  00045
   Finland

   Phone: +358 50 480 4586
   Email: miguel.an.garcia@nokia.com









































Garcia-Martin            Expires January 2, 2006                [Page 8]


Internet-Draft           ETSI NGN SIP P- headers               July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Garcia-Martin            Expires January 2, 2006                [Page 9]