Network Working Group                                           K. Drage
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational                               C. Holmberg
Expires: July 12, 2012                                          Ericsson
                                                               R. Jesske
                                                        Deutsche Telekom
                                                         January 9, 2012


Private Header (P-Header) Extensions to the Session Initiation Protocol
        (SIP) for the 3rd-Generation Partnership Project (3GPP)
                   draft-drage-sipping-rfc3455bis-03

Abstract

   This document describes a set of private Session Initiation Protocol
   (SIP) header fields (P-headers) used by the 3rd-Generation
   Partnership Project (3GPP), along with their applicability, which is
   limited to particular environments.  The P-header fields are for a
   variety of purposes within the networks that the partners use,
   including charging and information about the networks a call
   traverses.

Status of this Memo

   This Internet-Draft is submitted 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 July 12, 2012.

Copyright Notice

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



Drage, et al.             Expires July 12, 2012                 [Page 1]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

































Drage, et al.             Expires July 12, 2012                 [Page 2]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


Table of Contents

   1.  Overall Applicability  . . . . . . . . . . . . . . . . . . . .  5
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  SIP Private Header Fields  . . . . . . . . . . . . . . . . . .  5
     4.1.  The P-Associated-URI header field  . . . . . . . . . . . .  5
       4.1.1.  Applicability statement for the P-Associated-URI
               header field . . . . . . . . . . . . . . . . . . . . .  6
       4.1.2.  Usage of the P-Associated-URI header field . . . . . .  7
     4.2.  The P-Called-Party-ID header field . . . . . . . . . . . .  8
       4.2.1.  Applicability statement for the P-Called-Party-ID
               header field . . . . . . . . . . . . . . . . . . . . . 12
       4.2.2.  Usage of the P-Called-Party-ID header field  . . . . . 12
     4.3.  The P-Visited-Network-ID header field  . . . . . . . . . . 13
       4.3.1.  Applicability statement for the
               P-Visited-Network-ID header field  . . . . . . . . . . 13
       4.3.2.  Usage of the P-Visited-Network-ID header field . . . . 14
     4.4.  The P-Access-Network-Info header field . . . . . . . . . . 17
       4.4.1.  Applicability Statement for the
               P-Access-Network-Info header field . . . . . . . . . . 18
       4.4.2.  Usage of the P-Access-Network-Info header  . . . . . . 19
     4.5.  The P-Charging-Function-Addresses header . . . . . . . . . 20
       4.5.1.  Applicability Statement for the
               P-Charging-Function-header Addresses . . . . . . . . . 21
       4.5.2.  Usage of the P-Charging-Function-Addresses header  . . 22
     4.6.  The P-Charging-Vector header . . . . . . . . . . . . . . . 24
       4.6.1.  Applicability Statement for the P-Charging-Vector
               header . . . . . . . . . . . . . . . . . . . . . . . . 25
       4.6.2.  Usage of the P-Charging-Vector header  . . . . . . . . 26
       4.6.3.  Usage of transit-ioi . . . . . . . . . . . . . . . . . 28
   5.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 28
     5.1.  P-Associated-URI header syntax . . . . . . . . . . . . . . 29
     5.2.  P-Called-Party-ID header syntax  . . . . . . . . . . . . . 29
     5.3.  P-Visited-Network-ID header syntax . . . . . . . . . . . . 29
     5.4.  P-Access-Network-Info header syntax  . . . . . . . . . . . 29
     5.5.  P-Charging-Function-Addresses header syntax  . . . . . . . 31
     5.6.  P-Charging-Vector header syntax  . . . . . . . . . . . . . 31
     5.7.  Table of new headers . . . . . . . . . . . . . . . . . . . 32
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
     6.1.  P-Associated-URI . . . . . . . . . . . . . . . . . . . . . 33
     6.2.  P-Called-Party-ID  . . . . . . . . . . . . . . . . . . . . 34
     6.3.  P-Visited-Network-ID . . . . . . . . . . . . . . . . . . . 34
     6.4.  P-Access-Network-Info  . . . . . . . . . . . . . . . . . . 34
     6.5.  P-Charging-Function-Addresses  . . . . . . . . . . . . . . 35
     6.6.  P-Charging-Vector  . . . . . . . . . . . . . . . . . . . . 36
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 36
   8.  Contributors and Acknowledgements  . . . . . . . . . . . . . . 37



Drage, et al.             Expires July 12, 2012                 [Page 3]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   9.  Appendix: Changes from RFC 3455  . . . . . . . . . . . . . . . 38
   10. Appendix: Summary of changes between different versions  . . . 40
     10.1. Changes between RFC 3455 and -00 . . . . . . . . . . . . . 40
     10.2. Changes between -00 and -01  . . . . . . . . . . . . . . . 42
     10.3. Changes between -01 and -02  . . . . . . . . . . . . . . . 43
       10.3.1. Changes between -02 and -03  . . . . . . . . . . . . . 43
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 43
     11.2. Informative References . . . . . . . . . . . . . . . . . . 44
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45









































Drage, et al.             Expires July 12, 2012                 [Page 4]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


1.  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 in the 3GPP Release 5 requirements on SIP [RFC4083] 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.  For more details about the assumptions made about these
   extensions, consult the Applicability subsection for each extension.


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 [RFC2119].


3.  Overview

   The Third Generation Partnership Project (3GPP) has selected SIP as
   the protocol used to establish and tear down multimedia sessions in
   the context of its IP Multimedia Subsystem (IMS).  (For more
   information on the IMS, a detailed description can be found in 3GPP
   TS 23.228 [TS23.228] and 3GPP TS 24.229 [TS24.229]). 3GPP notified
   the IETF SIP and SIPPING working groups that existing SIP documents
   provided almost all the functionality needed to satisfy the
   requirements of the IMS, but that they required some additional
   functionality in order to use SIP for this purpose.  These
   requirements [RFC4083] are documented in an Internet Draft which was
   submitted to the SIPPING Working Group.  Some of these requirements
   are satisfied by chartered extensions, while other requirements were
   applicable to SIP, but not sufficiently general for the SIP Working
   Group to adopt.  This document describes private extensions to
   address those requirements.  Each extension, or set of related
   extensions is described in its own section below.


4.  SIP Private Header Fields

4.1.  The P-Associated-URI header field

   This extension allows a registrar to return a set of associated URIs
   for a registered address-of-record.  We define the P-Associated-URI



Drage, et al.             Expires July 12, 2012                 [Page 5]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   header field, used in the 200 (OK) response to a REGISTER request.
   The P-Associated-URI header field transports the set of Associated
   URIs to the registered address-of-record.

   An associated URI is a URI that the service provider has allocated to
   a user for his own usage.  A registrar contains information that
   allows an address-of-record URI to be associated with zero or more
   URIs.  Usually, all these URIs (the address-of-record URI and the
   associated URIs) are allocated for the usage of a particular user.
   This extension to SIP allows the UAC to know, upon a successful
   authenticated registration, which other URIs, if any, the service
   provider has associated to an address-of-record URI.

   Note that, generally speaking, the registrar does not register the
   associated URIs on behalf of the user.  Only the address-of-record
   which is present in the To header field of the REGISTER is registered
   and bound to the contact address.  The only information conveyed is
   that the registrar is aware of other URIs to be used by the same
   user.

   It may be possible, however, that an application server (or even the
   registrar itself) registers any of the associated URIs on behalf of
   the user by means of a third party registration.  However, this third
   party registration is out of the scope of this document.  A UAC MUST
   NOT assume that the associated URIs are registered.

   If a UAC wants to check whether any of the associated URIs is
   registered, it can do so by mechanisms specified outside this
   document, e.g., the UA may send a REGISTER request with the To header
   field value set to any of the associated URIs and without a Contact
   header field.  The 200 (OK) response will include a Contact header
   field with the list of registered contact addresses.  If the
   associated URI is not registered, the UA MAY register it prior to its
   utilization.

4.1.1.  Applicability statement for the P-Associated-URI header field

   The P-Associated-URI header field is applicable in SIP networks where
   the SIP provider is allocating the set of identities that a user can
   claim (in header fields like the From header field) in requests that
   the UA generates.  It furthermore assumes that the provider knows the
   entire set of identities that a user can legitimately claim, and that
   the user is willing to restrict its claimed identities to that set.
   This is in contrast to normal SIP usage, where the From field is
   explicitly an end-user specified field.






Drage, et al.             Expires July 12, 2012                 [Page 6]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


4.1.2.  Usage of the P-Associated-URI header field

   The registrar inserts the P-Associated-URI header field into the 200
   (OK) response to a REGISTER request.  The header field value is
   populated with a list of URIs that are associated to the address-of-
   record.

   If the registrar supports the P-Associated-URI header field extension
   and there is an associated uri, then the registrar MUST insert the
   P-Associated-URI header field in all the 200 (OK) responses to a
   REGISTER request.  The absence of an P-Associated-URI does indicate
   that no associated uri's are existing.

4.1.2.1.  Procedures at the UA

   A UAC may receive a P-Associated-URI header field in the 200 (OK)
   response for a REGISTER request.  The presence of the header field in
   the 200 (OK) response for a REGISTER request implies that the
   extension is supported at the registrar.

   The header field value contains a list of one or more associated URIs
   to the address-of-record URI.  The UAC MAY use any of the associated
   URIs to populate the From header field value, or any other SIP header
   field value that provides information of the identity of the calling
   party, in a subsequent request.

   The UAC MAY check whether the associated URI is registered or not.
   This check can be done, e.g., by populating the To header field value
   in a REGISTER sent to the registrar and without a Contact header
   field.  The 200 (OK) response will include a Contact header field
   with the list of registered contact addresses.  As described in SIP
   [RFC3261], the 200 (OK) response may contain a Contact header field
   with zero or more values (zero meaning the address-of-record is not
   registered).

4.1.2.2.  Procedures at the registrar

   A registrar that receives and authorizes a REGISTER request, may
   associate zero or more URIs with the address-of-record.

   A registrar that supports this specification MUST include a
   P-Associated-URI header field in the 200 (OK) response to a REGISTER
   request.  The header field MUST be populated with a comma-separated
   list of URIs which are associated to the address-of-record under
   registration.

   In case the address-of-record under registration does not have any
   other URIs associated, the P-Associater-URI header fild shall not be



Drage, et al.             Expires July 12, 2012                 [Page 7]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   attached.

