RFC 7315
Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP
Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP ✨
Okay bestie, this is RFC 7315 🎀, and it's all about the Private Header (P-Header) Extensions to SIP for the 3GPP. It was published in July 2014 💜 and it's an Informational document, which means it's a "here's how it works" doc and not a Standards Track spec. Its ISSN is 2070-1721. It was put together by the IETF (Internet Engineering Task Force) and has three authors: R. Jesske from Deutsche Telekom, K. Drage from Alcatel-Lucent, and C. Holmberg from Ericsson. The Request for Comments number is 7315, and the big headline is that it obsoletes RFC 3455 🥀, so 3455 is officially retired and this is the new version.
Abstract 🦋
This doc describes a set of private header (P-header) SIP fields that the 3GPP uses 🔥. It also explains where they're applicable, which is only in certain environments. These P-header fields do a bunch of jobs inside the networks the partners run, like charging and telling you which networks a call goes through 📡. This document obsoletes RFC 3455.
Status of This Memo 📜
Not gonna lie, this part is a little formal, but here's the tea: this document is not an Internet Standards Track specification. It's published just for info 🧚.
It's a product of the IETF, and it represents what the IETF community agreed on 🫶. It got public review and was approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full story 💅.
If you want the latest status, any errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc7315 ✨.
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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📖. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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
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 .................................411. Overall Applicability ✨
Okay so the SIP extensions in this doc make some assumptions about network topology, how SIP links to the lower layers, and whether trust is transitive 🕸️. These assumptions only work for private networks, and they're NOT appropriate for the Internet at large 🙅♀️. The mechanisms here were built to meet the 3GPP Release 5 requirements on SIP [RFC4083]. They cover cases where either there wasn't a general-purpose solution planned (because there wasn't enough operational experience to know if one was needed), or where a more general solution just isn't mature yet 🌱. If you want more detail on what's assumed for each extension, check the Applicability subsection for that 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 to set up and tear down multimedia sessions inside its IP Multimedia Subsystem (IMS) 📞. That's described in 3GPP TS 23.228 [TS23.228] and 3GPP TS 24.229 [TS24.229]. RFC 3455 [RFC3455] defines the SIP private header extensions (called P-headers) that the 3GPP spec needs 🔥. The requirements for these extensions are written up in RFC 4083 [RFC4083]. This document obsoletes RFC 3455 [RFC3455], and it also updates the existing P-header descriptions so they cover the extra requirements needed for 3GPP Release 11 🌈. Each P-header gets its own section below, so scroll on, bestie 👑.
4. SIP Private Header Fields 🦋
4.1. The P-Associated-URI Header Field 💖
This extension lets a registrar send back a set of associated URIs for a registered SIP address-of-record 🌸. We define the P-Associated-URI header field, which is used in the 200 (OK) response to a REGISTER request. It holds the set of associated URIs tied to the registered address-of-record 🗂️.
Besides the address-of-record, an associated URI is a URI that the service provider has given to a user 🎟️. A registrar keeps info that lets zero or more URIs be associated with an address-of-record. Usually, all of these URIs (the address-of-record plus the associated ones) are assigned to one particular user 🙋♀️. This extension lets the User Agent Client (UAC) find out, after a successful authenticated registration, which other URIs (if any) the service provider has tied to the address-of-record URI 🔍.
Heads up, though: in standard SIP usage [RFC3261], the registrar does NOT register the associated URIs on the user's behalf 🙅♀️. Only the address-of-record that's in the To header field of the REGISTER gets registered and bound to the contact address. The only thing conveyed is that the registrar knows about other URIs that the same user can use 💁♀️.
It's possible, though, that an application server (or even the registrar itself) registers any of the associated URIs for the user through a third-party registration 🌀. That third-party registration is out of scope for this document, so a UAC MUST NOT assume that the associated URIs are registered 🚫.
If a UAC wants to check whether any associated URI is registered, it can do that with mechanisms specified outside this document. For example, the UA MAY send a REGISTER request with the To header field set to any of the associated URIs and without a Contact header field 🔎. The 200 (OK) response will include a Contact header field listing the addresses-of-record that have been registered with contact addresses 📋. If the associated URI isn't registered, the UA MAY register it before using it ✨.
4.1.1. Applicability Statement for the P-Associated-URI Header Field 🌷
The P-Associated-URI header field applies in SIP networks where the SIP provider lets a user claim a set of identities (in header fields like the From header field) inside the requests the UA generates 🪪. It also assumes the provider knows the whole set of identities a user can legitimately claim, and that the user is fine with limiting their claimed identities to that set 🎯. This is different from 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 filled with a list of URIs associated with the address-of-record 💌.
If the registrar supports the P-Associated-URI header field extension and there's 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 💯. If there's no P-Associated-URI header field, that means there are no associated URIs for the registered address-of-record 🌙.
4.1.2.1. Procedures at the UA 🎀
okay so a UAC might get a P-Associated-URI header field in the 200 (OK) response to a REGISTER request. If that header shows up there, it means the extension is supported at the registrar 💅
The header value is a list of one or more associated URIs for the address-of-record. In a later request, the UAC MAY use any of those associated URIs to fill in the From header field value, or any other SIP header field value that says who the calling party is ✨
The UAC MAY also check whether an associated URI is registered 🔍 It can do that by putting the URI in the To header field of a REGISTER request sent to the registrar, and leaving out the Contact header field. The 200 (OK) response will then include a Contact header field listing the addresses-of-record that have been registered with contact addresses. As SIP [RFC3261] describes, the 200 (OK) response may contain a Contact header field with zero or more values (zero means 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 doesn't 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 meant for proxies. A proxy doesn't add, read, modify, or delete the header field, so 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, usually in an INVITE request, on its way to the destination. The header is filled in with the Request-URI that the proxy received in the request. This tells the User Agent Server (UAS) which address-of-record, out of several registered addresses-of-record, the invitation was sent to. For example, a user might be using one personal SIP URI and one business SIP URI to receive invitations to sessions. The UAS can then play different distinctive audiovisual alerting tones depending on which URI was used to reach it 🔔✨
Users in the 3GPP IP Multimedia Subsystem (IMS) might get one or several SIP URIs (addresses-of-record) to identify themselves. For example, a user could get one business SIP URI and one personal SIP URI. As an example of how that's used, the user could share the business SIP URI with coworkers and the personal SIP URI with family 👨👩👧
At some point, both the business SIP URI and the personal SIP URI are registered with the SIP registrar, so both can receive invitations to new sessions. When the user gets an invitation to join a session, they should be aware of which of the registered SIP URIs the session was sent to 🧐
This requirement is stated in the 3GPP Release 5 requirements on SIP [RFC4083] 📜
The problem shows up on the terminating side of session establishment. At that point, the SIP proxy serving a UA gets an INVITE request. The SIP server retargets the SIP URI in the Request-URI and replaces it with the SIP URI the user published in the Contact header field of the REGISTER request at registration time 😭
You could argue that the To header field already conveys the semantics of the called user, so this extension to SIP isn't needed. And yes, the To header field can carry the called party ID in most situations. But there are two particular cases where that assumption breaks:
- The session has been forwarded, redirected, etc., by previous SIP proxies before it arrives at the proxy serving the called user.
- The UAC builds an INVITE request and the
Toheader field is not the same as the Request-URI.
The catch with using the To header field is that the UAC fills it in, and proxies on the path don't modify it. So if the UAC, for any reason, didn't put the address-of-record of the destination user in the To header field, the destination user can't tell which address-of-record the session was meant for 🥺
Another possible solution is to have the UA give each address-of-record a different Contact header field value when it registers. The UA can tell its registered addresses-of-record apart by assigning each one its own Contact 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 🧩
That solution assumes the UA explicitly registers each of its addresses-of-record, so it has full control over the contact address values assigned to each registration 💅
But if the UA doesn't have full control of its registered addresses-of-record, say because of a third-party registration, the solution falls apart 💀 That can happen with 3GPP registration. The UA may have already told the network, by means outside of SIP, that some other addresses-of-record should be registered automatically whenever the UA registers a particular address-of-record. The requirement is covered in the 3GPP Release 5 requirements on SIP [RFC4083] 📜
Next up, we'll walk through an example of the problem, where some sort of call forwarding happened during the session, so the UAC doesn't know the intended destination URI in the current INVITE request 🕵️♀️
Say a UA is registering with 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 their personal URI with their 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) gets an INVITE request from another proxy (P2) aimed at the user's business SIP address-of-record. This INVITE has been forwarded before, so the To header field doesn't contain the user's SIP URI. In this case, the session was first addressed to sip:other-user@othernetwork.com. The SIP server at othernetwork.com then forwarded it to sip:user1-business@example.com 🔁
Scenario UA --- P1 --- P2
F3 Invite P2 -> P1
INVITE sip:user1-business@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITEProxy P1 retargets the user and replaces the Request-URI with the SIP URI published at 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 INVITEWhen the UAS gets the INVITE request, it can't tell whether the invitation came from registering the business or the personal address-of-record 😩 Neither the UAS nor the proxies or application servers can give this user a service based on the destination address-of-record of the session.
We fix this by letting the proxy responsible for the user's home domain (as defined in SIP) insert a P-Called-Party-ID header field that identifies the address-of-record the session is destined for 🛠️
If this SIP extension is used, the proxy serving the called user gets message flow F5. It then fills the P-Called-Party-ID header field in message flow F6 with the contents of the Request-URI from F4. Flows F5 and F6 are shown below:
F5 Invite P2 -> P1
INVITE sip:user1-business@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
CSeq: 101 INVITE
F6 Invite P1 -> UA
INVITE sip:user1@192.0.2.4 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128
Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1
To: sip:other-user@othernetwork.com
From: sip:another-user@anothernetwork.com;tag=938s0
Call-ID: 843817637684230998sdasdh09
P-Called-Party-ID: <sip:user1-business@example.com>
CSeq: 101 INVITEWhen the UA receives INVITE request F6, it can work out the intended address-of-record for the session and apply whatever service that address-of-record needs 🎉✨
4.2.1. Applicability Statement for the P-Called-Party-ID Header Field ✨
okay so the P-Called-Party-ID header field is for when the UAS needs to know which address-of-record was in the Request-URI before the proxy swaps it for the contact address 🎀 the UAS might want different alerting effects or filtering depending on where the call was meant to go, and this is especially useful when the UAS has registered several addresses-of-record with its registrar. without this extension, the UAS has no idea which address-of-record was in the INVITE by the time it hits its proxy/registrar 😭
P-Called-Party-ID and History-Info: back when RFC 3455 [RFC3455] was written, History-Info was still a long way from being specified 💅 it has since been specified and approved in RFC 7044 [RFC7044]. it's acknowledged that History-Info gives equivalent coverage to P-Called-Party-ID 🫶 but P-Called-Party-ID is used entirely within the 3GPP system and doesn't show up to SIP entities outside a single 3GPP operator 🧚
4.2.2. Usage of the P-Called-Party-ID Header Field
the P-Called-Party-ID header field gives proxies and the UAS the address-of-record that was in the Request-URI before a proxy retargets the request 💜 subsequent proxies on the path or the UAS can use this info 👑
typically, a SIP proxy adds the P-Called-Party-ID header field before retargetting the Request-URI 🌸 the value is filled with whatever was in the Request-URI, right before it gets replaced 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 get a SIP request that has a P-Called-Party-ID header field 🎀 the header will contain the address-of-record the proxy got in the Request-URI, from before it forwarded the request to the UAS 🦋
the UAS MAY use the value in the P-Called-Party-ID header field to offer services based on the called party URI 💅 for example, filtering calls by date and time, distinctive presentation services, distinctive alerting tones, and so on 🔥
4.2.2.2. Procedures at the Proxy
a proxy that has access to the user's contact information can insert a P-Called-Party-ID header field into any of the requests indicated in Section 5.7 ✨ when it does, the proxy MUST fill the header value with the contents of the Request-URI in the SIP request it received 🌈
the proxy that inserts P-Called-Party-ID needs to have info about the user, so that the called party ID doesn't get delivered to the wrong place 😭 that info might, 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 that header to provide a service to the user, based on the URI in the header value 🧚
a SIP proxy MUST NOT insert a P-Called-Party-ID header field in REGISTER requests 💀
4.3. The P-Visited-Network-ID Header Field 🌍
okay this one is giving roaming 🦋 3GPP networks are made up of home networks, visited networks, and subscribers 💖 a home network can have roaming agreements with one or more visited networks, which means a mobile terminal that's roaming can use resources from the visited network totally transparently ✨
one of the conditions for a home network to accept the registration of a UA roaming on a particular visited network is that a roaming agreement exists between the two 🤝 so the home network needs to know which visited network is providing services to the roaming UA 👑
3GPP user agents always register with the home network 💅 the REGISTER request gets proxied by one or more proxies in the visited network on its way to the home network 🛣️ to keep things simple, it makes sense for the visited network to include an identification that the home network already knows 🫶 this identification should be globally unique, and it takes the form of a quoted-text string or a token 🎀 the home network can use it to verify that a roaming agreement exists with that visited network, and to authorize the registration through it 🔥
heads up, P-Visited-Network-ID reveals where the user is, down to the coverage area of the visited network 👀 for a national network, for example, it would reveal that the user is in that country 🌸
4.3.1. Applicability Statement for the P-Visited-Network-ID Header Field
the P-Visited-Network-ID header field is applicable whenever all of the following circumstances are met 💜
- there is transitive trust in intermediate proxies between the UA and the home network proxy, through established relationships between the home network and the visited network, backed by standard security mechanisms like IPsec, Authentication and Key Agreement (AKA), or Transport Layer Security (TLS) 🔐
- an endpoint is using resources provided by one or more visited networks (a network the user doesn't have a direct business relationship with) 🧳
- a proxy located in one of the visited networks wants to be identified at the user's home network 🙋♀️
- there's no requirement that every visited network be identified at the home network 💁♀️ networks that want to be identified use this extension, and networks that don't want to be identified do nothing 🫠
- a commonly pre-agreed text string or token identifies the visited network at the home network 🧚
- the UAC sends a REGISTER request, a 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 🚀
- 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 🗺️
- 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 there's a trust relationship between a home network and one or more visited networks it's transited through 🤝 other proxies between the proxy in the visited network that inserts the header and the registrar or home proxy can modify the P-Visited-Network-ID value 😱 so intermediaries taking part in this mechanism MUST apply a hop-by-hop integrity-protection mechanism, such as IPsec or other available mechanisms, to prevent such attacks 🛡️
⚠️ this is serious bestie: without hop-by-hop integrity protection, anyone in the path can mess with the value, so don't skip it 💀
4.3.2. Usage of the P-Visited-Network-ID Header Field
the P-Visited-Network-ID header field carries the identifier of a visited network to the registrar or home proxy in the home network 💌 the identifier is a text string or token that both the registrar or home proxy and the proxies in the visited network know 🫶
typically, the home network authorizes the UA to roam on a particular visited network 👑 that needs an existing roaming agreement between the home and visited networks 📜
the home network could try to identify visited networks by looking at the domain names in the Via header fields, but that leans really hard on DNS 🙃 a proxy could also fill the Via header field with an IP address, and without a reverse DNS entry, that IP address won't convey the info the home network wants 🤷♀️
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 🦋 if a REGISTER request or other request is crossing different administrative domains (e.g., different visited networks), a SIP proxy MAY insert a new P-Visited-Network-ID header field when the request doesn't already contain one with the same network identifier as its own network 🌍 (e.g., if the request has gone through other different administrative domains)
heads up, there's no requirement that this header value be readable by the proxies 👀 so a first proxy MAY insert an encrypted header field that only the registrar can decrypt 🔐 if the request goes through a second proxy in the same administrative domain as the first, that second proxy might not be able to read the header's contents 😵 in that case, it will think its visited network identifier isn't already in the header value, so it inserts a new P-Visited-Network-ID header field value (hopefully with the same identifier the first proxy inserted, though maybe not encrypted) 🫠 when the request reaches the registrar or home proxy, it'll notice the header value is repeated, since both the first and second proxy inserted it 🙈 the decrypted values should be the same, because both proxies were part of the same administrative domain 💖 it's not ideal, but it doesn't cause any harm at the registrar or home proxy 🌸
the P-Visited-Network-ID header field is normally used at registration 💅 but this extension doesn't rule out other uses 🧚 for example, a proxy in a visited network that doesn't keep registration state MAY insert a P-Visited-Network-ID header field into any standalone request outside a dialog, or into a request that creates a dialog 🌈 when this document was written, the only requests that create dialogs were INVITE requests [RFC3261], SUBSCRIBE requests [RFC6665], and REFER requests [RFC3515] 📞
as roaming agreements between networks multiply, you have to be careful picking the P-Visited-Network-ID value so it doesn't clash with other identifiers 🙏 the identifier MUST be globally unique to avoid duplications 💎 there are lots of mechanisms for creating globally unique identifiers across networks, and one of them is already running everywhere: DNS 🌐 the P-Visited-Network-ID header field has no connection to DNS itself, but its values can be taken from the DNS entry for the network's domain name, which guarantees uniqueness ✨
4.3.2.1. Procedures at the UA
in the context of the network these header fields apply to, a User Agent has no knowledge of P-Visited-Network-ID when it sends the REGISTER request 🙈 so 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 ✨
Okay so a SIP proxy chilling in a visited network MAY insert a P-Visited-Network-ID header field into any of the requests listed in Section 5.7. 🌸 When it does, that header field MUST be filled with a text string or a token that names the administrative domain of the network where the proxy is operating, as seen from the user's home network. 🦋
A SIP proxy or registrar in the home network can read the P-Visited-Network-ID contents as an identifier for one or more visited networks the request went through. 💅 It may take local-policy-driven actions based on whether a roaming agreement between the home and the visited networks exists (or doesn't exist). So, for instance, whether the request's actions are authorized depends on what's in the P-Visited-Network-ID header field. It's giving policy-based routing energy, bestie 💜
A SIP proxy located in the home network MUST delete this header field when it forwards the message outside the home network administrative domain. That's how the user's privacy stays protected 🔒🫶
A SIP proxy located in the home network SHOULD delete this header field when the home proxy has already used its contents, or when the request is routed based on the called party's identification. This applies even when the request is not forwarded outside the home network administrative domain. ✨
Heads up: a P-Visited-Network-ID that comes in from a UA is not allowed. It MUST be deleted when the request is forwarded. No exceptions, periodt 🙅♀️
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 --- REGISTRARThis example shows the message sequence for a REGISTER transaction originating from UA and 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. Main character routing, fr fr 👑
Message sequence for REGISTER using the 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, into the P-Visited-Network-ID header field. Iconic energy 🌈
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"4.4. The P-Access-Network-Info Header Field
This section describes the P-Access-Network-Info header field. 📡 It's 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 the proxies that are providing services. The serving proxy can then use that 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 the 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. That network, in turn, gives a user access to the SIP capabilities and services provided. 🧃
Sometimes the SIP server that provides the user with services wants to know the type of access network the UA is currently using. Some services are more or less suitable depending on the access type, and some services are more valuable to subscribers when the access network details are known by the SIP proxy providing those services. 💖
In other cases, the SIP server that provides the user with services may just want crude location information so it can provide certain services. For example, many 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 mandate that, for cellular radio systems, the identity of the cell where an emergency call is established be made available to the emergency authorities. 🚨 That's a serious one, babe.
The SIP server that provides services to the user may want knowledge about the access network. This is achieved by defining a new private SIP extension header field, the P-Access-Network-Info header field. This header field carries information about 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 that includes the P-Access-Network-Info header field.
Wait, let me fix that: the original says "must consider", which is lowercase, so it isn't a BCP 14 keyword and I shouldn't capitalise it. Correcting the line below:
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. 🤝
4.4.1. Applicability Statement for the P-Access-Network-Info Header Field
This mechanism is appropriate in environments where SIP services depend on SIP elements knowing details about the IP and lower-layer technologies a UA uses to connect to the SIP network. 🔍 Specifically, the extension requires that the UA know the access technology it is using, and that a proxy wants that 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 SIP operation. 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 specific business and security relationships among the proxies that will see SIP messages containing this header field. It also depends on the UA having explicit knowledge 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. Security is the whole vibe here, no cap 🔐
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 providing services, the UA inserts a P-Access-Network-Info header field into the SIP message. 💌 This header contains information on the access network the UA is using to get IP connectivity. The header is typically ignored by intermediate proxies between the UA and the SIP proxy providing services. The proxy providing services can inspect the header and use the information in it 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 it has 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. 💁♀️
The UA inserting this information MUST have a trust relationship with the proxy providing services, so it can protect its privacy by deleting the header before forwarding the message outside of that 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 the 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 is generally supported by 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 that has 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 providing services to the UA can act upon any information present in the P-Access-Network-Info header field value, if it 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, which is of no interest to other proxies located in different administrative domains. 🌸
4.5. The P-Charging-Function-Addresses Header Field ✨
okay so 3GPP built this super distributed architecture 🌸 where a bunch of network entities end up helping deliver access and services. the thing is, every SIP proxy in a transaction needs to know which common charging functional entities should receive the charging records or charging events. it's a whole group project 💅
3GPP's answer is two kinds of charging functional entities: the Charging Collection Function (CCF) and the Event Charging Function (ECF). the CCF handles offline charging (think postpaid accounts 💳), and the ECF handles online charging (think prepaid accounts ✨). a network can have more than one CCF and ECF instance for redundancy, which is so smart 🫶. when there's more than one instance, implementations SHOULD try sending the charging data to the ECF or CCF address, starting with the first address in the sequence (if there is one) in the P-Charging-Function-Addresses header field. if that first address isn't available, then the next one (ccf-2 or ecf-2) MUST be used, if it's available. the CCF and ECF addresses MAY be passed during the establishment of a dialog or in a standalone transaction. for more juicy charging details, check out 3GPP TS 32.240 [TS32.240] and 3GPP TS 32.260 [TS32.260] 📚
we're defining the SIP private header field called P-Charging-Function-Addresses 🎀. a proxy MAY add this header, if it isn't already there, to either the initial request or response for a dialog, or to the request and response of a standalone transaction outside a dialog. when it's present, only one instance of the header MUST be present in a particular request or response. main character energy, one header only 👑
how a SIP proxy gathers the values to fill in this header is outside the scope of this document 🙈. but as an example, a SIP proxy might have these addresses preconfigured, or it could grab them from a subscriber database 🗂️.
4.5.1. Applicability Statement for the P-Charging-Function-Addresses Header Field 🌈
this header is applicable within a single private administrative domain where charging coordination is needed, like under the architecture 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 🚫. and it's not applicable if the administrative domain doesn't provide a charging function.
it's applicable whenever these circumstances are met:
- 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.
- A registrar, proxy, or UA that is located in the administrative domain of the private network wants to generate charging records.
- 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.
- 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 before forwarding the request, if the header wasn't already there. the header field holds one or more parameters with the hostnames or IP addresses of the nodes that are willing to receive charging information 📬.
a SIP proxy that receives a request with a P-Charging-Function-Addresses header field can use those hostnames or IP addresses as the destination for charging information or charging events 🎯. the means of actually sending that info are outside the scope of this document, and they usually don't use SIP for that purpose 📮.
4.5.2.1. Procedures at the UA 💖
this document doesn't specify any procedure at a UA located outside the administrative domain of a private network when it comes to the P-Charging-Function-Addresses header field. those 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, 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 header field when 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 one before forwarding the message 🛠️. the header gets 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 pull the info out of the header to use with application-specific logic, i.e., charging 💅. if the next hop for the message is within the proxy's administrative domain, then the proxy SHOULD include the header field in the outbound message. however, if the next hop is outside the proxy's administrative domain, then the proxy MUST remove the P-Charging-Function-Addresses header field 🚪. no leaking the charging addresses to strangers, bestie 🙅♀️.
4.5.2.3. Examples of Usage 🧚
we'll walk through an example using this network scenario:
Scenario UA1 --- P1 --- P2 --- UA2in 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 that starts at UA1 and eventually arrives at UA2 ✈️. P1 is an outbound proxy for UA1, so in this case P1 inserts charging information. then P1 routes the request via P2 to UA2.
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.4now both P1 and P2 know the IP addresses of the entities that collect charging records or charging events 🥳. both proxies can send the charging information to the same entities, and that's the vibe we want 💜.
4.6. The P-Charging-Vector Header Field 🌸
3GPP's distributed architecture means multiple network entities are involved in providing access and services 🌐. operators need the ability and flexibility to charge for that access and those services however they see fit 💸. this requires coordination among the network entities (e.g., SIP proxies), and that includes correlating the charging records generated by different entities that relate to the same session 🔗.
the correlation information includes, but isn't limited to, a globally unique charging identifier, which makes the billing effort so much easier 🧾.
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 in a standalone transaction outside a dialog. the information inside the charging vector MAY be filled in by multiple network entities (including SIP proxies) and retrieved by multiple network entities too 🤝. there are three types of correlation information being transferred: the IMS Charging Identity (ICID) value, the address of the SIP proxy that creates the ICID value, and the Inter Operator Identifier (IOI) 🦋.
the ICID is a charging value that identifies a dialog or a transaction outside a dialog, and it's used to correlate charging records 🔍. ICID MUST be a globally unique value. one way to get there is to generate the ICID from two components: a locally unique value and the hostname or IP address of the SIP proxy that generated that locally unique value 🧩.
the IOI identifies both the originating and terminating networks involved in a SIP dialog or a transaction outside a dialog 🛫🛬. there MAY be an IOI generated from each side of the dialog, so each side's network gets identified 🪪.
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 says "a transit network showed up, but the operator policy means its name isn't shown" 🤐.
and 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. same deal here: the void value means a transit appeared, but the service provider name isn't shown because of service provider policy 🙈.
there's 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 for each type of network aren't described in this memo, so that's a separate story 📖.
we're defining the SIP private header P-Charging-Vector header field 💫. a proxy MAY include this header, if it isn't 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 it's 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 🫠.
4.6.1. Applicability Statement for the P-Charging-Vector Header Field 🎀
okay so the P-Charging-Vector header is giving "only trusted friends allowed" 🫶 It works inside one private admin domain, or between different domains that have a trust relationship with each other. 🔒
If there's no trust relationship, the header is NOT included in a SIP message sent to another network 💀 (no cap, that's the rule). It also isn't applicable when the admin domain handles charging without needing to correlate records from several network entities (for example, SIP proxies). Why would you even need it then? 🙈
The P-Charging-Vector header is applicable whenever these circumstances are met:
- A UA sends a REGISTER or dialog-initiating request (for example, INVITE), a mid-dialog request (for example, UPDATE), or a standalone transaction request outside a dialog to a proxy in the administrative domain of a private network. 📨
- A registrar, proxy, or UA in the administrative domain of the private network wants to generate charging records. 💅
- A proxy or UA in the administrative domain of the private network has access to the charging correlation information for that network. 🧚
- Optionally, a registrar, proxy, or UA that's part of a second administrative domain in another private network, whose SIP requests and responses travel through the first private network on their way to or from it, wants to generate charging records and correlate those with the records of the first private network. This assumes there's a trust relationship between both private networks. 👑
4.6.2. Usage of the P-Charging-Vector Header Field 🦋
The P-Charging-Vector header is used to carry charging-related info, like the globally unique IMS Charging Identity (ICID) value. ✨
Typically, a SIP proxy that gets a SIP request without a P-Charging-Vector header MAY insert one, using whatever parameters it has available. 🌸
A SIP proxy that gets a SIP request WITH a P-Charging-Vector header can use the values, like the globally unique ICID, to produce charging records. 📊
4.6.2.1. Procedures at the UA 💖
This document doesn't specify any procedure for a UA that sits outside the administrative domain of a private network (like a PSTN gateway or a conference mixer) when it comes to the P-Charging-Vector header. UAs need not understand this header. 🙃
BUT it might be possible for a UA to be inside the administrative domain of a private network (like a PSTN gateway or conference mixer), and then it may interact with the charging entities. 🫣 In that case, a UA MAY insert the P-Charging-Vector header in a SIP request or response when the next hop is a proxy or UA in the same administrative domain. Similarly, that UA MAY use the contents of the P-Charging-Vector header when talking to the charging entities. 💜
4.6.2.2. Procedures at the Proxy 🍓
A SIP proxy that supports this extension and receives a request or response without the P-Charging-Vector header MAY insert a P-Charging-Vector header before forwarding the message. The header gets filled 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 gets a request or response WITH the P-Charging-Vector header, it MAY pull the info out of the header value to use with application-specific logic, aka charging. 🔥 If the next hop is inside the trusted domain, then the proxy SHOULD include the P-Charging-Vector header in the outbound message. If the next hop is outside the trusted domain, then the proxy MAY remove the P-Charging-Function-Addresses header field. 🙈
Per its own local application-specific logic, the proxy MAY modify the contents of the P-Charging-Vector header before sending the message. 🌈
4.6.2.3. Examples of Usage 🧚♀️
We're going to look at an example in the scenario shown in this network diagram:
Scenario UA1 --- P1 --- P2 --- UA2This example shows the message sequence for an INVITE transaction that starts at UA1 and eventually reaches UA2. P1 is the outbound proxy for UA1, so P1 inserts the charging info. Then P1 routes the call through P2 to UA2. 📞
Message sequence for INVITE using the 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.net4.6.3. Usage of the transit-ioi 🌍
The transit-ioi gets added to the P-Charging-Vector header when traffic goes through transit networks. You can have multiple transit-ioi values in one SIP message or response, and the values in the response are independent of the ones set up in the request. 💫
The element can be added either by a transit network itself, or by the next network at the entry point where the previous network is known. Depending 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 can't be guaranteed that all the values that get added will show up in the P-Charging-Vector header. 🥲
Some networks can screen the P-Charging-Vector header and delete transit-ioi values, for example networks that don't support this value. There are scenarios where the transit-ioi values from all networks need to appear to get a correct end-to-end view. 👀
The policies for adding, modifying, and deleting transit-ioi values are out of scope for this document. 📝
The transit-ioi contains an indexed value that MUST be incremented with each value added to the P-Charging-Vector header. 🔢
A void value has no index. When you add the next value, the index has to go up by the number of void entries +1. 🧮
4.6.3.1. Procedures at the Proxy 🐣
The procedures in Section 4.5.2.2 apply here. A transit-ioi MAY be added or modified by a proxy. A deletion of the transit-ioi, or of an entry within the transit-ioi, could show up depending on network policy and trust rules. This is also valid when you replace 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 in SIP requests or SIP responses. For example, the UAS can include the related-icid in a response to an INVITE request when the INVITE it received creates a new call leg toward the same remote end. The value of the related-icid is the icid value of the original dialog toward the remote end. 💅
4.6.4.2. Procedures at the Proxy ✨
The procedures in Section 4.5.2.2 apply here. A related-icid and "related-icid-generated-at" MAY be added or modified by a proxy. A deletion of these elements could show up depending on 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]. Several BNF definitions are inherited from SIP and aren't repeated here, so implementors need to be familiar with the notation and contents of SIP [RFC3261] and [RFC5234] to understand this document. 🤓
5.1. P-Associated-URI Header Syntax 🎀
The syntax of the P-Associated-URI header field goes like this:
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-param5.2. P-Called-Party-ID Header Syntax 🦋
The syntax of the P-Called-Party-ID header field goes like this:
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-param5.3. P-Visited-Network-ID Header Syntax 🌸
The syntax of the P-Visited-Network-ID header field goes like this:
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-param5.4. P-Access-Network-Info Header Syntax ✨
Okay, so here's the grammar for the P-Access-Network-Info header field 🛜 Everything hangs off access-net-spec, and it's giving very precise. 💅
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" /
"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
operator-specific-GI = "operator-specific-GI" EQUAL
(token / quoted-string)
utran-sai-3gpp = "utran-sai-3gpp" EQUAL
(token / quoted-string)Right, so the access-info part is where the juicy extra details live 🎀 It MAY contain additional information about the access network, so you can really spill the tea on where the user is connecting from. 🌸 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]. Go check that one if you want the full receipts 🧾
5.5. P-Charging-Function-Addresses Header Syntax 🦋
Next up is the P-Charging-Function-Addresses header field, which is the grammar for telling people where the charging functions are hanging out 📍
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-valueSo this header holds one or two addresses, either for the ECF (ecf and ecf-2) or for the CCF (ccf and ccf-2) 🔥 The first address in the sequence is ccf or ecf. If that first one isn't available, then the next address (ccf-2 or ecf-2) MUST be used, as long as it's available. Backup plan, very responsible of us 🫶
5.6. P-Charging-Vector Header Syntax 💜
Now the P-Charging-Vector header field, which is honestly one of the most iconic headers because it carries all the charging correlation info 👑
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 hostOkay, so the P-Charging-Vector header has icid-value as a mandatory parameter 🎯 That's the IMS charging ID, and it's the thing used to correlate charging records and events. The first proxy that gets the request is the one that generates this value, so it's the OG 🧚
The icid-gen-addr parameter holds the hostname or IP address of the proxy that generated the icid-value 📮
The orig-ioi and term-ioi parameters hold the originating and terminating interoperator identifiers 🌈 They're how charging records get matched up between different operators. The originating IOI is the network responsible for the charging records on the originating side of the session or standalone request. Similarly, the terminating IOI is the network handling the charging records on the terminating side of that same session or standalone request. Two sides, one story ✨
The transit-ioi parameter carries values that each represent a transit interoperator identifier 🚏 It's used to correlate charging records between different networks, and it represents the network responsible for the records in the transit part of the session or standalone request.
The related-icid parameter holds the icid-value of a related charging record, for when more than one call leg is tied to one session 🤝 It's an OPTIONAL parameter, and it helps correlate charging info between two or more call legs that belong to the same remote-end dialog.
The related-icid-gen-addr parameter holds the hostname or IP address of the proxy that generated the related-icid 🦋
Also, applications that use the P-Charging-Vector header field within their own applicability are allowed to define generic-param extensions without going through the IETF specification process. Freedom to create, bestie 💖
5.7. New Headers 🎀
Okay, so here's where we figure out which methods each header is allowed to show up in 🗺️ The P-Associated-URI header field can appear in SIP REGISTER method and 2xx responses. 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 in 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. Know your lanes, everyone 🛣️
6. Security Considerations 🔐
Okay, bestie, this part is serious, so let's get into it 😭 Every header here has some privacy and security stuff going on, so pay attention.
6.1. P-Associated-URI Header Field 🫣
The info returned in the P-Associated-URI header field isn't seen as particularly sensitive 💅 It's really just informational, giving the UAC some openness about the automatic association the registrar did. But if there's no end-to-end protection at the SIP layer, proxies sitting between the registrar and the UA could totally modify what's in the header value 🙈
Also, no encryption at all, whether end-to-end or hop-by-hop, may lead to some leakage of privacy about the list of authorized identities. Like, a user who registers the address-of-record 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. Wild, right? 👀
An eavesdropper could possibly collect the list of identities a user is registered with, and that can have privacy implications 💀 To mitigate this, this extension SHOULD only be used in a secured environment. That means SIP messages are encrypted either end-to-end or hop-by-hop, and there's a trust relationship equivalent to the one defined in RFC 3325 [RFC3325] between the entities. In other words, the user's privacy depends on the other entities in the session not spilling what they've learned about the user 🤫
Heads up: even though the P-Associated-URI header field value lets one REGISTER message implicitly register a whole bundle of URIs, the security impact is no higher than using separate REGISTER messages for each of those URIs. So no extra risk, just more URIs in one go ✨
6.2. P-Called-Party-ID Header Field 🌸
Because of what the P-Called-Party-ID header field is, it doesn't introduce any significant security concern 🙌 It's possible for an attacker to modify the contents of the header, but that modification won't cause any harm to session establishment, so we're chill.
An eavesdropper could possibly collect the list of identities a user has registered, and that can have privacy implications 🫠 To mitigate this, this extension SHOULD only be used in a secured environment, where SIP messages are encrypted either end-to-end or hop-by-hop.
Normally, inside a 3GPP environment, the P-Called-Party-ID isn't sent to end users, but it may be exchanged between carriers that use security mechanisms other than SIP encryption 🧚
6.3. P-Visited-Network-ID Header Field 🦋
okay so the P-Visited-Network-ID header kinda assumes that the home network and the visited networks it passes through actually trust each other 🤝 like, lowkey the whole point. Other proxies sitting between the visited-network proxy that inserts the header and the registrar or the home proxy could change the P-Visited-Network-ID value, and that is NOT it 💀 so anyone participating in this mechanism MUST apply a hop-by-hop integrity-protection mechanism such as IPsec or other available mechanisms to stop those attacks 🔒✨
6.4. P-Access-Network-Info Header Field 🌸
okay this one is giving full security-arc energy 😭 A Trust Domain is formally defined in RFC 3324 [RFC3324]. For the purposes of this doc, the 3GPP trust domain means the collection of SIP proxies and application servers that a 3GPP network operator runs and that follow the requirements in 3GPP TS 24.229 [TS24.229] 🧚
This extension assumes the access network is trusted by the UA (because the UA's home network has a trust relationship with the access network), like we already covered earlier in the doc 💅
This extension also assumes that the info the UAC adds 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 uses this header's info to offer extra services, and UAs are expected to give correct info 🫶 Still, there are no security problems from a UA putting in incorrect info. Networks using the P-Access-Network-Info header field will therefore need to trust the UA sending it. A rogue UA sending false access network info will do no more harm than restrict the user from certain services. bestie that is the worst-case scenario 😂
The mechanism here is designed primarily for private systems like 3GPP, and most security requirements are met through private standardized solutions 🌈
For instance, 3GPP will use the P-Access-Network-Info header field to carry relatively sensitive info like the cell ID 📡 so the info MUST NOT be sent outside of the 3GPP domain. Iconic behavior, no notes 🙈
If the UA is a 3GPP UA, it's aware that it's operating within a trusted domain 🌸
The 3GPP UA knows whether a secure association to the home network domain for transporting SIP signaling is currently available. Because of that, the sensitive info 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 using this extension that is not part of a private trusted domain should not consider the mechanism as secure. So it MUST NOT send sensitive info in the P-Access-Network-Info header field 🙅♀️
Any proxy 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 before forwarding it outside of the trusted domain. Non-negotiable, periodt 💖
A proxy that receives a message containing the P-Access-Network-Info header field from an untrusted entity can't guarantee the validity of the contents. So this content SHOULD be deleted based on local policy 🧹
6.5. P-Charging-Function-Addresses Header Field 💸
It's 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 info MUST have a trust relationship.
If an untrusted entity were inserted between trusted entities, it could potentially substitute a different charging function address 😬 So an integrity-protection mechanism such as IPsec or other available mechanisms MUST be applied 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 ⭐
Same energy here! It's 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 info 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 💜
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
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 73158. 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 also 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] 🌷
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.
- [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.
Appendix A. Changes from RFC 3455 🎀
okay bestie, this is the changelog, and it's giving receipts 💅 here's everything that changed since RFC 3455:
- Procedures for the
P-Associated-URIheader field at a proxy. RFC 3455 says it defines no procedures forP-Associated-URIat a proxy. What it really means is that a proxy doesn't add, read, modify, or delete the header, so the RFC 3261 proxy procedures are the only ones that apply to it 🦋 P-Called-Party-IDheader field and theHistory-Infoheader field. When RFC 3455 was written,History-Infowas still a long way from being specified. It's now specified and approved in RFC 7044 ✨ It's acknowledged thatHistory-Infogives equivalent coverage toP-Called-Party-ID. However,P-Called-Party-IDis used entirely within the 3GPP system and doesn't really show up to SIP entities outside a single 3GPP operator 🌸- Procedures at the UA for the
P-Charging-Function-Addressesheader field. The text in Section 4.5.2.1 of RFC 3455 doesn't properly cover UAs inside the private network, like gateways and similar devices that can play a full part in network charging procedures 💼 Section 4.5.2.1 gets replaced with new text. - The text in Section 4.6.2.1 of RFC 3455 also doesn't properly cover UAs inside the private network, like gateways, which can play a full part in network charging procedures 🫶 Section 4.6.2.1 is now replaced with new text.
- New access technology values in the
P-Access-Network-Infoheader field (Section 4.4). A bunch of new access technologies are coming from 3GPP, and reusing IMS for Next Generation Networks (NGN) is making even more. RFC 3455 defines the access technology values explicitly and sets up no IANA procedures for a separate registry 🧚 So the new values are defined here:"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 ✨ - Replacement of an existing access technology value in the
P-Access-Network-Infoheader field (Section 4.4). The value"3GPP-CDMA2000"was replaced a long time ago in 3GPP2 by three new values:"3GPP2-1X","3GPP2-1X-HRPD", and"3GPP2-UMB"🌈 It's not believed that the"3GPP-CDMA2000"value was ever deployed, so it's a no-drama replacement 🍓 - Network-provided
P-Access-Network-Infoheader field. Proxies within the network may also provide theP-Access-Network-Infoheader field 🌐 This doesn't change the values a UA provides. The header is just repeated. These values are identified by the string"network-provided". A special class of values is defined for this, because the same granularity of values might not be possible as for the ones from the UA:"3GPP-GERAN","3GPP-UTRAN","3GPP-WLAN","3GPP-GAN", and"3GPP-HSPA"💜 Outbound proxies removeP-Access-Network-Infoheader fields that contain the"network-provided"value. - Additional parameters for the
P-Charging-Vectorheader field. Section 5.6 of RFC 3455 defines the syntax of theP-Charging-Vectorheader field. Extra parameters were considered too application specific for RFC 3455, but everyone knew they would exist, and 3GPP has in fact specified more of them for specific access technologies 🔥 So this update says applications usingP-Charging-Vectorwithin their own applicability are allowed to define generic-param extensions without further reference to the IETF specification process 👑 - In Section 5.7, it was added that the
P-Called-Party-IDcan appear in the PUBLISH method 📮 - Referencing. RFC 3427 was deleted from the References section because nothing in the document used it 🗑️ Various informative references have now been published as RFCs and have been updated with the right 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., the latest version applies) ⭐
- Editorial changes. Various editorial changes were applied to match the style of RFC 3261. Examples are putting response code text in parentheses, and using the words "request" and "response" together with method names 🙈
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📦 where this page comes from
- ietf: rfc7315 2014-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms