tech-invite   World Map
3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search     Home

RFC 7315

 
 
 

Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP

Part 2 of 2, p. 28 to 43
Prev RFC Part

 


prevText      Top      ToC       Page 28 
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
   5234 [RFC5234].  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 [RFC5234] to
   understand this document.

Top      Up      ToC       Page 29 
5.1.  P-Associated-URI Header Syntax

   The syntax of the P-Associated-URI header field 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 field 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 field 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 field is described as
   follows:

      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" /
                               "IEEE-802.3" / "IEEE-802.3a" /
                               "IEEE-802.3ab" / "IEEE-802.3ae" /
                               "IEEE-802.3ak" / "IEEE-802.3ah" /

Top      Up      ToC       Page 30 
                               "IEEE-802.3aq" / "IEEE-802.3an" /
                               "IEEE-802.3e" / "IEEE-802.3i" /
                               "IEEE-802.3j" / "IEEE-802.3u" /
                               "IEEE-802.3y" / "IEEE-802.3z" /
                               "3GPP-GERAN" /
                               "3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" /
                               "3GPP-E-UTRAN-FDD" / "3GPP-E-UTRAN-TDD" /
                               "3GPP2-1X-Femto" / "3GPP2-UMB" /
                               "3GPP2-1X-HRPD" / "3GPP2-1X" /
                               "ADSL" / "ADSL2" / "ADSL2+" / "RADSL" /
                               "SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" /
                               "VDSL" / "IDSL" /
                               "DOCSIS" / "GSTN" / "GPON" / " XGPON1" /
                               "DVB-RCS2" / token
      access-class           = "3GPP-GERAN" /  "3GPP-UTRAN" /
                               "3GPP-E-UTRAN" / "3GPP-WLAN" /
                               "3GPP-GAN" / "3GPP-HSPA" /
                               "3GPP2" / token
      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 /local-time-zone /
                               dvb-rcs2-node-id / extension-access-info
      np                     = "network-provided"
      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)
      fiber-location         = "fiber-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)
      dvb-rcs2-node-id       = "dvb-rcs2-node-id" EQUAL
                                     quoted-string
      local-time-zone        = "local-time-zone"  EQUAL
                                    quoted-string

Top      Up      ToC       Page 31 
      operator-specific-GI   = "operator-specific-GI" EQUAL
                                    (token / quoted-string)
      utran-sai-3gpp         = "utran-sai-3gpp" EQUAL
                                    (token / quoted-string)

   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", "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 field is
   described as follows:

  P-Charging-Addresses = "P-Charging-Function-Addresses" HCOLON
                          charge-addr-params *(COMMA charge-addr-params)
  charge-addr-params   = charge-addr-param *(SEMI charge-addr-param)
  charge-addr-param    = ccf / ecf / ccf-2 /ecf-2 / 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

   The P-Charging-Function-Addresses header field contains one or two
   addresses of the ECF (ecf and ecf-2) or CCF (ccf and ccf-2).  The
   first address of the sequence is ccf or ecf.  If the first address of
   the sequence is not available, then the next address (ccf-2 or ecf-2)
   MUST be used if available.

Top      Up      ToC       Page 32 
5.6.  P-Charging-Vector Header Syntax

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

      P-Charging-Vector  = "P-Charging-Vector" HCOLON icid-value
                                  *(SEMI charge-params)
      charge-params      = icid-gen-addr / orig-ioi / term-ioi /
                           transit-ioi / related-icid /
                           related-icid-gen-addr / 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 "."
                                                transit-ioi-index
      transit-ioi-name          = ALPHA *(ALPHA / DIGIT)
      transit-ioi-index         = 1*DIGIT
      transit-ioi-void-value    = "void"
      related-icid              = "related-icid" EQUAL gen-value
      related-icid-gen-addr     = "related-icid-generated-at" EQUAL host

   The P-Charging-Vector header field contains icid-value as a 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.

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

   The orig-ioi and term-ioi parameters contain 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.

Top      Up      ToC       Page 33 
   The transit-ioi parameter contains values with each of them,
   respectively, representing a 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 related-icid parameter contains the icid-value of a related
   charging record when more than one call leg is associated with one
   session.  This optional parameter is used for correlation of charging
   information between two or more call legs related to the same remote-
   end dialog.

   The related-icid-gen-addr parameter contains the hostname or IP
   address of the proxy that generated the related-icid.

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

5.7.  New Headers

   The P-Associated-URI header field can appear in SIP REGISTER method
   and 2xx resonses.  The P-Called-Party-ID header field can appear in
   SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all
   responses.  The P-Visited-Network-ID header field can appear in all
   SIP methods except ACK, BYE, and CANCEL and all responses.  The
   P-Access-Network-Info header field can appear in all SIP methods
   except ACK and CANCEL.  The P-Charging-Vector header field can appear
   in all SIP methods except CANCEL.  The P-Charging-Function-Addresses
   header field can appear in all SIP methods except ACK and CANCEL.

6.  Security Considerations

6.1.  P-Associated-URI Header Field

   The information returned in the P-Associated-URI header field 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.

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

Top      Up      ToC       Page 34 
   An eavesdropper could possibly collect the list of identities a user
   is registered.  This can 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 and where a trust relationship equivalent with that
   defined in RFC 3325 [RFC3325] between entities exists.  That is, the
   privacy of the user relies on the other entities in the session not
   disclosing information that they have learned about the user.

   While the P-Associated-URI header field value allows the implicit
   registration of a bundle of URIs with one REGISTER Message, the
   impact of security using the P-Associated-URI header field is no
   higher than using separate REGISTER messages for each of the URIs.

6.2.  P-Called-Party-ID Header Field

   Due to the nature of the P-Called-Party-ID header field, 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 could possibly collect the list of identities a user
   has registered.  This can 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.

   Normally, within a 3GPP environment, the P-Called-Party-ID is not
   sent towards end users but may be exchanged between carriers where
   other security mechanisms than SIP encryption are used.

6.3.  P-Visited-Network-ID Header Field

   The P-Visited-Network-ID header field 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 field.
   Therefore, intermediaries participating in this mechanism MUST apply
   a hop-by-hop integrity-protection mechanism such as IPsec or other
   available mechanisms in order to prevent such attacks.

Top      Up      ToC       Page 35 
6.4.  P-Access-Network-Info Header Field

   A Trust Domain is formally defined in RFC 3324 [RFC3324].  For the
   purposes 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 MUST 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 field will therefore need
   to trust the UA sending the information.  A rogue UA sending false
   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 field 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 field MUST 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, MUST NOT send sensitive information in the P-Access-Network-
   Info header field.

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

   A proxy receiving a message containing the P-Access-Network-Info
   header field from an untrusted entity is not able to guarantee the
   validity of the contents.  Thus, this content SHOULD be deleted based
   on local policy.

6.5.  P-Charging-Function-Addresses Header Field

   It is expected as normal behavior that proxies within a closed
   network will modify the values of the P-Charging-Function-Addresses
   header field and insert it into a SIP request or response.  However,
   the 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.
   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 field, the
   protection should be applied on a hop-by-hop basis.

6.6.  P-Charging-Vector Header Field

   It is expected as normal behavior that proxies within a closed
   network will modify the values of the P-Charging-Vector header field
   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 field, the protection should
   be applied on a hop-by-hop basis.

Top      Up      ToC       Page 37 
7.  IANA Considerations

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

   This document obsoletes [RFC3455] but uses the same SIP header field
   names.  The references in the "Header Fields" registry and "Header
   Field Parameters and Parameter Values" registry have been updated to
   [RFC3455] to this document.

   The following extensions are registered as private extension header
   fields:

      Header Field Name:  P-Associated-URI
      Compact Form:       none
      Reference:          RFC 7315

      Header Field Name:  P-Called-Party-ID
      Compact Form:       none
      Reference:          RFC 7315

      Header Field Name:  P-Visited-Network-ID
      Compact Form:       none
      Reference:          RFC 7315

      Header Field Name:  P-Access-Network-Info
      Parameter Name:     ci-3gpp
      Parameter Name:     ci-3gpp2
      Parameter Name:     ci-3gpp2-femto
      Parameter Name:     dsl-location
      Parameter Name:     dvb-rcs2-node-id
      Parameter Name:     eth-location
      Parameter Name:     fiber-location
      Parameter Name:     gstn-location
      Parameter Name:     i-wlan-node-id
      Parameter Name:     local-time-zone
      Parameter Name:     operator-specific-GI
      Parameter Name:     utran-cell-id-3gpp
      Parameter Name:     utran-sai-3gpp
      Compact Form:       none
      Reference:          RFC 7315

Top      Up      ToC       Page 38 
      Header Field Name:  P-Charging-Function-Addresses
      Parameter Name:     ccf
      Parameter Name:     ccf-2
      Parameter Name:     ecf
      Parameter Name:     ecf-2
      Compact Form:       none
      Reference:          RFC 7315

      Header Field Name:  P-Charging-Vector
      Parameter Name:     icid-value
      Parameter Name:     icid-generated-at
      Parameter Name:     orig-ioi
      Parameter Name:     related-icid
      Parameter Name:     related-icid-generated-at
      Parameter Name:     term-ioi
      Parameter Name:     transit-ioi
      Compact Form:       none
      Reference:          RFC 7315