4.1.2.3.  Procedures at the proxy

   This memo does not define any procedure at the proxy.  The proxy does
   not add, read, modify or delete the header field, and therefore
   RFC3261 [RFC3261] proxy procedures only apply to the header field.

4.2.  The P-Called-Party-ID header field

   A proxy server inserts a P-Called-Party-ID header field, typically in
   an INVITE request, en-route to its destination.  The header is
   populated with the Request-URI received by the proxy in the request.
   The UAS identifies which address-of-record, out of several registered
   address-of-records, the invitation was sent to (for example, the user
   may be simultaneously using a personal and a business SIP URIs to
   receive invitation to sessions).  The UAS may use the information to
   render different distinctive audiovisual alerting tones, depending on
   the URI used to receive the invitation to the session.

   Users in the 3GPP IP Multimedia Subsystem (IMS) may get one or
   several SIP URIs (address-of-record) to identify the user.  For
   instance, a user may get a business SIP URI and a personal one.  As
   an example of utilization, the user may make available the business
   SIP URI to co-workers and may make available the personal SIP URI to
   members of the family.

   At a certain point in time, both the business SIP URI and the
   personal SIP URI are registered in the SIP registrar, so both URIs
   can receive invitations to new sessions.  When the user receives an
   invitation to join a session, he/she should be aware of which of the
   several registered SIP URIs this session was sent to.

   This requirement is stated in the 3GPP Release 5 requirements on SIP
   [RFC4083].

   The problem arises during the terminating side of a session
   establishment, when the SIP proxy that is serving a UA gets an INVITE
   request, and the SIP server retargets the SIP URI which is present in
   the Request-URI field, and replaces it by the SIP URI published by
   the user in the Contact header field of the REGISTER request at
   registration time.  When the UAS receives the SIP INVITE, request it
   cannot determine which address-of-record the request was sent to.

   One can argue that the To header field conveys the semantics of the
   called user, and therefore, this extension to SIP is not needed.
   Although the To header field in SIP may convey the called party ID in
   most situations, there are two particular cases when the above



Drage, et al.             Expires July 12, 2012                 [Page 8]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   assumption is not correct:

   1.  The session has been forwarded, redirected, etc., by previous SIP
       proxies, before arriving to the proxy which is serving the called
       user.

   2.  The UAC builds an INVITE request and the To header field is not
       the same as the Request-URI.

   The problem of using the To header field is that this field is
   populated by the UAC and not modified by proxies in the path.  If the
   UAC, for any reason, did not populate the To header field with the
   address-of-record of the destination user, then the destination user
   is not able to distinguish which address-of-record the session was
   destined.

   Another possible solution to the problem is built upon the
   differentiation of the Contact header field value between different
   address-of-record at registration time.  The UA can differentiate
   each address-of-record it registers by assigning a different Contact
   header field value.  For instance, when the UA registers the address-
   of-record sip:id1, the Contact header field value can be sip:id1@ua;
   the registration of sip:id2 can be bound to the Contact value
   sip:id2@ua.

   The solution described above assumes that the UA explicitly registers
   each of its address-of-record URIs, and therefore, it has full
   control over the contact address values assigned to each
   registration.  However, in the case the UA does not have full control
   of its registered address-of-record, because of, e.g., a third party
   registration, the solution does not work.  This may be the case of
   the 3GPP registration, where the UA may have previously indicated the
   network, by means outside of SIP, that some other address-of-record
   URIs may be automatically registered when the UA registers a
   particular address-of-record.  The requirement is covered in the 3GPP
   Release 5 requirements on SIP [RFC4083].

   In the next paragraphs we show an example of the problem, in the case
   there has been some sort of call forwarding in the session, so that
   the UAC is not aware of the intended destination URI in the current
   INVITE request.

   We assume that a User Agent (UA) is registering to his proxy (P1).








Drage, et al.             Expires July 12, 2012                 [Page 9]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


     Scenario                      UA --- P1

         F1 Register UA -> P1
              REGISTER sip:example.com SIP/2.0
              Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
              To: sip:user1-business@example.com
              From: sip:user1-business@example.com;tag=456248
              Call-ID: 843817637684230998sdasdh09
              CSeq: 1826 REGISTER
              Contact: <sip:user1@192.0.2.4>

   The user also registers his personal URI to his/her registrar.
    F2 Register UA -> P1
              REGISTER sip:example.com SIP/2.0
              Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8
              To: sip:user1-personal@example.com
              From: sip:user1-personal@example.com;tag=346249
              Call-ID: 2Q3817637684230998sdasdh10
              CSeq: 1827 REGISTER
              Contact: <sip:user1@192.0.2.4>

   Later, the proxy/registrar (P1) receives an INVITE request from
   another proxy (P2) destined to the user's business SIP address-of-
   record.  We assume that this SIP INVITE request has undergone some
   sort of forwarding in the past, and as such, the To header field is
   not populated with the SIP URI of the user.  In this case we assume
   that the session was initially addressed to
   sip:other-user@othernetwork.com.  The SIP server at othernetwork.com
   has forwarded this session to sip:user1-business@example.com

            Scenario                      UA --- P1 --- P2

         F3 Invite P2 -> P1
              INVITE sip:user1-business@example.com SIP/2.0
              Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
              To: sip:other-user@othernetwork.com
              From: sip:another-user@anothernetwork.com;tag=938s0
              Call-ID: 843817637684230998sdasdh09
              CSeq: 101 INVITE

   The proxy P1 retargets the user and replaces the Request-URI with the
   SIP URI published during registration time in the Contact header
   field value.








Drage, et al.             Expires July 12, 2012                [Page 10]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


       F4 Invite P1 -> UA
              INVITE sip:user1@192.0.2.4 SIP/2.0
              Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
              Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
              To: sip:other-user@othernetwork.com
              From: sip:another-user@anothernetwork.com;tag=938s0
              Call-ID: 843817637684230998sdasdh09
              CSeq: 101 INVITE

   When the UAS receives the INVITE request, it cannot determine whether
   it got the session invitation due to his registration of the business
   or the personal address-of-record.  Neither the UAS nor proxies or
   application servers can provide this user a service based on the
   destination address-of-record of the session.

   We solve this problem by allowing the proxy that is responsible for
   the home domain (as defined in SIP) of the user to insert a P-Called-
   Party-ID header field that identifies the address-of-record to which
   this session is destined.

   If this SIP extension is used, the proxy serving the called user will
   get the message flow F5, it will populate the P-Called-Party-ID
   header field in message flow F6 with the contents of the Request-URI
   in F4.  This is show in flows F5 and F6 below:
     F5 Invite P2 -> P1
              INVITE sip:user1-business@example.com SIP/2.0
              Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
              To: sip:other-user@othernetwork.com
              From: sip:another-user@anothernetwork.com;tag=938s0
              Call-ID: 843817637684230998sdasdh09
              CSeq: 101 INVITE

         F6 Invite P1 -> UA
              INVITE sip:user1@192.0.2.4 SIP/2.0
              Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
              Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
              To: sip:other-user@othernetwork.com
              From: sip:another-user@anothernetwork.com;tag=938s0
              Call-ID: 843817637684230998sdasdh09
              P-Called-Party-ID: sip:user1-business@example.com
              CSeq: 101 INVITE

   When the UA receives the INVITE request F6 it can determine the
   intended address-of-record of the session, and apply whatever service
   is needed for that address-of-record.






Drage, et al.             Expires July 12, 2012                [Page 11]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


4.2.1.  Applicability statement for the P-Called-Party-ID header field

   The P-Called-Party-ID is applicable when the UAS needs to be aware of
   the intended address-of-record that was present in the Request-URI of
   the request, before the proxy retargets to the contact address.  The
   UAS may be interested in applying different audiovisual alerting
   effects or other filtering services, depending on the intended
   destination of the request.  It is specially valuable when the UAS
   has registered several address-of-record URIs to his registrar, and
   therefore, the UAS is not aware of the address-of-record that was
   present in the INVITE request when it hit his proxy/registrar, unless
   this extension is used.

   Requirements for a more general solution are proposed in [RFC4244].
   3GPP will continue to use the P-Called-Party-ID header field even
   though RFC 4244 [RFC4244] has now been published.

4.2.2.  Usage of the P-Called-Party-ID header field

   The P-Called-Party-ID header field provides proxies and the UAS with
   the address-of-record that was present in the Request-URI of the
   request, before a proxy retargets the request.  This information is
   intended to be used by subsequent proxies in the path or by the UAS.

   Typically, a SIP proxy inserts the P-Called-Party-ID header field
   prior to retargetting the Request-URI in the SIP request.  The header
   field value is populated with the contents of Request-URI, prior to
   replacing it with the Contact address.

4.2.2.1.  Procedures at the UA

   A UAC MUST NOT insert a P-Called-Party-ID header field in any SIP
   request or response.

   A UAS may receive a SIP request that contains a P-Called-Party-ID
   header field.  The header field will be populated with the
   address-of- record received by the proxy in the Request-URI of the
   request, prior to its forwarding to the UAS.

   The UAS may use the value in the P-Called-Party-ID header field to
   provide services based on the called party URI, such as, e.g.,
   filtering of calls depending on the date and time, distinctive
   presentation services, distinctive alerting tones, etc.

4.2.2.2.  Procedures at the proxy

   A proxy that has access to the Contact information of the user, MAY
   insert a P-Called-Party-ID header field in any of the requests



Drage, et al.             Expires July 12, 2012                [Page 12]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   indicated in the Table 1 (Section 5.7).  The proxy MUST populate the
   header field value with the contents of the Request-URI present in
   the SIP request that the proxy received.

   It is necessary that the proxy which inserts the P-Called-Party-ID
   header field has information about the user, in order to prevent a
   wrong delivery of the called party ID.  This information may have
   been learned through a registration process, for instance.

   A proxy or application server that receives a request containing a
   P-Called-Party-ID header field may use the contents of the header
   field to provide a service to the user based on the URI of that
   header field value.

   A SIP proxy MUST NOT insert a P-Called-Party-ID header field in
   REGISTER requests.

