Tech-invite3GPPspaceIETF RFCsSIP
9493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7315

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

Pages: 43
Informational
Errata
Obsoletes:  3455
Updated by:  79137976
Part 2 of 2 – Pages 28 to 43
First   Prev   None

Top   ToC   RFC7315 - Page 28   prevText

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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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   ToC   RFC7315 - 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