8.  Contributors and Acknowledgements

   The authors would like to thank James Yu and Atle Monrad for their
   extensive review, Dean Willis for his expert review, and Mary Barnes
   for the proto review.  The authors would like to acknowledge the
   constructive feedback and contributions provided by Peter Leis,
   Joergen Axell, and Jan Holm.

   The extensions described in [RFC3455] were originally specified in
   several documents.  Miguel Garcia-Martin authored the P-Associated-
   URI, P-Called-Party-ID, and P-Visited-Network-ID header fields.
   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 [RFC3455] were Miguel Garcia-Martin, Eric
   Henrikson and Duncan Mills.

   The [RFC3455] 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 [RFC3455].

Top      Up      ToC       Page 39 
9.  References

9.1.  Normative References

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

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

   [RFC5234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [TS24.229]   3GPP, "IP multimedia call control protocol based on
                Session Initiation Protocol (SIP) and Session
                Description Protocol (SDP); Stage 3", 3GPP TS 24.229
                12.4.0, March 2014.

9.2.  Informative References

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

   [RFC3325]    Jennings, C., Peterson, J., and M. Watson, "Private
                Extensions to the Session Initiation Protocol (SIP) for
                Asserted Identity within Trusted Networks", RFC 3325,
                November 2002.

   [RFC3455]    Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
                Header (P-Header) Extensions to the Session Initiation
                Protocol (SIP) for the 3rd-Generation Partnership
                Project (3GPP)", RFC 3455, January 2003.

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

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

   [RFC6665]    Roach, A., "SIP-Specific Event Notification", RFC 6665,
                July 2012.

Top      Up      ToC       Page 40 
   [RFC7044]    Barnes, M., Audet, F., Schubert, S., van Elburg, J., and
                C. Holmberg, "An Extension to the Session Initiation
                Protocol (SIP) for Request History Information", RFC
                7044, February 2014.

   [TS23.228]   3GPP, "P Multimedia Subsystem (IMS); Stage 2", 3GPP TS
                23.228 12.4.0, March 2014.

   [TS32.240]   3GPP, "Telecommunication management; Charging
                management; Charging architecture and principles", 3GPP
                TS 32.240 12.3.0, March 2013.

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

Top      Up      ToC       Page 41 
Appendix A.  Changes from RFC 3455

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

   2.   P-Called-Party-ID header field and the History-Info header
        field: At the time RFC 3455 was written, the History-Info header
        field was a long way from specification.  This header has now
        been specified and approved in RFC 7044.  It is acknowledged
        that the History-Info header field will provide equivalent
        coverage to that of the P-Called-Party-ID header field.
        However, the P-Called-Party-ID header field is used entirely
        within the 3GPP system and does not appear to SIP entities
        outside that of a single 3GPP operator.

   3.   Procedures at the UA for the P-Charging-Function Addresses
        header field: The text in Section 4.5.2.1 of RFC 3455 does not
        adequately take into account procedures for UAs located inside
        the private network, e.g., as gateways and such that may play a
        full part in network charging procedures.  Section 4.5.2.1 is
        replaced with new text.

   4.   The text in Section 4.6.2.1 of RFC 3455 does not adequately take
        into account procedures for UAs located inside the private
        network, e.g., as gateways and such that may play a full part in
        network charging procedures.  Section 4.6.2.1 is now replaced
        with new text.

   5.   Recognition of additional values of access technology in the
        P-Access-Network-Info header field (Section 4.4): 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 RFC 3455, 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.

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

   7.   Network-provided P-Access-Network-Info header field: The
        P-Access-Network-Info header field 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 P-Access-
        Network-Info header fields containing the "network-provided"
        value.

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

   9.   In Section 5.7, it was added that the P-Called-Party-ID can
        appear in the PUBLISH method.

   10.  Referencing: RFC 3427 was deleted from the References section as
        it was not used within the document.  Various informative
        references have now been published as RFCs and have been updated
        to include the appropriate RFC number.  References to 3GPP TS
        32.200 were replaced by references to 3GPP TS 32.240 [TS32.240],
        which is the successor specification.  References to 3GPP TS
        32.225 were replaced by references to 3GPP TS 32.260 [TS32.260],
        which is the successor specification.  The referencing style was
        changed to symbolic references.  Dates have been removed from
        all 3GPP references (i.e., latest version applies).

Top      Up      ToC       Page 43 
   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
        have been applied.

Authors' Addresses

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

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


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

   EMail: drage@alcatel-lucent.com


   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: christer.holmberg@ericsson.com