4.3.  The P-Visited-Network-ID header field

   3GPP networks are composed of a collection of so called home
   networks, visited networks and subscribers.  A particular home
   network may have roaming agreements with one or more visited
   networks.  This has the effect that when a mobile terminal is
   roaming, it can use resources provided by the visited network in a
   transparent fashion.

   One of the conditions for a home network to accept the registration
   of a UA roaming to a particular visited network, is the existence of
   a roaming agreement between the home and the visited network.  There
   is a need to indicate to the home network which one is the visited
   network that is providing services to the roaming UA.

   3GPP user agents always register to the home network.  The REGISTER
   request is proxied by one or more proxies located in the visited
   network towards the home network.  For the sake of a simple approach,
   it seems sensible that the visited network includes an identification
   that is known at the home network.  This identification should be
   globally unique, and takes the form of a quoted text string or a
   token.  The home network may use this identification to verify the
   existence of a roaming agreement with the visited network, and to
   authorize the registration through that visited network.

4.3.1.  Applicability statement for the P-Visited-Network-ID header
        field

   The P-Visited-Network-ID is applicable whenever the following
   circumstances are met:




Drage, et al.             Expires July 12, 2012                [Page 13]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   1.  There is transitive trust in intermediate proxies between the UA
       and the home network proxy via established relationships between
       the home network and the visited network, and generally supported
       by the use of standard security mechanisms, e.g., IPsec, AKA, or
       TLS.

   2.  An endpoint is using resources provided by one or more visited
       networks (a network to which the user does not have a direct
       business relationship).

   3.  A proxy that is located in one of the visited networks wants to
       be identified at the user's home network.

   4.  There is no requirement that every visited network needs to be
       identified at the home network.  Those networks that want to be
       identified make use of the extension defined in this document.
       Those networks that do not want to be identified do nothing.

   5.  A commonly pre-agreed text string or token identifies the visited
       network at the home network.

   6.  The UAC sends a REGISTER request or dialog-initiating request
       (e.g., INVITE request) or a standalone request outside a dialog
       (e.g., OPTIONS request) to a proxy in a visited network.

   7.  The request traverses, en route to its destination, a first proxy
       located in the visited network, and a second proxy located in the
       home network or its destination is the registrar in the home
       network.

   8.  The registrar or home proxy verifies and authorizes the usage of
       resources (e.g., proxies) in the visited network.

4.3.2.  Usage of the P-Visited-Network-ID header field

   The P-Visited-Network-ID header field is used to convey to the
   registrar or home proxy in the home network the identifier of a
   visited network.  The identifier is a text string or token that is
   known by both the registrar or the home proxy at the home network and
   the proxies in the visited network.

   Typically, the home network authorizes the UA to roam to a particular
   visited network.  This action requires an existing roaming agreement
   between the home and the visited network.

   While it is possible for a home network to identify one or more
   visited networks by inspecting the domain name in the Via header
   fields, this approach has a heavy dependency on DNS.  It is an option



Drage, et al.             Expires July 12, 2012                [Page 14]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   for a proxy to populate the Via header field with an IP address, for
   example, and in the absence of a reverse DNS entry, the IP address
   will not convey the desired information.

   Any SIP proxy that receives any of the requests indicated in Table 1
   (Section 5.7) MAY insert a P-Visited-Network-ID header field when it
   forwards the request.  In case a REGISTER request or other request is
   traversing different administrative domains (e.g., different visited
   networks), a SIP proxy MAY insert a new P-Visited-Network-ID header
   field if the request does not contain a P-Visited-Network-ID header
   field with the same network identifier as its own network identifier
   (e.g., if the request has traversed other different administrative
   domains).

   Note also that, there is not requirement for the header field value
   to be readable in the proxies.  Therefore, a first proxy may insert
   an encrypted header field that only the registrar can decrypt.  If
   the request traverses a second proxy located in the same
   administrative domain as the first proxy, the second proxy may not be
   able to read the contents of the P-Visited-Network-ID header field.
   In this situation, the second proxy will consider that its visited
   network identifier is not already present in the value of the header
   field, and therefore, it will insert a new P-Visited-Network-ID
   header field value (hopefully with the same identifier that the first
   proxy inserted, although perhaps, not encrypted).  When the request
   arrives at the registrar or proxy in the home network, it will notice
   that the header field value is repeated (both the first and the
   second proxy inserted it).  The decrypted values should be the same,
   because both proxies where part of the same administrative domain.
   While this situation is not desirable, it does not create any harm at
   the registrar or proxy in the home network.

   The P-Visited-Network-ID is normally used at registration.  However,
   this extension does not preclude other usages.  For instance, a proxy
   located in a visited network that does not maintain registration
   state may insert a P-Visited-Network-ID header field into any
   standalone request outside a dialog or a request that creates a
   dialog.  At the time of writing this document, the only requests that
   create dialogs are INVITE requests [RFC3261], SUBSCRIBE requests
   [RFC3265] and REFER requests [RFC3515].

   In order to avoid conflicts with identifiers, especially when the
   number of roaming agreements between networks increase, care must be
   taken when selecting the value of the P-Visited-Network-ID.  The
   identifier should be a globally unique to avoid duplications.
   Although there are many mechanism to create globally unique
   identifiers across networks, one of such as mechanisms is already in
   operation, and that is DNS.  The P-Visited-Network-ID does not have



Drage, et al.             Expires July 12, 2012                [Page 15]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   any connection to DNS, but the values in the header field can be
   chosen from the own DNS entry representing the domain name of the
   network.  This guarantees the uniqueness of the value.

4.3.2.1.  Procedures at the UA

   User agent clients SHOULD NOT insert a P-Visited-Network-ID header
   field in any SIP message.

4.3.2.2.  Procedures at the registrar and proxy

   A SIP proxy which is located in a visited network MAY insert a
   P-Visited-Network-ID header field in any of the requests indicated in
   the Table 1 (Section 5.7).  The header field MUST be populated with
   the contents of a text string or a token that identifies the
   administrative domain of the network where the proxy is operating at
   the user's home network.

   A SIP proxy or registrar which is located in the home network may use
   the contents of the P-Visited-Network-ID header field as an
   identifier of one or more visited networks that the request
   traversed.  The proxy or registrar in the home network may take local
   policy driven actions based on the existence or not of a roaming
   agreement between the home and the visited networks.  This means, for
   instance, authorize the actions of the request based on the contents
   of the P-Visited-Network-ID header field.

   A SIP proxy which is located in the home network MUST delete this
   header field when forwarding the message outside the home network
   administrative domain, in order to retain the user's privacy.

   A SIP proxy which is located in the home network SHOULD delete this
   header field when the home proxy has used the contents of the header
   field or the request is routed based on the called party, even when
   the request is not forwarded outside the home network administrative
   domain.

4.3.2.3.  Examples of Usage

   We present example in the context of the scenario presented in the
   following network diagram:
     Scenario            UA --- P1 --- P2 --- REGISTRAR

   This example shows the message sequence for an REGISTER transaction
   originating from UA1 eventually arriving at REGISTRAR.  P1 is an
   outbound proxy for UA1.  In this case P1 also inserts the P-Visited-
   Network-ID header field.  P1 then routes the REGISTER request to the
   Registrar via P2.



Drage, et al.             Expires July 12, 2012                [Page 16]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   Message sequence for REGISTER using P-Visited-Network-ID header
   field:

         F1 Register UA -> P1
              REGISTER sip:example.com SIP/2.0
              Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
              To: sip:user1-business@example.com
              From: sip:user1-business@example.com;tag=456248
              Call-ID: 843817637684230998sdasdh09
              CSeq: 1826 REGISTER
              Contact: <sip:user1@192.0.2.4>

   In flow F2, proxy P2 adds its own identifier to the P-Visited-
   Network-ID header field.

         F2 Register P1 -> P2
              REGISTER sip:example.com SIP/2.0
              Via: SIP/2.0/UDP p1.visited.net;branch=z9hG4bK203igld
              Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8
              To: sip:user1-personal@example.com
              From: sip:user1-personal@example.com;tag=346249
              Call-ID: 2Q3817637684230998sdasdh10
              CSeq: 1826 REGISTER
              Contact: <sip:user1@192.0.2.4>
              P-Visited-Network-ID: "Visited network number 1"

   Finally, in flow F3, proxy P2 decides to insert his own identifier,
   derived from its own domain name.

        F3 Register P2 -> REGISTRAR
             REGISTER sip:example.com SIP/2.0
             Via: SIP/2.0/UDP p2.other.net;branch=z9hG4bK2bndnvk
             Via: SIP/2.0/UDP p1.visited.net;branch=z9hG4bK203igld
             Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8
             To: sip:user1-personal@example.com
             From: sip:user1-personal@example.com;tag=346249
             Call-ID: 2Q3817637684230998sdasdh10
             CSeq: 1826 REGISTER
             Contact: <sip:user1@192.0.2.4>
             P-Visited-Network-ID: other.net, "Visited network number 1"

4.4.  The P-Access-Network-Info header field

   This section describes the P-Access-Network-Info header field.  This
   header field is useful in SIP-based networks that also provide layer
   2/layer 3 connectivity through different access technologies.  SIP
   User Agents may use this header field to relay information about the
   access technology to proxies that are providing services.  The



Drage, et al.             Expires July 12, 2012                [Page 17]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   serving proxy may then use this information to optimize services for
   the UA.  For example, a 3GPP UA may use this header field to pass
   information about the access network such as radio access technology
   and radio cell identity to its home service provider.

   For the purpose of this extension, we define an access network as the
   network providing the layer 2/layer 3 IP connectivity which in turn
   provides a user with access to the SIP capabilities and services
   provided.

   In some cases, the SIP server that provides the user with services
   may wish to know information about the type of access network that
   the UA is currently using.  Some services are more suitable or less
   suitable depending on the access type, and some services are of more
   value to subscribers if the access network details are known by the
   SIP proxy which provides the user with services.

   In other cases, the SIP server that provides the user with services
   may simply wish to know crude location information in order to
   provide certain services to the user.  For example, many of the
   location based services available in wireless networks today require
   the home network to know the identity of the cell the user is being
   served by.

   Some regulatory requirements exist mandating that for cellular radio
   systems, the identity of the cell where an emergency call is
   established is made available to the emergency authorities.

   The SIP server that provides services to the user may desire
   knowledge about the access network.  This is achieved by defining a
   new private SIP extension header field, P-Access-Network-Info.  This
   header field carries information relating to the access network
   between the UAC and its serving proxy in the home network.

4.4.1.  Applicability Statement for the P-Access-Network-Info header
        field

   This mechanism is appropriate in environments where SIP services are
   dependent on SIP elements knowing details about the IP and lower
   layer technologies used by a UA to connect to the SIP network.
   Specifically, the extension requires that the UA know the access
   technology it is using, and that a proxy desires such information to
   provide services.  Generally, SIP is built on the "Everything over IP
   and IP over everything" principle, where the access technology is not
   relevant for the operation of SIP.  Since SIP systems generally
   should not care or even know about the access technology, this SIP
   extension is not for general SIP usage.




