diff options
Diffstat (limited to 'doc/rfc/rfc7315.txt')
| -rw-r--r-- | doc/rfc/rfc7315.txt | 2411 |
1 files changed, 2411 insertions, 0 deletions
diff --git a/doc/rfc/rfc7315.txt b/doc/rfc/rfc7315.txt new file mode 100644 index 0000000..4a39f2b --- /dev/null +++ b/doc/rfc/rfc7315.txt @@ -0,0 +1,2411 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Jesske +Request for Comments: 7315 Deutsche Telekom +Obsoletes: 3455 K. Drage +Category: Informational Alcatel-Lucent +ISSN: 2070-1721 C. Holmberg + Ericsson + July 2014 + + + Private Header (P-Header) Extensions + to the Session Initiation Protocol (SIP) for the 3GPP + +Abstract + + This document describes a set of private header (P-header) Session + Initiation Protocol (SIP) fields used by the 3GPP, along with their + applicability, which is limited to particular environments. The + P-header fields are used for a variety of purposes within the + networks that the partners implement, including charging and + information about the networks a call traverses. This document + obsoletes RFC 3455. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7315. + + + + + + + + + + + + + + +Jesske, et al. Informational [Page 1] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Overall Applicability ...........................................3 + 2. Conventions .....................................................3 + 3. Overview ........................................................3 + 4. SIP Private Header Fields .......................................4 + 4.1. The P-Associated-URI Header Field ..........................4 + 4.1.1. Applicability Statement for the + P-Associated-URI Header Field .......................5 + 4.1.2. Usage of the P-Associated-URI Header Field ..........5 + 4.2. The P-Called-Party-ID Header Field .........................6 + 4.2.1. Applicability Statement for the + P-Called-Party-ID Header Field .....................10 + 4.2.2. Usage of the P-Called-Party-ID Header Field ........11 + 4.3. The P-Visited-Network-ID Header Field .....................12 + 4.3.1. Applicability Statement for the + P-Visited-Network-ID Header Field ..................12 + 4.3.2. Usage of the P-Visited-Network-ID Header Field .....13 + 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 ..........18 + 4.5. The P-Charging-Function-Addresses Header Field ............19 + 4.5.1. Applicability Statement for the + P-Charging-Function-Addresses Header Field .........20 + 4.5.2. Usage of the P-Charging-Function-Addresses + Header Field .......................................21 + 4.6. The P-Charging-Vector Header Field ........................23 + 4.6.1. Applicability Statement for the + P-Charging-Vector Header Field .....................25 + 4.6.2. Usage of the P-Charging-Vector Header Field ........25 + 4.6.3. Usage of the transit-ioi ...........................27 + 4.6.4. Usage of the related-icid ..........................28 + + + +Jesske, et al. Informational [Page 2] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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 ...........................32 + 5.7. New Headers ...............................................33 + 6. Security Considerations ........................................33 + 6.1. P-Associated-URI Header Field .............................33 + 6.2. P-Called-Party-ID Header Field ............................34 + 6.3. P-Visited-Network-ID Header Field .........................34 + 6.4. P-Access-Network-Info Header Field ........................35 + 6.5. P-Charging-Function-Addresses Header Field ................36 + 6.6. P-Charging-Vector Header Field ............................36 + 7. IANA Considerations ............................................37 + 8. Contributors and Acknowledgements ..............................38 + 9. References .....................................................39 + 9.1. Normative References ......................................39 + 9.2. Informative References ....................................39 + Appendix A. Changes from RFC 3455 .................................41 + +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 + apply only to private networks and are not appropriate for use in an + Internet environment. 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 would be needed) or for which 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 3GPP uses SIP as the protocol to establish and tear down + multimedia sessions in the context of its IP Multimedia Subsystem + (IMS), as described in the 3GPP TS 23.228 [TS23.228] and 3GPP TS + + + +Jesske, et al. Informational [Page 3] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 24.229 [TS24.229]. RFC 3455 [RFC3455] defines SIP private header + extensions (referred to as P-headers) that are required by the 3GPP + specification. Note that the requirements for these extensions are + documented in RFC 4083 [RFC4083]. This document obsoletes RFC 3455 + [RFC3455]. This document updates existing P-header descriptions to + address additional requirements that are needed for 3GPP Release 11. + Each of the P-headers is described in the sections 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 SIP address-of-record. We define the P-Associated- + URI header field, used in the 200 (OK) response to a REGISTER + request. The P-Associated-URI header field contains the set of + associated URIs that are associated with the registered address-of- + record. + + In addition to the address-of-record, an associated URI is a URI that + the service provider has allocated to a user. A registrar contains + information that allows zero or more URIs to be associated with an + address-of-record. Usually, all these URIs (the address-of-record + and the associated URIs) are allocated for the usage of a particular + user. This extension to SIP allows the User Agent Client (UAC) to + know, upon a successful authenticated registration, which other URIs, + if any, the service provider has associated with an address-of-record + URI. + + Note that, in standard SIP usage [RFC3261], the registrar does not + register the associated URIs on behalf of the user. Only the + address-of-record that 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 + that can be used by the same user. + + A situation may be possible, however, in which 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 + + + +Jesske, et al. Informational [Page 4] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + field with the list of addresses-of-record that have been registered + with 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 allows a set of identities that a user can claim (in + header fields like the From header field) in requests that the UA + generates. Furthermore, it 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 header field + is explicitly an end-user-specified field. + +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 at least one 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 a P-Associated-URI + header field indicates that there are no associated URIs for the + registered address-of-record. + +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 a 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. 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 or not the associated URI is registered. + This check can be done, e.g., by populating the To header field value + in a REGISTER request sent to the registrar and without a Contact + header field. The 200 (OK) response will include a Contact header + field with the list of address-of-record that have been registered + + + + +Jesske, et al. Informational [Page 5] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + with 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 registered address-of-record. + + If the address-of-record under registration does not have any + associated URIs, the P-Associated-URI header field SHALL NOT be + included. + + Otherwise, a registrar that supports this specification MUST include + a P-Associated-URI header field in the 200 (OK) response to a + REGISTER request that contains a contact header. The header field + MUST be populated with a comma-separated list of URIs that are + associated to the address-of-record under registration. + +4.1.2.3. Procedures at the Proxy + + This header is not intended to be used by proxies -- a proxy does not + add, read, modify, or delete the header field; therefore, any proxy + MUST relay this header field unchanged. + +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 User Agent Server (UAS) identifies to which address-of-record, + out of several registered addresses-of-record, the invitation was + sent (for example, the user may be simultaneously using one personal + SIP URI and one business SIP URI to receive invitation to sessions). + The UAS can 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 + example, a user may get one business SIP URI and one personal SIP + URI. As an example of utilization, the user may make available the + business SIP URI to coworkers and may make available the personal SIP + URI to members of the family. + + + + + + + +Jesske, et al. Informational [Page 6] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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 + 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. At that time, the SIP proxy that is serving a UA gets + an INVITE request, and the SIP server retargets the SIP URI that is + present in the Request-URI, and replaces that SIP URI with the SIP + URI published by the user in the Contact header field of the REGISTER + request at registration time. + + 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 + assumption is not correct: + + 1. The session has been forwarded, redirected, etc., by previous SIP + proxies, before arriving to the proxy that 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 to 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 example, when the UA registers the address- + of-record sip:id1, the Contact header field value can be sip:id1@ua, + while the registration of the address-of-record sip:id2 can be bound + to the Contact header field value sip:id2@ua. + + The solution described above assumes that the UA explicitly registers + each of its addresses-of-record, and therefore, it has full control + over the contact address values assigned to each registration. + + + +Jesske, et al. Informational [Page 7] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + However, if the UA does not have full control of its registered + addresses-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 to the + network, by means outside of SIP, that some other addresses-of-record + 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 in which 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 UA is registering to its proxy (P1). + + 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 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. + + + + + +Jesske, et al. Informational [Page 8] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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. + + 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 / + 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: + + + + + + + + + + + + + +Jesske, et al. Informational [Page 9] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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. + +4.2.1. Applicability Statement for the P-Called-Party-ID Header Field + + The P-Called-Party-ID header field 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 especially valuable when + the UAS has registered several addresses-of-record 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. + + P-Called-Party-ID header field and the History-Info header field: At + the time RFC 3455 [RFC3455] was written, the History-Info header + field was a long way from specification. This header has now been + specified and approved in RFC 7044 [RFC7044]. 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. + + + + + + + +Jesske, et al. Informational [Page 10] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +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 the 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 can + insert a P-Called-Party-ID header field in any of the requests + indicated in Section 5.7. When included, 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 that 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, for + example, have been learned through a registration process. + + 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. + + + + +Jesske, et al. Informational [Page 11] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +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. The effect of this is 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 network 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 to the home network. This identification should be + globally unique, and it 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. + + Note that P-Visited-Network-ID information reveals the location of + the user, to the level of the coverage area of the visited network. + For a national network, for example, P-Visited-Network-ID would + reveal that the user is in the country in question. + +4.3.1. Applicability Statement for the P-Visited-Network-ID Header + Field + + The P-Visited-Network-ID header field is applicable whenever the + following circumstances are met: + + 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, supported by the use of + standard security mechanisms, e.g., IPsec, Authentication and Key + Agreement (AKA), or Transport Layer Security (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. + + + +Jesske, et al. Informational [Page 12] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 4. There is no requirement that every visited network need be + identified at the home network. Those networks that want to be + identified make use of this extension. 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. + + 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. + +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 + 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. + + + + +Jesske, et al. Informational [Page 13] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + Any SIP proxy in the visited network that receives any of the + requests indicated in 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 no requirement for this 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 header field is normally used at + registration. However, this extension does not preclude other + usages. For example, 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 [RFC6665], 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 header + field. The identifier MUST be globally unique to avoid duplications. + Although there are many mechanisms to create globally unique + identifiers across networks, one such mechanism is already in + operation, and that is DNS. The P-Visited-Network-ID header field + does not have any connection to DNS, but the values in the header + field can be chosen from the DNS entry representing the domain name + of the network. This guarantees the uniqueness of the value. + + + + +Jesske, et al. Informational [Page 14] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +4.3.2.1. Procedures at the UA + + In the context of the network to which the header fields defined in + this document apply, a User Agent has no knowledge of the P-Visited- + Network-ID when sending the REGISTER request. Therefore, UACs MUST + 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 that is located in a visited network MAY insert a + P-Visited-Network-ID header field in any of the requests indicated in + 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 towards the user's home + network. + + A SIP proxy or registrar which is located in the home network can 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 nonexistence) + of a roaming agreement between the home and the visited networks. + This means, for instance, the authorization of the actions of the + request is based on the contents of the P-Visited-Network-ID header + field. + + A SIP proxy that 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 that 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's + identification, even when the request is not forwarded outside the + home network administrative domain. + + Note that a received P-Visited-Network-ID from a UA is not allowed + and MUST be deleted when the request is forwarded. + +4.3.2.3. Examples of Usage + + We present an example in the context of the scenario shown in the + following network diagram: + + Scenario UA --- P1 --- P2 --- REGISTRAR + + + + + + +Jesske, et al. Informational [Page 15] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + This example shows the message sequence for a REGISTER transaction + originating from UA eventually arriving at the REGISTRAR. P1 is an + outbound proxy in the visited network for UA. In this case, P1 + inserts the P-Visited-Network-ID header field. Then, P1 routes the + REGISTER request to REGISTRAR via P2. + + 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 P1 adds its own identifier in a quoted string 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=z9hG4bKnashd8 + 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 its own identifier, + derived from its own domain name to the P-Visited-Network-ID header + field. + + 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=z9hG4bKnashd8 + 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" + + + + +Jesske, et al. Informational [Page 16] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +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 (L2) / Layer 3 (L3) connectivity through different access + technologies. SIP UAs may use this header field to relay information + about the access technology to proxies that are providing services. + The 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 L2/L3 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 that 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 to have + knowledge about the access network. This is achieved by defining a + new private SIP extension header field, P-Access-Network-Info header + field. This header field carries information relating to the access + network between the UAC and its serving proxy in the home network. + + A proxy providing services based on the P-Access-Network-Info header + field must consider the trust relationship to the UA or outbound + proxy including the P-Access-Network-Info header field. + + + + + + + + +Jesske, et al. Informational [Page 17] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +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. + + 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 that 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 field into field 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 to an untrusted administrative network + domain, 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 field + in any SIP request or response. + + + + +Jesske, et al. Informational [Page 18] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + The UA inserting this information MUST have a trust relationship with + 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 avoid 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. + +4.4.2.2. Proxy Behavior + + A proxy MUST NOT modify the value of the P-Access-Network-Info header + field. + + A proxy in possession of appropriate information about the access + technology MAY insert a P-Access-Network-Info header field with its + own values. A proxy sending towards an untrusted entity MUST remove + any P-Access-Network-Info header field containing a "network- + provided" value. + + A proxy that is providing services to the UA, can act upon any + information present in the P-Access-Network-Info header field 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 is typically located in + the home network and is therefore trusted. It MUST delete the header + when the SIP signaling is forwarded to a SIP server located in an + untrusted administrative network domain. The SIP server providing + services to the UA uses the access network information that is of no + interest to other proxies located in different administrative + domains. + +4.5. The P-Charging-Function-Addresses Header Field + + 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. + + + + + +Jesske, et al. Informational [Page 19] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + The solution provided by 3GPP is to define two types of charging + functional entities: Charging Collection Function (CCF) and Event + Charging Function (ECF). CCF is used for offline charging (e.g., for + postpaid account charging). ECF is used for online 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 field. If the first address of the + sequence is not available, then the next address (ccf-2 or ecf-2) + MUST be used if available. 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]. + + We define the SIP private header field P-Charging-Function-Addresses + header field. A proxy MAY include this header field, 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. When present, 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 field 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-Addresses + Header Field + + The P-Charging-Function-Addresses header field 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 field 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. + + + + + + + + + +Jesske, et al. Informational [Page 20] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + The P-Charging-Function-Addresses header field 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 that are located in the same + administrative domain of the private network and that generate + 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. + +4.5.2. Usage of the P-Charging-Function-Addresses Header Field + + A SIP proxy that receives a SIP request MAY insert a P-Charging- + Function-Addresses header field prior to forwarding the request, if + the header was not already present in the SIP request. The header + filed 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 header field can 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 field. 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 Public Switched + Telephone Network (PSTN) gateway, or conference mixer), and it may + have access to the addresses of the charging entities. In this case, + + + +Jesske, et al. Informational [Page 21] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + a UA MAY insert the P-Charging-Function-Addresses header field 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 + field 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 header field MAY + insert a P-Charging-Function-Addresses header field 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 header field, it MAY + retrieve the information from the header field 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 field + in the outbound message. 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 field. + +4.5.2.3. Examples of Usage + + We present an example in the context of the scenario shown in the + following network diagram: + + Scenario UA1 --- P1 --- P2 --- UA2 + + In this 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 and eventually arriving at UA2. P1 + is an outbound proxy for UA1. In this case, P1 inserts charging + information. Then, P1 routes the request via P2 to UA2. + + + + + + + + + + + + +Jesske, et al. Informational [Page 22] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + Message sequence for INVITE using P-Charging-Function-Addresses + header field: + + 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:ua1@home1.net;tag=456248 + Call-ID: 843817637684230998sdasdh09 + CSeq: 18 INVITE + Contact: sip:ua1@192.0.2.4 + P-Charging-Function-Addresses: + ccf=192.0.8.1; ecf=192.0.8.3, + ccf-2=192.0.8.2; ecf-2=192.0.8.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. + +4.6. The P-Charging-Vector Header Field + + 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 is not limited to, a + globally unique charging identifier that makes the billing effort + easy. + + 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 + + + +Jesske, et al. Informational [Page 23] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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 + Identifier (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 hostname 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 + be 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 name. The void value + is used to indicate that a transit network appeared but due to + operator policy the network name is not shown. + + Furthermore, in a multi-service provider environment, one or more + transit IOIs MAY be included along the path of the SIP dialog or + transaction outside a dialog. Due to service provider policy, a void + value MAY be included instead of the transit service provider. The + void value is used to indicate that a transit appeared but due to + service provider policy the service provider 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., Universal Mobile Telecommunications System (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 header field. 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. When present, + 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-Vector header field are outside the scope of this + document. + + + + +Jesske, et al. Informational [Page 24] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +4.6.1. Applicability Statement for the P-Charging-Vector Header Field + + The P-Charging-Vector header field 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 field 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 field is applicable whenever the + following circumstances are met: + + 1. A UA sends a REGISTER or dialog-initiating request (e.g., INVITE) + or mid-dialog request (e.g., UPDATE) 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 + requests and responses are traversed through, en route to/from + the first private network, wants to generate charging records and + correlate those records with those of the first private network. + This assumes that there is a trust relationship between both + private networks. + +4.6.2. Usage of the P-Charging-Vector Header Field + + The P-Charging-Vector header field is used to convey charging-related + information, such as the globally unique IMS Charging Identity (ICID) + value. + + Typically, a SIP proxy that receives a SIP request that does not + contain a P-Charging-Vector header field 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 field can use the values, such as the globally unique + ICID, to produce charging records. + + + +Jesske, et al. Informational [Page 25] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +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 field. + UAs need not understand this header. + + However, it might be possible that a UA be located within the + administrative domain of a private network (e.g., a PSTN gateway, or + conference mixer), and it may interact with the charging entities. + In this case, a UA MAY insert the P-Charging-Vector header field 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-Vector header field 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 field MAY insert a + P-Charging-Vector header field prior to forwarding the message. The + header is populated with one or 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 field, 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 field in the outbound message. If the next hop for the + message is outside the trusted domain, then the proxy MAY remove the + P-Charging-Function-Addresses header field. + + Per local application-specific logic, the proxy MAY modify the + contents of the P-Charging-Vector header field prior to sending the + message. + +4.6.2.3. Examples of Usage + + We present an example in the context of the scenario shown in the + following network diagram: + + Scenario UA1 --- P1 --- P2 --- UA2 + + + + + + + +Jesske, et al. Informational [Page 26] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + This example shows the message sequence for an INVITE transaction + originating from UA1 and eventually arriving at UA2. P1 is an + outbound proxy for UA1. In this case, P1 inserts charging + information. Then, P1 routes the call via P2 to UA2. + + Message sequence for INVITE using P-Charging-Vector header field: + + 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.2.4 + + 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 + +4.6.3. Usage of the 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 added either by a 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 used. + + Depending on the call scenario, each transit network can add either a + transit network name or a void value. However, it cannot be + guaranteed that all the values that are added will appear within the + P-Charging-Vector header field. + + + + + + +Jesske, et al. Informational [Page 27] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + Some networks can screen the P-Charging-Vector header 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 deleting transit-ioi values + are out of the scope of this document. + + The transit-ioi contains an indexed value that MUST be incremented + with each value added to the P-Charging-Vector header field. + + A void value has no index. By adding the next value, the index has + to be incremented by the number of void entries +1. + +4.6.3.1. Procedures at the Proxy + + Procedures described within Section 4.5.2.2 apply. A transit-ioi MAY + be added or modified by a proxy. A deletion of the transit-ioi or a + entry within the tranist-ioi could appear depending on the network + policy and trust rules. This is also valid by replacing the + transit-ioi with a void value. + +4.6.4. Usage of the related-icid + +4.6.4.1. Procedures at the UA + + The UAS acting as a B2BUA MAY add the related-icid into the + P-Charging-Vector header field into SIP request or SIP responses. + For example, the UAS can include the related-icid in a response to an + INVITE request when the received INVITE request creates a new call + leg towards the same remote end. The value of the related-icid is + the icid value of the original dialog towards the remote end. + +4.6.4.2. Procedures at the Proxy + + Procedures described within Section 4.5.2.2 apply. A related-icid + and "related-icid-generated-at" MAY be added or modified by a proxy. + A deletion of the elements could appear depending on the network + policy and trust rules. + +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. + + + +Jesske, et al. Informational [Page 28] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +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" / + + + +Jesske, et al. Informational [Page 29] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + "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 + + + +Jesske, et al. Informational [Page 30] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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. + + + + + + + + + + + + + + + + + + + + + + +Jesske, et al. Informational [Page 31] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +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. + + + + + + + +Jesske, et al. Informational [Page 32] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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. + + + +Jesske, et al. Informational [Page 33] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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. + + + + + + + + + + +Jesske, et al. Informational [Page 34] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +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. + + + + +Jesske, et al. Informational [Page 35] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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. + + + + + + + + + + + +Jesske, et al. Informational [Page 36] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +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 + + + + + + + + + + +Jesske, et al. Informational [Page 37] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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]. + + + + + + + + + +Jesske, et al. Informational [Page 38] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +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. + + + + + + + +Jesske, et al. Informational [Page 39] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jesske, et al. Informational [Page 40] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + +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. + + + + + +Jesske, et al. Informational [Page 41] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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). + + + + + + + +Jesske, et al. Informational [Page 42] + +RFC 7315 3GPP SIP P-Header Extensions July 2014 + + + 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 + + + + + + + + + + + + + + + + + + +Jesske, et al. Informational [Page 43] + |