Drage, et al.             Expires July 12, 2012                [Page 18]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   The information revealed in the P-Access-Network-Info header field is
   potentially very sensitive.  Proper protection of this information
   depends on the existence of specific business and security
   relationships amongst the proxies that will see SIP messages
   containing this header field.  It also depends on explicit knowledge
   of the UA of the existence of those relationships.  Therefore, this
   mechanism is only suitable in environments where the appropriate
   relationships are in place, and the UA has explicit knowledge that
   they exist.

4.4.2.  Usage of the P-Access-Network-Info header

   When a UA generates a SIP request or response which it knows is going
   to be securely sent to its SIP proxy that is providing services, the
   UA inserts a P-Access-Network-Info header into the SIP message.  This
   header contains information on the access network that the UA is
   using to get IP connectivity.  The header is typically ignored by
   intermediate proxies between the UA and the SIP proxy that is
   providing services.  The proxy providing services can inspect the
   header and make use of the information contained there to provide
   appropriate services, depending on the value of the header.  Before
   proxying the request onwards, this proxy strips the header from the
   message.

   Additionally, the first outbound proxy, if in possession of
   appropriate information, can also add a P-Access-Network-Info header
   field with its own information.

4.4.2.1.  UA behavior

   A UA that supports this extension and is willing to disclose the
   related parameters MAY insert the P-Access-Network-Info header in any
   SIP request or response.

   The UA inserting this information MUST trust the proxy that is
   providing services to protect its privacy by deleting the header
   before forwarding the message outside of the proxy's domain.  This
   proxy is typically located in the home network.

   In order to do the deletion of the header, there must also be a
   transitive trust in intermediate proxies between the UA and the proxy
   that provides the services.  This trust is established by business
   agreements between the home network and the access network, and
   generally supported by the use of standard security mechanisms, e.g.,
   IPsec, AKA, and TLS.






Drage, et al.             Expires July 12, 2012                [Page 19]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


4.4.2.2.  Proxy behavior

   A proxy MUST NOT modify the value of the P-Access-Network-Info
   header.

   A proxy in possession of appropriate information about the access
   technology MAY insert a P-Access-Network-Info header field with its
   own values.  An outbound proxy MUST remove any P-Access-Network-Info
   header field containing a "network-provided" value.

   A proxy which is providing services to the UA, may act upon any
   information present in the P-Access-Network-Info header value, if is
   present, to provide a different service depending on the network or
   the location through which the UA is accessing the server.  For
   example, for cellular radio access networks the SIP proxy located in
   the home network may use the cell ID to provide basic localized
   services.

   A proxy that provides services to the user, the proxy typically
   located in the home network, and therefore trusted, MUST delete the
   header when the SIP signaling is forwarded to a SIP server located in
   a non-trusted administrative network domain.  The SIP server
   providing services to the UA uses the access network information and
   is of no interest to other proxies located in different
   administrative domains.

4.5.  The P-Charging-Function-Addresses header

   3GPP has defined a distributed architecture that results in multiple
   network entities becoming involved in providing access and services.
   There is a need to inform each SIP proxy involved in a transaction
   about the common charging functional entities to receive the
   generated charging records or charging events.

   The solution provided by 3GPP is to define two types of charging
   functional entities: Charging Collection Function () and Event
   Charging Function (ECF).  CCF is used for off-line charging (e.g.,
   for postpaid account charging).  ECF is used for on-line charging
   (e.g., for pre-paid account charging).  There may be more than a
   single instance of CCF and ECF in a network, in order to provide
   redundancy in the network.  In case there are more than a single
   instance of either the CCF or the ECF addresses, implementations
   SHOULD attempt sending the charging data to the ECF or CCF address,
   starting with the first address of the sequence (if any) in the
   P-Charging-Function-Addresses header.  The CCF and ECF addresses may
   be passed during the establishment of a dialog or in a standalone
   transaction.  More detailed information about charging can be found
   in 3GPP TS 32.240 [TS32.240] and 3GPP TS 32.260 [TS32.260].



Drage, et al.             Expires July 12, 2012                [Page 20]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   We define the SIP private header P-Charging-Function-Addresses.  A
   proxy MAY include this header, if not already present, in either the
   initial request or response for a dialog, or in the request and
   response of a standalone transaction outside a dialog.  Only one
   instance of the header MUST be present in a particular request or
   response.

   The mechanisms by which a SIP proxy collects the values to populate
   the P-Charging-Function-Addresses header values are outside the scope
   of this document.  However, as an example, a SIP proxy may have
   preconfigured these addresses, or may obtain them from a subscriber
   database.

4.5.1.  Applicability Statement for the P-Charging-Function-header
        Addresses

   The P-Charging-Function-Addresses header is applicable within a
   single private administrative domain where coordination of charging
   is required, for example, according to the architecture specified in
   3GPP TS 32.240 [TS32.240].

   The P-Charging-Function-Addresses header is not included in a SIP
   message sent outside of the own administrative domain.  The header is
   not applicable if the administrative domain does not provide a
   charging function.

   The P-Charging-Function-Addresses header is applicable whenever the
   following circumstances are met:

   1.  A UA sends a REGISTER or dialog-initiating request (e.g., INVITE
       request) or a standalone transaction request outside a dialog to
       a proxy located in the administrative domain of a private
       network.

   2.  A registrar, proxy or UA that is located in the administrative
       domain of the private network wants to generate charging records.

   3.  A registrar, proxy or UA that is located in the private network
       has access to the addresses of the charging function entities for
       that network.

   4.  There are other proxies located in the same administrative domain
       of the private network, that are generated charging records or
       charging events.  The proxies want to send, by means outside SIP,
       the charging information to the same charging collecting entities
       than the first proxy.





Drage, et al.             Expires July 12, 2012                [Page 21]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


4.5.2.  Usage of the P-Charging-Function-Addresses header

   A SIP proxy that receives a SIP request may insert a P-Charging-
   Function-Addresses header prior to forwarding the request, if the
   header was not already present in the SIP request.  The header value
   contains one or more parameters that contain the hostnames or IP
   addresses of the nodes that are willing to receive charging
   information.

   A SIP proxy that receives a SIP request that includes a P-Charging-
   Function-Addresses may use the hostnames or IP addresses included in
   the value, as the destination of charging information or charging
   events.  The means to send those charging information or events are
   outside the scope of this document, and usually, do not use SIP for
   that purpose.

4.5.2.1.  Procedures at the UA

   This document does not specify any procedure at the UA located
   outside the administrative domain of a private network, with regard
   to the P-Charging-Function-Addresses header.  Such UAs need not
   understand this header.

   However, it might be possible that a UA is located within the
   administrative domain of a private network (e.g., a PSTN gateway, or
   conference mixer), and it may have access to the addresses of the
   charging entities.  In this case, a UA MAY insert the P-Charging-
   Function-Addresses header in a SIP request or response when the next
   hop for the message is a proxy or UA located in the same
   administrative domain.  Similarly such a UA may use the contents of
   the P-Charging-Function-Addresses header in communicating with the
   charging entities.

4.5.2.2.  Procedures at the Proxy

   A SIP proxy that supports this extension and receives a request or
   response without the P-Charging-Function-Addresses MAY insert a
   P-Charging-Function-Addresses header prior to forwarding the message.
   The header is populated with a list of the addresses of one or more
   charging entities where the proxy should send charging related
   information.

   If a proxy that supports this extension receives a request or
   response with the P-Charging-Function-Addresses, it may retrieve the
   information from the header value to use with application specific
   logic, i.e., charging.  If the next hop for the message is within the
   administrative domain of the proxy, then the proxy SHOULD include the
   P-Charging-Function-Addresses header in the outbound message.



Drage, et al.             Expires July 12, 2012                [Page 22]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   However, if the next hop for the message is outside the
   administrative domain of the proxy, then the proxy MUST remove the
   P-Charging-Function-Addresses header.

4.5.2.3.  Examples of Usage

   We present example in the context of the scenario presented in the
   following network diagram:

         Scenario                   UA1 --- P1 --- P2 --- UA2


   In the scenario we assume that P1 and P2 belong to the same
   administrative domain.

   The example below shows the message sequence for an INVITE
   transaction originating from UA1 eventually arriving at UA2.  P1 is
   an outbound proxy for UA1.  In this case P1 also inserts charging
   information.  P1 then routes the call via P2 to UA2.

   Message sequence for INVITE using P-Charging-Function-Addresses:

         F1 Invite UA1 -> P1
            INVITE sip:ua2@home1.net SIP/2.0
            Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
            To: sip:ua2@home1.net
            From: sip:ua1@home1.net;tag=456248
            Call-ID: 843817637684230998sdasdh09
            CSeq: 18 INVITE
            Contact: sip:ua1@192.0.2.4

         F2 Invite P1 -> P2
            INVITE sip:ua2@home1.net SIP/2.0
            Via: SIP/2.0/UDP p1.home1.net:5060;branch=z9hG4bK34ghi7ab04
            Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
            To: sip:ua2@home1.net
            From: sip:ua1home1.net;tag=456248
            Call-ID: 843817637684230998sdasdh09
            CSeq: 18 INVITE
            Contact: sip:ua1@192.0.2.4
            P-Charging-Function-Addresses: ccf=192.1.1.1; ecf=192.1.1.3,
                                           cdf=192.1.1.2; ocf=192.1.1.4


   Now both P1 and P2 are aware of the IP addresses of the entities that
   collect charging record or charging events.  Both proxies can send
   the charging information to the same entities.




Drage, et al.             Expires July 12, 2012                [Page 23]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


4.6.  The P-Charging-Vector header

   3GPP has defined a distributed architecture that results in multiple
   network entities becoming involved in providing access and services.
   Operators need the ability and flexibility to charge for the access
   and services as they see fit.  This requires coordination among the
   network entities (e.g., SIP proxies), which includes correlating
   charging records generated from different entities that are related
   to the same session.

   The correlation information includes, but it is not limited to, a
   globally unique charging identifier that makes easy the billing
   effort.

   A charging vector is defined as a collection of charging information.
   The charging vector may be filled in during the establishment of a
   dialog or standalone transaction outside a dialog.  The information
   inside the charging vector may be filled in by multiple network
   entities (including SIP proxies) and retrieved by multiple network
   entities.  There are three types of correlation information to be
   transferred: the IMS Charging Identity (ICID) value, the address of
   the SIP proxy that creates the ICID value, and the Inter Operator
   Identifiers (IOI).

   ICID is a charging value that identifies a dialog or a transaction
   outside a dialog.  It is used to correlate charging records.  ICID
   MUST be a globally unique value.  One way to achieve globally
   uniqueness is to generate the ICID using two components: a locally
   unique value and the host name or IP address of the SIP proxy that
   generated the locally unique value.

   The IOI identifies both the originating and terminating networks
   involved in a SIP dialog or transaction outside a dialog.  There may
   an IOI generated from each side of the dialog to identify the network
   associated with each side.

   Additionally in a multi network environment one or more transit ioi
   identifiers may be included along the path of the SIP Dialog or
   transaction outside a dialog.  Due to network policy a void value may
   be included instead of the transit network.  The void value is used
   to indicate that a transit appeared but due to operator policy the
   network name is not shown.

   Additionally in an multi service provider environment one or more
   transit ioi identifiers may be included along the path of the SIP
   Dialog or transaction outside a dialog.  Due to operator policy a
   void value may be included instead of the transit operator.  The void
   value is used to indicate that a transit appeared but due to operator



Drage, et al.             Expires July 12, 2012                [Page 24]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   policy the network name is not shown.

   There is also expected to be access network charging information,
   which consists of network specific identifiers for the access level
   (e.g., UMTS radio access network or IEEE 802.11b).  The details of
   the information for each type of network are not described in this
   memo.

   We define the SIP private header P-Charging-Vector.  A proxy MAY
   include this header, if not already present, in either the initial
   request or response for a dialog, or in the request and response of a
   standalone transaction outside a dialog.  Only one instance of the
   header MUST be present in a particular request or response.

   The mechanisms by which a SIP proxy collects the values to populate
   in the P-Charging-Vector are outside the scope of this document.

4.6.1.  Applicability Statement for the P-Charging-Vector header

   The P-Charging-Vector header is applicable within a single private
   administrative domain or between different administrative domains
   where there is a trust relationship between the domains.

   The P-Charging-Vector header is not included in a SIP message sent to
   another network if there is no trust relationship.  The header is not
   applicable if the administrative domain manages charging in a way
   that does not require correlation of records from multiple network
   entities (e.g., SIP proxies).

   The P-Charging-Vector header is applicable whenever the following
   circumstances are met:

   1.  A UA sends a REGISTER or dialog-initiating request (e.g., INVITE)
       or a standalone transaction request outside a dialog to a proxy
       located in the administrative domain of a private network.

   2.  A registrar, proxy or UA that is located in the administrative
       domain of the private network wants to generate charging records.

   3.  A proxy or UA that is located in the administrative domain of the
       private network has access to the charging correlation
       information for that network.

   4.  Optionally, a registrar, proxy or UA that is part of a second
       administrative domain in another private network, whose SIP
       request and responses are traversed through, en-route to the
       first private network, wants to generate charging records and
       correlate those records with those of the first private network.



Drage, et al.             Expires July 12, 2012                [Page 25]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


       This assumes that there is a trust relationship between both
       private networks.

4.6.2.  Usage of the P-Charging-Vector header

   The P-Charging-Vector header is used to convey charging related
   information, such as the globally unique IMS charging identifier
   (ICID) value.

   Typically, a SIP proxy that receives a SIP request that does not
   contain a P-Charging-Vector header may insert it, with those
   parameters that are available at the SIP proxy.

   A SIP proxy that receives a SIP request that contains a P-Charging-
   Vector header may use the values, such as the globally unique ICID,
   to produce charging records.

4.6.2.1.  Procedures at the UA

   This document does not specify any procedure at a UA located outside
   the administrative domain of a private network (e.g., PSTN gateway or
   conference mixer), with regard to the P-Charging-Vector header.  UAs
   need not understand this header.

   However, it might be possible that a UA is located within the
   administrative domain of a private network (e.g., a PSTN gateway, or
   conference mixer), and it may it may interact with the charging
   entities.  In this cases, a UA MAY insert the P-Charging-Vector
   header in a SIP request or response when the next hop for the message
   is a proxy or UA located in the same administrative domain.  Similar
   such a UA may use the contents of the P-Charging-Vector header in
   communicating with the charging entities.

4.6.2.2.  Procedures at the Proxy

   A SIP proxy that supports this extension and receives a request or
   response without the P-Charging-Vector header MAY insert a
   P-Charging-Vector header prior to forwarding the message.  The header
   is populated with one ore more parameters, as described in the
   syntax, including but not limited to, a globally unique charging
   identifier.

   If a proxy that supports this extension receives a request or
   response with the P-Charging-Vector header, it may retrieve the
   information from the header value to use with application specific
   logic, i.e., charging.  If the next hop for the message is within the
   trusted domain, then the proxy SHOULD include the P-Charging-Vector
   header in the outbound message.  If the next hop for the message is



Drage, et al.             Expires July 12, 2012                [Page 26]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   outside the trusted domain, then the proxy MAY remove the P-Charging-
   Function-Addresses header.

   Per local application specific logic, the proxy MAY modify the
   contents of the P-Charging-Vector header prior to sending the
   message.

4.6.2.3.  Examples of Usage

   We present example in the context of the scenario presented in the
   following network diagram:

    Scenario                      UA1 --- P1 --- P2 --- UA2


   This example shows the message sequence for an INVITE transaction
   originating from UA1 eventually arriving at UA2.  P1 is an outbound
   proxy for UA1.  In this case P1 also inserts charging information.
   P1 then routes the call via P2 to UA2.

   Message sequence for INVITE using P-Charging-Vector:

      F1 Invite UA1 -> P1
              INVITE sip:joe@example.com SIP/2.0
              Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
              To: sip:joe@example.com
              From: sip:ua1@home1.net;tag=456248
              Call-ID: 843817637684230998sdasdh09
              CSeq: 18 INVITE
              Contact: sip:ua1@192.0

         F2 Invite P1 -> P2
              INVITE sip:joe@example.com SIP/2.0
              Via: SIP/2.0/UDP P1.home1.net:5060;branch=z9hG4bK34ghi7a
              Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
              To: sip:joe@example.com
              From: sip:ua1@home1.net;tag=456248
              Call-ID: 843817637684230998sdasdh09
              CSeq: 18 INVITE
              Contact: sip:ua1@192.0.2.4
              P-Charging-Vector: icid-value=1234bc9876e;
                                 icid-generated-at=192.0.6.8;
                                 orig-ioi=home1.net#








Drage, et al.             Expires July 12, 2012                [Page 27]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


4.6.3.  Usage of transit-ioi

   The transit-ioi is added to the P-Charging-Vector header field when
   traversing transit networks.  It is allowed to have multiple transit-
   ioi values within one SIP message or response.  The values within the
   Response are independent from the values set up within the Request.

   The element could be either added by the transit network itself or by
   the succeeding network at the entry point where the preceding network
   is known.  Based on network policy a void value can be added.

   Depending on the call scenario it is needed to add for each transit
   network either a transit network name or a void value.  Nevertheless
   it can not be guaranteed that all values will appear within the
   P-Charging-Vector header field.

   Some networks can screen the P-Charging-Vector field and delete
   transit-ioi values, e.g. networks not supporting this value.  There
   are scenarios where the appearance of the transit-ioi values of all
   networks is needed to have a correct end-to-end view.

   The policies of adding, modifying and deletion of transit-ioi values
   are out of the scope of this document.

   The transit-ioi is an indexed value which needs to be incremented
   with each value added to the P-charging vector header field.

   A void value has no index.  By adding the next entry the succeeding
   index and/or void valued needed to be taken into consideration

4.6.3.1.  Procedures at the Proxy

   Procedures described within 4.6.2.2 apply.  A transit-ioi may be
   added or modified by a Proxy.  A deletion of the element could appear
   depending on the network policy and trust rules.  This is also valid
   by replacing the transit-ioi with a void value.


5.  Formal Syntax

   All of the mechanisms specified in this document are described in
   both prose and an augmented Backus-Naur Form (BNF) defined in RFC
   2234 [RFC2234].  Further, several BNF definitions are inherited from
   SIP and are not repeated here.  Implementors need to be familiar with
   the notation and contents of SIP [RFC3261] and RFC 2234 [RFC2234] to
   understand this document.





Drage, et al.             Expires July 12, 2012                [Page 28]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


5.1.  P-Associated-URI header syntax

   The syntax of the P-Associated-URI header is described as follows:

      P-Associated-URI       = "P-Associated-URI" HCOLON
                                  [p-aso-uri-spec]
                                  *(COMMA p-aso-uri-spec)
         p-aso-uri-spec         = name-addr *(SEMI ai-param)
         ai-param               = generic-param


5.2.  P-Called-Party-ID header syntax

   The syntax of the P-Called-Party-ID header is described as follows:

         P-Called-Party-ID      = "P-Called-Party-ID" HCOLON
                                  called-pty-id-spec
         called-pty-id-spec     = name-addr *(SEMI cpid-param)
         cpid-param             = generic-param

5.3.  P-Visited-Network-ID header syntax

   The syntax of the P-Visited-Network-ID header is described as
   follows:

         P-Visited-Network-ID   = "P-Visited-Network-ID" HCOLON
                                   vnetwork-spec
                                   *(COMMA vnetwork-spec)
         vnetwork-spec          = (token / quoted-string)
                                   *(SEMI vnetwork-param)
         vnetwork-param         = generic-param


5.4.  P-Access-Network-Info header syntax

   The syntax of the P-Access-Network-Info header is described as
   follows:














Drage, et al.             Expires July 12, 2012                [Page 29]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


 P-Access-Network-Info  = "P-Access-Network-Info" HCOLON
                               access-net-spec *(COMMA access-net-spec)
      access-net-spec        = (access-type / access-class)
                               *(SEMI access-info)
      access-type            = "IEEE-802.11" / "IEEE-802.11a" /
                               "IEEE-802.11b" / "IEEE-802.11g" /
                               "IEEE-802.11n" / "3GPP-GERAN" /
                               "3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" /
                               "ADSL" / "ADSL2" / "ADSL2+" / "RADSL" /
                               "SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" /
                               "VDSL" / "IDSL" / "3GPP2-1X" /
                               "3GPP2-1X-HRPD" / "3GPP2-UMB" /
                               "DOCSIS" / "IEEE-802.3"/ "IEEE-802.3a" /
                               "IEEE-802.3e" / "IEEE-802.3i" /
                               "IEEE-802.3j" / "IEEE-802.3u" /
                               "IEEE-802.3ab" / "IEEE-802.3ae" /
                               "IEEE-802.3ak" / "IEEE-802.3ah" /
                               "IEEE-802.3aq" / "IEEE-802.3an" /
                               "IEEE-802.3y"/ "IEEE-802.3z" /"GSTN"/
                               "3GPP-E-UTRAN-FDD" / "3GPP-E-UTRAN-TDD" /
                               "3GPP2-1X-Femto" / "GPON" / " XGPON1" /
                               token
      access-class           = "3GPP-GERAN" / "3GPP-UTRAN" /  "3GPP-E-UTRAN"/
                               "3GPP-WLAN" / "3GPP-GAN" / "3GPP-HSPA"
      np                     = "network-provided"
      access-info            = cgi-3gpp / utran-cell-id-3gpp /
                               dsl-location / i-wlan-node-id /
                               ci-3gpp2 / eth-location /
                               ci-3gpp2-femto / fiber-location /
                                np / gstn-location /
                               extension-access-info
      extension-access-info  = gen-value
      cgi-3gpp               = "cgi-3gpp" EQUAL
                               (token / quoted-string)
      utran-cell-id-3gpp     = "utran-cell-id-3gpp" EQUAL
                               (token / quoted-string)
      i-wlan-node-id         = "i-wlan-node-id" EQUAL
                                   (token / quoted-string)
      dsl-location           = "dsl-location" EQUAL
                                   (token / quoted-string)
      eth-location           = "eth-location" EQUAL
                                   (token / quoted-string)
      ci-3gpp2               = "ci-3gpp2" EQUAL
                                   (token / quoted-string)
      ci-3gpp2-femto         = "ci-3gpp2-femto" EQUAL
                                    (token / quoted-string)
      gstn-location          = "gstn-location" EQUAL
                                    (token / quoted-string)



Drage, et al.             Expires July 12, 2012                [Page 30]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   The access-info may contain additional information relating to the
   access network.  The values for "cgi-3gpp", "utran-cell-id-3gpp",
   "i-wlan-node-id", "dsl-location" and "ci-3gpp2", "ci-3gpp2-femto" and
   "gstn-location" are defined in 3GPP TS 24.229 [TS24.229].

5.5.  P-Charging-Function-Addresses header syntax

   The syntax for the P-Charging-Function-Addresses header is described
   as follows:

P-Charging-Addr        = "P-Charging-Function-Addresses" HCOLON
                                          charge-addr-params *(COMMA charge-addr-params)
      charge-addr-params     = charge-addr-parm *(SEMI charge-addr-parm)
      charge-addr-param     = ccf / ecf / cdf /odf / generic-param
      ccf                    = "ccf" EQUAL gen-value
      ecf                    = "ecf" EQUAL gen-value
      ccf-2                 = "ccf-2" EQUAL gen-value
      ecf-2                 = "ecf-2" EQUAL gen-value


5.6.  P-Charging-Vector header syntax

   The syntax for the P-Charging-Vector header is described as follows:


      P-Charging-Vector         = "P-Charging-Vector" HCOLON icid-value
                                  *(SEMI charge-params)
      charge-params             = icid-gen-addr / orig-ioi /transit-ioi /
                                  term-ioi / generic-param
      icid-value                = "icid-value" EQUAL gen-value
      icid-gen-addr             = "icid-generated-at" EQUAL host
      orig-ioi                  = "orig-ioi" EQUAL gen-value
      term-ioi                  = "term-ioi" EQUAL gen-value
      transit-ioi               = "transit-ioi" EQUAL transit-ioi-list
      transit-ioi-list          = DQUOTE transit-ioi-param *(COMMA transit-ioi-param) DQUOTE
      transit-ioi-param         = transit-ioi-indexed-value / transit-ioi-void-value
      transit-ioi-indexed-value = transit-ioi-name DOT transit-ioi-index
      transit-ioi-name          = ALPHA * (ALPHA / DIGIT)
      transit-ioi-index         = 1*DIGIT
      transit-ioi-void-value    = "void"



   The P-Charging-Vector contains icid-value mandatory parameter.  The
   icid-value represents the IMS charging ID, and contains an identifier
   used for correlating charging records and events.  The first proxy
   that receives the request generates this value.




Drage, et al.             Expires July 12, 2012                [Page 31]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   The icid-gen-addr parameter contains the host name or IP address of
   the proxy that generated the icid-value.

   The orig-ioi and term-ioi parameters represent, respectively, the
   originating and terminating interoperator identifiers.  They are used
   to correlate charging records between different operators.  The
   originating ioi represents the network responsible for the charging
   records in the originating part of the session or standalone request.
   Similarly, the terminating ioi represents the network responsible for
   the charging records in the terminating part of the session or
   standalone request.

   The transit-ioi parameters represent, respectively, the transit
   interoperator identifier.  It is used to correlate charging records
   between different networks.  The transit-ioi represents the network
   responsible for the records in the transit part of the session or
   standalone request.  The transit-ioi parameters represent,
   respectively, the transit interoperator identifier.  It is used to
   correlate charging records between different operators.  The transit
   ioi represents the network responsible for the records in the transit
   part of the session or standalone request.

   Applications using the P-Charging-Vector header within their own
   applicability are allowed to define generic-param extensions without
   further reference to the IETF specification process.

5.7.  Table of new headers

   Table 1 extends the headers defined in this document to Table 2 in
   SIP [RFC3261], Section 7.1 of the SIP-specific event notification
   [RFC3265], tables 1 and 2 in the SIP INFO method [RFC2976], tables 1
   and 2 in Reliability of provisional responses in SIP [RFC3262],
   tables 1 and 2 in the SIP UPDATE method [RFC3311], tables 1 and 2 in
   the SIP extension for Instant Messaging [RFC3428], table 1 in the SIP
   REFER method [RFC3515], and table 3 in the SIP PUBLISH method
   [RFC3903]:















Drage, et al.             Expires July 12, 2012                [Page 32]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   Header field          where  proxy  ACK BYE CAN INV OPT REG PUB
      _______________________________________________________________
      P-Associated-URI       2xx           -   -   -   -   -   o   -
      P-Called-Party-ID       R     amr    -   -   -   o   o   -   o
      P-Visited-Network-ID    R     ad     -   -   -   o   o   o   o
      P-Access-Network-Info         adr    -   o   -   o   o   o   o
      P-Charging-Vector             admr   -   o   -   o   o   o   o
      P-Charging-Function-          adr    -   o   -   o   o   o   o
           Addresses

      Header field                        SUB NOT PRA INF UPD MSG REF
      _______________________________________________________________
      P-Associated-URI                     -   -   -   -   -   -   -
      P-Called-Party-ID                    o   -   -   -   -   o   o
      P-Visited-Network-ID                 o   -   -   -   -   o   o
      P-Access-Network-Info                o   o   o   o   o   o   o
      P-Charging-Vector                    o   o   o   o   o   o   o
      P-Charging-Function-                 o   o   o   o   o   o   o
        Addresses

                          Table 1: Header field support



6.  Security Considerations

6.1.  P-Associated-URI

   The information returned in the P-Associated-URI header is not viewed
   as particularly sensitive.  Rather, it is simply informational in
   nature, providing openness to the UAC with regard to the automatic
   association performed by the registrar.  If end-to-end protection is
   not used at the SIP layer, it is possible for proxies between the
   registrar and the UA to modify the contents of the header value.
   This attack, while potentially annoying, should not have significant
   impacts.

   The lack of encryption, either end-to-end or hop-by-hop, may lead to
   leak some privacy regarding the list of authorized identities.  For
   instance, a user who registers an address-of-record of
   sip:user1@example.com may get another SIP URI associated as
   sip:first.last@example.com returned in the P-Associated-URI header
   value.  An eavesdropper could collect this information.  If the user
   does not want to disclose the associated URIs, the eavesdropper could
   have gain access to private URIs.  Therefore it is RECOMMENDED that
   this extension is used in a secured environment, where encryption of
   SIP messages is provided either end-to-end or hop-by-hop.




Drage, et al.             Expires July 12, 2012                [Page 33]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


6.2.  P-Called-Party-ID

   Due to the nature of the P-Called-Party-ID header, this header does
   not introduce any significant security concern.  It is possible for
   an attacker to modify the contents of the header.  However, this
   modification will not cause any harm to the session establishment.

   An eavesdropper may collect the list of identities a user is
   registered.  This may have privacy implications.  To mitigate this
   problem, this extension SHOULD only be used in a secured environment,
   where encryption of SIP messages is provided either end-to-end or
   hop-by-hop.

6.3.  P-Visited-Network-ID

   The P-Visited-Network-ID header assumes that there is trust
   relationship between a home network and one or more transited visited
   networks.  It is possible for other proxies between the proxy in the
   visited network that inserts the header, and the registrar or the
   home proxy, to modify the value of P-Visited-Network-ID header.
   Therefore intermediaries participating in this mechanism MUST apply a
   hop-by-hop integrity protection mechanism such us IPsec or other
   available mechanisms in order to prevent such attacks.

6.4.  P-Access-Network-Info

   A Trust Domain is formally defined in the Short term requirements for
   Network Asserted Identity [RFC3324] document.  For the purpose of
   this document, we refer to the 3GPP trust domain as the collection of
   SIP proxies and application servers that are operated by a 3GPP
   network operator and are compliant with the requirements expressed in
   3GPP TS 24.229 [TS24.229].

   This extension assumes that the access network is trusted by the UA
   (because the UA's home network has a trust relationship with the
   access network), as described earlier in this document.

   This extension assumes that the information added to the header by
   the UAC should be sent only to trusted entities and should not be
   used outside of the trusted administrative network domain.

   The SIP proxy that provides services to the user, utilizes the
   information contained in this header to provide additional services
   and UAs are expected to provide correct information.  However, there
   are no security problems resulting from a UA inserting incorrect
   information.  Networks providing services based on the information
   carried in the P-Access-Network-Info header will therefore need to
   trust the UA sending the information.  A rogue UA sending false



Drage, et al.             Expires July 12, 2012                [Page 34]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   access network information will do no more harm than to restrict the
   user from using certain services.

   The mechanism provided in this document is designed primarily for
   private systems like 3GPP.  Most security requirements are met by way
   of private standardized solutions.

   For instance, 3GPP will use the P-Access-Network-Info header to carry
   relatively sensitive information like the cell ID.  Therefore the
   information MUST NOT be sent outside of the 3GPP domain.

   The UA is aware - if it is a 3GPP UA - that it is operating within a
   trusted domain.

   The 3GPP UA is aware of whether or not a secure association to the
   home network domain for transporting SIP signaling, is currently
   available, and as such the sensitive information carried in the
   P-Access-Network-Info header SHOULD NOT be sent in any initial
   unauthenticated and unprotected requests (e.g., REGISTER).

   Any UA that is using this extension and is not part of a private
   trusted domain should not consider the mechanism as secure and as
   such SHOULD NOT send sensitive information in the P-Access-Network-
   Info header.

   Any proxy that is operating in a private trust domain where the
   P-Access-Network-Info header is supported is required to delete the
   header, if it is present, from any message prior to forwarding it
   outside of the trusted domain.

   Therefore, a network that requires its UA to send information in the
   P-Access-Network-Info header must ensure that either that information
   is not of a sensitive nature or that the information is not sent
   outside of the trust domain.

   A proxy receiving a message containing the P-Access-Network-Info
   header from a non-trusted entity is not able to guarantee the
   validity of the contents.

6.5.  P-Charging-Function-Addresses

   It is expected as normal behavior that proxies within a closed
   network will modify the values of the P-Charging-Function-Addresses
   and insert it into a SIP request or response.  However, these proxies
   that share this information MUST have a trust relationship.

   If an untrusted entity were inserted between trusted entities, it
   could potentially substitute a different charging function address.



Drage, et al.             Expires July 12, 2012                [Page 35]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   Therefore, an integrity protection mechanism such as IPsec or other
   available mechanisms MUST be applied in order to prevent such
   attacks.  Since each trusted proxy may need to view or modify the
   values in the P-Charging-Function-Addresses header, the protection
   should be applied on a hop-by-hop basis.

6.6.  P-Charging-Vector

   It is expected as normal behavior that proxies within a closed
   network will modify the values of the P-Charging-Vector and insert it
   into a SIP request or response.  However, these proxies that share
   this information MUST have a trust relationship.

   If an untrusted entity were inserted between trusted entities, it
   could potentially interfere with the charging correlation mechanism.
   Therefore, an integrity protection mechanism such as IPsec or other
   available mechanisms MUST be applied in order to prevent such
   attacks.  Since each trusted proxy may need to view or modify the
   values in the P-Charging-Vector header, the protection should be
   applied on a hop-by-hop basis.


7.  IANA Considerations

   This document defines several private SIP extension header fields
   (beginning with the prefix "P-" ).

   These extension headers have been included in the registry of SIP
   header fields defined in SIP [RFC3261].  Expert review as required
   for this process was provided by the SIP Working Group.

   The following extensions are registered as private extension header
   fields:


















Drage, et al.             Expires July 12, 2012                [Page 36]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


      RFC Number:         RFC3455
      Header Field Name:  P-Associated-URI
      Compact Form:       none


      RFC Number:         RFC3455
      Header Field Name:  P-Called-Party-ID
      Compact Form:       none


      RFC Number:         RFC3455
      Header Field Name:  P-Visited-Network-ID
      Compact Form:       none


      RFC Number:         RFC3455
      Header Field Name:  P-Access-Network-Info
      Compact Form:       none


      RFC Number:         RFC3455
      Header Field Name:  P-Charging-Function-Addresses
      Compact Form:       none


      RFC Number:         RFC3455
      Header Field Name:  P-Charging-Vector
      Compact Form:       none


8.  Contributors and Acknowledgements

   The extensions described in this RFC 3455 were originally specified
   in several documents.  Miguel Garcia-Martin authored the
   P-Associated-URI, P-Called-Party-ID, and P-Visited-Network-ID
   headers.  Duncan Mills authored the P-Access-Network-Info header.
   Eric Henrikson authored the P-Charging-Function-Addresses and
   P-Charging-Vector headers.  Rohan Mahy assisted in the incorporation
   of these extensions into a single document.

   The listed authors of RFC 3455 were Miguel Garcia-Martin, Eric
   Henrikson and Duncan Mills.

   The RFC 3455 authors thanked Andrew Allen, Gabor Bajko, Gonzalo
   Camarillo, Keith Drage, Georg Mayer, Dean Willis, Rohan Mahy,
   Jonathan Rosenberg, Ya-Ching Tan and the 3GPP CN1 WG members for
   their comments on RFC 3455.




Drage, et al.             Expires July 12, 2012                [Page 37]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


9.  Appendix: Changes from RFC 3455

   1.   Procedures for the P-Associated-URI header at a proxy.  RFC3455
        indicates that it defines no procedures for the P-Associated-URI
        header at a proxy.  What is implicitly meant here is that the
        proxy does not add, read, modify or delete the header, and
        therefore RFC3261 proxy procedures only apply to the header.

   2.   P-Called-Party-ID header and the History-Info header: At the
        time RFC3455 was drafted, the History-Info header was a long way
        from specification; this header has now been specified and
        approved in RFC 4244.  It is acknowledged that the History-Info
        header will provide equivalent coverage to that of the P-Called-
        Party-ID header.  However the P-Called-Party-ID header is used
        entirely within the 3GPP system and does not appear to SIP
        entities outside that of a single 3GPP operator.  Additionally
        the P-Called-Party-ID header has been defined within 3GPP
        systems since release 5, and therefore it is realistic to expect
        implementations to be already released to the field.  It is
        therefore considered that replacement of the P-Called-Party-ID
        header within 3GPP systems causes more issues that it solves,
        and therefore the update of RFC3455 to remove the P-Called-
        Party-ID header will not be addressed.  However it is
        recommended that any new usage of this type of functionality
        should use the History-Info header rather than the P-Called-
        Party-ID header.

   3.   Procedures at the UA for the P-Charging-Function Addresses
        header: The text in section 4.5.2.1 of RFC3455 [3] does not
        adequately take into account procedures for UAs located inside
        the private network, e.g. as gateways and suchlike which may
        play a full part in network charging procedures.  Section
        4.5.2.1 is replaced with the following text: "This document does
        not specify any procedure at a UA located outside the
        administrative domain of a private network, with regard to the
        P-Charging-Function-Addresses header.  Such UAs need not
        understand this header.  However, it might be possible that a UA
        is located within the administrative domain of a private network
        (e.g., a PSTN gateway, or conference mixer), and it may have
        access to the addresses of the charging entities.  In this
        cases, a UA MAY insert the P-Charging-Function-Addresses header
        in a SIP request or response when the next hop for the message
        is a proxy or UA located in the same administrative domain.
        Similar such a UA may use the contents of the P-Charging-
        Function-Addresses header in communicating with the charging
        entities."





Drage, et al.             Expires July 12, 2012                [Page 38]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   4.   The text in section 4.6.2.1 of RFC3455 [3] does not adequately
        take into account procedures for UAs located inside the private
        network, e.g. as gateways and suchlike which may play a full
        part in network charging procedures.  Section 4.6.2.1 is
        replaced with the following text: "This document does not
        specify any procedure at a UA located outside the
        admininstrative domain of a private network, with regard to the
        P-Charging-Vector header.  UAs need not understand this header.
        However, it might be possible that a UA is located within the
        administrative domain of a private network (e.g., a PSTN
        gateway, or conference mixer), and it may it may interact with
        the charging entities.  In this cases, a UA MAY insert the
        P-Charging-Vector header in a SIP request or response when the
        next hop for the message is a proxy or UA located in the same
        administrative domain.  Similar such a UA may use the contents
        of the P-Charging-Vector header in communicating with the
        charging entities."

   5.   Recognition of additional values of access technology in the
        P-Access-Network-Info header: A number of new access
        technologies are contemplated in 3GPP, and the reuse of IMS to
        support Next Generation Networks (NGN) is also resulting in new
        access technologies.  Values for access technologies are defined
        explicitly in RFC3455 [3] and no IANA procedures are defined to
        maintain a separate registry.  In particular the new values:
        "IEEE 802.11", "IEEE-802.11g", "IEEE-802.11n", "ADSL" / "ADSL2",
        "ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL",
        "IDSL", "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-
        802.3i", "IEEE-802.3j", "IEEE-802.3u", "IEEE-802.3ab", "IEEE-
        802.3ae", "IEEE-802.3ak", IEEE-802.3aq", "IEEE-802.3an", "IEEE-
        802.3y", "IEEE-802.3z", and "IEEE-802.3y" are defined.

   6.   Replacement of existing value of access technology in the
        P-Access-Network-Info header: The value of "3GPP-CDMA2000" was
        replaced long ago in 3GPP2 by three new values: "3GPP2-1X",
        "3GPP2-1X-HRPD", "3GPP2-UMB".  It is not believed that there was
        any deployment of the "3GPP-CDMA2000" value.

   7.   Network provided P-Access-Network-Info header: The P-Access-
        Network-Info header may additionally be provided by proxies
        within the network.  This does not impact the values provided by
        a UA, rather the header is repeated.  Such values are identified
        by the string "network-provided".  A special class of values are
        defined for use here, as the same granularity of values may not
        be possible as for those available from the UA: "3GPP-GERAN",
        "3GPP-UTRAN", "3GPP-WLAN", "3GPP-GAN" and "3GPP-HSPA".  Outbound
        proxies remove and P-Access-Network-Info header fields
        containing the "network-provided" value.



Drage, et al.             Expires July 12, 2012                [Page 39]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   8.   Definition of additional parameters to the P-Charging-Vector
        header: Section 5.6 of RFC3455 [3] defines the syntax of the
        P-Charging-Vector header.  Additional parameters were considered
        too application specific for specification in RFC3455 [3], but
        it was acknowledged that they would exist, and indeed additional
        specification of such parameters, relating to specific access
        technologies, has occurred in 3GPP.  This update therefore
        defines that applications using the P-Charging-Vector header
        within their own applicability are allowed to define generic-
        param extensions without further reference to the IETF
        specification process.

   9.   PUBLISH method added to table 1.

   10.  Referencing: RFC 3427 deleted from references as not used within
        the document.  Various informative references to work in
        progress now replaced with appropriate RFC number.  References
        to 3GPP TS 32.200 replaced by references to 3GPP TS 32.240
        [TS32.240], which is the successor specification.  References to
        3GPP TS 32.225 replaced by references to 3GPP TS 32.260
        [TS32.260], which is the successor specification.  Referencing
        style changed to symbolic references.  Dates have been removed
        from all 3GPP references (i.e. latest version applies).

   11.  Various editorial changes in alignment with style used in RFC
        3261 such as placing response code text in parentheses, and
        using words "request" and "response" in association with method
        names.


10.  Appendix: Summary of changes between different versions

   NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION BEFORE PUBLICATION.

10.1.  Changes between RFC 3455 and -00

   1.  Procedures for the P-Associated-URI header at a proxy.  RFC3455
       indicates that it defines no procedures for the P-Associated-URI
       header at a proxy.  What is implicitly meant here is that the
       proxy does not add, read, modify or delete the header, and
       therefore RFC3261 proxy procedures only apply to the header.

   2.  P-Called-Party-ID header and the History-Info header: At the time
       RFC3455 was drafted, the History-Info header was a long way from
       specification; this header has now been specified and approved in
       RFC 4244.  It is acknowledged that the History-Info header will
       provide equivalent coverage to that of the P-Called-Party-ID
       header.  However the P-Called-Party-ID header is used entirely



Drage, et al.             Expires July 12, 2012                [Page 40]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


       within the 3GPP system and does not appear to SIP entities
       outside that of a single 3GPP operator.  Additionally the
       P-Called-Party-ID header has been defined within 3GPP systems
       since release 5, and therefore it is realistic to expect
       implementations to be already released to the field.  It is
       therefore considered that replacement of the P-Called-Party-ID
       header within 3GPP systems causes more issues that it solves, and
       therefore the update of RFC3455 to remove the P-Called-Party-ID
       header will not be addressed.  However it is recommended that any
       new usage of this type of functionality should use the History-
       Info header rather than the P-Called-Party-ID header.

   3.  Recognition of additional values of access technology in the
       P-Access-Network-Info header: the new values: "IEEE 802.11e",
       "IEEE-802.11g" are defined.

   4.  Procedures at the UA for the P-Charging-Function Addresses
       header: The text in section 4.5.2.1 of RFC3455 [3] does not
       adequately take into account procedures for UAs located inside
       the private network, e.g. as gateways and suchlike which may play
       a full part in network charging procedures.  Section 4.5.2.1 is
       replaced with the following text: "This document does not specify
       any procedure at a UA located outside the administrative domain
       of a private network, with regard to the P-Charging-Function-
       Addresses header.  Such UAs need not understand this header.
       However, it might be possible that a UA is located within the
       administrative domain of a private network (e.g., a PSTN gateway,
       or conference mixer), and it may have access to the addresses of
       the charging entities.  In this cases, a UA MAY insert the
       P-Charging-Function-Addresses header in a SIP request or response
       when the next hop for the message is a proxy or UA located in the
       same administrative domain.  Similar such a UA may use the
       contents of the P-Charging-Function-Addresses header in
       communicating with the charging entities."

   5.  The text in section 4.6.2.1 of RFC3455 [3] does not adequately
       take into account procedures for UAs located inside the private
       network, e.g. as gateways and suchlike which may play a full part
       in network charging procedures.  Section 4.6.2.1 is replaced with
       the following text: "This document does not specify any procedure
       at a UA located outside the admininstrative domain of a private
       network, with regard to the P-Charging-Vector header.  UAs need
       not understand this header.  However, it might be possible that a
       UA is located within the administrative domain of a private
       network (e.g., a PSTN gateway, or conference mixer), and it may
       it may interact with the charging entities.  In this cases, a UA
       MAY insert the P-Charging-Vector header in a SIP request or
       response when the next hop for the message is a proxy or UA



Drage, et al.             Expires July 12, 2012                [Page 41]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


       located in the same administrative domain.  Similar such a UA may
       use the contents of the P-Charging-Vector header in communicating
       with the charging entities."

   6.  Definition of additional parameters to the P-Charging-Vector
       header: Section 5.6 of RFC3455 [3] defines the syntax of the
       P-Charging-Vector header.  Additional parameters were considered
       too application specific for specification in RFC3455 [3], but it
       was acknowledged that they would exist, and indeed additional
       specification of such parameters, relating to specific access
       technologies, has occurred in 3GPP.  This update therefore
       defines that applications using the P-Charging-Vector header
       within their own applicability are allowed to define generic-
       param extensions without further reference to the IETF
       specification process.

10.2.  Changes between -00 and -01

   1.  Document changed to a complete RFC in its own right, specifying
       all the new headers originally specified in RFC 3455 in full,
       rather than a list of proposed modifications to RFC 3455.  Change
       due to comments to this effect, and also due to the replacement
       of RFC 3325 is also following this approach.  Issues from -00
       version incorporated into full text.

   2.  Removal of additional values of access technology in the
       P-Access-Network-Info header: values "IEEE 802.11e" is removed.

   3.  Recognition of additional values of access technology in the
       P-Access-Network-Info header: A number of new access technologies
       are contemplated in 3GPP, and the reuse of IMS to support Next
       Generation Networks (NGN) is also resulting in new access
       technologies.  Values for access technologies are defined
       explicitly in RFC3455 [3] and no IANA procedures are defined to
       maintain a separate registry.  In particular the new values:
       "IEEE 802.11", "IEEE-802.11n", "ADSL" / "ADSL2", "ADSL2+",
       "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", "IDSL",
       "IEEE-802.3", "IEEE-802.3a", "IEEE-802.3e", "IEEE-802.3i", "IEEE-
       802.3j", "IEEE-802.3u", "IEEE-802.3ab", "IEEE-802.3ae", "IEEE-
       802.3ak", IEEE-802.3aq", "IEEE-802.3an", "IEEE-802.3y", "IEEE-
       802.3z", and "IEEE-802.3y" are defined.

   4.  Replacement of existing value of access technology in the
       P-Access-Network-Info header: The value of "3GPP-CDMA2000" was
       replaced long ago in 3GPP2 by three new values: "3GPP2-1X",
       "3GPP2-1X-HRPD", "3GPP2-UMB".  It is not believed that there was
       any deployment of the "3GPP-CDMA2000" value.




Drage, et al.             Expires July 12, 2012                [Page 42]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


   5.  Network provided P-Access-Network-Info header: The P-Access-
       Network-Info header may additionally be provided by proxies
       within the network.  This does not impact the values provided by
       a UA, rather the header is repeated.  Such values are identified
       by the string "network-provided".  A special class of values are
       defined for use here, as the same granularity of values may not
       be possible as for those available from the UA: "3GPP-GERAN",
       "3GPP-UTRAN", "3GPP-WLAN", "3GPP-GAN" and "3GPP-HSPA".

10.3.  Changes between -01 and -02

   1.  Addition of values ccf-2 and ecf-2.  Note that the naming of ccf
       and ecf was changed within 3GPP equivalent to cdf (Charging Data
       Function) and ocf (Online Charging Function), but nevertheless
       this is a documentationissue within 24.229 [TS24.229]).

   2.  By text description in 4.1.2.1 and 4.1.2.2, P-Associated-URI may
       have zero URI.  But refer to the syntax description part in 5.1,
       it seams the header would have at least one URI.  The new text
       reflects that is allowed to have at minimum one associated uri
       within the P-Associated-URI.

   3.  Section 4.1.2.2 generalisation of URI so that not only SIP/SIP
       URI's are only allowed.  This alings the whole section 4.1.2
       where only URI is mentioned.

10.3.1.  Changes between -02 and -03

   1.  Section 4.6 additionn of transit-ioi procedure

   2.  New Section 4.6.3 additionn of transit-ioi procedure

   3.  Section 5.6 Addition of syntax for transit-ioi and descriptive
       text

   4.  Section 5.4 new Value "IEEE-802.3ah" added


11.  References

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




Drage, et al.             Expires July 12, 2012                [Page 43]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


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

11.2.  Informative References

   [RFC2976]  Donovan, S., "The SIP INFO Method", RFC 2976,
              October 2000.

   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, June 2002.

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

   [RFC3311]  Rosenberg, J., "The Session Initiation Protocol (SIP)
              UPDATE Method", RFC 3311, October 2002.

   [RFC3324]  Watson, M., "Short Term Requirements for Network Asserted
              Identity", RFC 3324, November 2002.

   [RFC3428]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
              and D. Gurle, "Session Initiation Protocol (SIP) Extension
              for Instant Messaging", RFC 3428, December 2002.

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, April 2003.

   [RFC3903]  Niemi, A., "Session Initiation Protocol (SIP) Extension
              for Event State Publication", RFC 3903, October 2004.

   [RFC4083]  Garcia-Martin, M., "Input 3rd-Generation Partnership
              Project (3GPP) Release 5 Requirements on the Session
              Initiation Protocol (SIP)", RFC 4083, May 2005.

   [RFC4244]  Barnes, M., "An Extension to the Session Initiation
              Protocol (SIP) for Request History Information", RFC 4244,
              November 2005.

   [TS23.228]
              3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP
              TS 23.228 10.4.0, March 2011.

   [TS24.229]
              3GPP, "IP multimedia call control protocol based on
              Session Initiation Protocol (SIP) and Session Description



Drage, et al.             Expires July 12, 2012                [Page 44]


Internet-Draft        3GPP SIP P-Header Extensions          January 2012


              Protocol (SDP); Stage 3", 3GPP TS 24.229 10.3.0,
              April 2011.

   [TS32.240]
              3GPP, "Telecommunication management; Charging management;
              Charging architecture and principles", 3GPP TS 32.240
              10.1.0, April 2011.

   [TS32.260]
              3GPP, "Telecommunication management; Charging management;
              IP Multimedia Subsystem (IMS) charging", 3GPP TS 32.260
              10.3.0, April 2011.


Authors' Addresses

   Keith Drage
   Alcatel-Lucent
   Quadrant, StoneHill Green, Westlea
   Swindon, Wilts
   UK

   Email: drage@alcatel-lucent.com


   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas,   02420
   Finland

   Phone:
   Email: rchrister.holmberg@ericsson.com


   Roland Jesske
   Deutsche Telekom
   Heinrich-Hertz-Strasse 3-7
   Darmstadt,   64307
   Germany

   Phone: +4961515812766
   Email: r.jesske@telekom.de








Drage, et al.             Expires July 12, 2012                [Page 45]