RFC 3455

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

📅 published January 2003, from ietf

Part 1 of 7 🎀

RFC 3455: Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) ✨

  • Stream and group: Network Working Group 💖
  • Authors: M. Garcia-Martin (Ericsson), E. Henrikson (Lucent), D. Mills (Vodafone) 🦋
  • Category: Informational 🌸
  • Date: January 2003 📅
  • Obsoletes / Updates: this doc doesn't list anything it obsoletes or updates 🙈

Status of this Memo ✨

Okay bestie, this memo is just information for the Internet community 💅 It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🫶

Copyright (C) The Internet Society (2003). All Rights Reserved. 🌈

Abstract

This doc describes a set of private Session Initiation Protocol (SIP) headers (P-headers) used by the 3rd-Generation Partnership Project (3GPP) 🧚 It also covers where they apply, which is limited to particular environments. The P-headers serve a bunch of purposes inside the networks the partners use, including charging and info about which networks a call goes through 💜

Table of Contents

1. Overall Applicability . . . . . . . . . . . . . . . . . . . .  3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . .  3
3. Overview . . . .  . . . . . . . . . . . . . . . . . . . . . .  3
4. SIP Private Headers . . . . . . . . . . . . . . . . . . . . .  3
  4.1 The P-Associated-URI header. . . . . . . . . . . . . . . .  3
      4.1.1 Applicability statement for the
            P-Associated-URI header. . . . . . . . . . . . . . .  4
      4.1.2 Usage of the P-Associated-URI header . . . . . . . .  4
  4.2 The P-Called-Party-ID header . . . . . . . . . . . . . . .  6
      4.2.1 Applicability statement for the
           P-Called-Party-ID header. . . . . . . . . . . . . . .  9
      4.2.2 Usage of the P-Called-Party-ID header. . . . . . . . 10
  4.3 The P-Visited-Network-ID header. . . . . . . . . . . . . . 11
      4.3.1 Applicability statement for the
            P-Visited-Network-ID header. . . . . . . . . . . . . 11

      4.3.2 Usage of the P-Visited-Network-ID header . . . . . . 12
  4.4 The P-Access-Network-Info header . . . . . . . . . . . . . 15
      4.4.1 Applicability Statement for the
            P-Access-Network-Info header . . . . . . . . . . . . 16
      4.4.2 Usage of the P-Access-Network-Info header .  . . . . 17
  4.5 The P-Charging-Function-Addresses header . . . . . . . . . 18
      4.5.1 Applicability Statement for the
            P-Charging-Function-Addresses header . . . . . . . . 18
      4.5.2 Usage of the P-Charging-Function-Addresses
            headerd. . . . . . . . . . . . . . . . . . . . . . . 19
  4.6 The P-Charging-Vector header . . . . . . . . . . . . . . . 21
      4.6.1 Applicability Statement for the
            P-Charging-Vector header . . . . . . . . . . . . . . 22
      4.6.2 Usage of the P-Charging-Vector header .  . . . . . . 23
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25
  5.1 P-Associated-URI header syntax . . . . . . . . . . . . . . 25
  5.2 P-Called-Party-ID header syntax. . . . . . . . . . . . . . 25
  5.3 P-Visited-Network-ID header syntax . . . . . . . . . . . . 25
  5.4 P-Access-Network-Info header syntax. . . . . . . . . . . . 25
  5.5 P-Charging-Function-Addresses header syntax. . . . . . . . 26
  5.6 P-Charging-Vector header syntax. . . . . . . . . . . . . . 26
  5.7 Table of new headers . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
  6.1 P-Associated-URI . . . . . . . . . . . . . . . . . . . . . 28
  6.2 P-Called-Party-ID. . . . . . . . . . . . . . . . . . . . . 28
  6.3 P-Visited-Network-ID . . . . . . . . . . . . . . . . . . . 28
  6.4 P-Access-Network-Info. . . . . . . . . . . . . . . . . . . 29
  6.5 P-Charging-Function-Addresses. . . . . . . . . . . . . . . 30
  6.6 P-Charging-Vector. . . . . . . . . . . . . . . . . . . . . 30
7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . 30
8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
9.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 32
10. Normative References . . . . . . . . . . . . . . . . . . . . 32
11. Informative References . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 34

1. Overall Applicability 🌸

Okay so the SIP extensions in this doc make some assumptions about network topology, how SIP links up with the lower layers, and whether transitive trust is available 👀 Those assumptions are NOT APPLICABLE across the Internet as a whole 💀 The mechanisms were built to meet the 3GPP Release 5 requirements on SIP [4]. They cover cases where either no general-purpose solution was planned, where there wasn't enough operational experience to know if a general solution is even needed, or where a more general solution isn't mature yet 🧠 For the deep dive into the assumptions, check 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 BCP 14, RFC 2119 [2]. Those are the official BCP 14 vibes, so read them exactly 🫶

3. Overview 🦋

The Third Generation Partnership Project (3GPP) picked SIP as the protocol to set up and tear down multimedia sessions in its IP Multimedia Subsystem (IMS) 🌈 If you want the full IMS tea, see 3GPP TS 23.228 [14] and 3GPP TS 24.229 [15] ✨ 3GPP told the IETF SIP and SIPPING working groups that existing SIP docs already covered almost all the functionality the IMS needs. They did need some extra stuff to actually use SIP for this, though 🙈 These requirements [4] are written up in an Internet Draft that was submitted to the SIPPING Working Group. Some of them are handled by chartered extensions. Others applied to SIP but weren't general enough for the SIP Working Group to adopt 💖 This doc describes private extensions to cover those requirements. Each extension, or set of related extensions, gets its own section below 🎀

4. SIP Private Headers ⭐

4.1 The P-Associated-URI header 🦋

This extension lets a registrar return a set of associated URIs for a registered address-of-record. We define the P-Associated-URI header field, used in the 200 OK response to a REGISTER request 💜 It carries the set of Associated URIs to the registered address-of-record 🫧

An associated URI is a URI the service provider has allocated to a user for their own usage. A registrar holds info that lets an address-of-record URI be associated with zero or more URIs. Usually all of these URIs (the address-of-record URI and the associated URIs) are allocated for one particular user 🧚 This extension lets the UAC know, after a successful authenticated registration, which other URIs (if any) the service provider has associated with an address-of-record URI 👑

Note that the registrar generally does not register the associated URIs on the user's behalf. Only the address-of-record in the To header field of the REGISTER gets registered and bound to the contact address. The only info conveyed is that the registrar knows about other URIs for the same user 🙃

It may be possible, though, that an application server (or even the registrar itself) registers any of the associated URIs on the user's behalf through a third party registration. This third party registration is out of scope for this doc, though 🚫 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 doc, 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. The 200 OK response will include a Contact header with the list of registered contact addresses. If the associated URI is not registered, the UA MAY register it before using it 🌸

4.1.1 Applicability statement for the P-Associated-URI header 🔥

The P-Associated-URI header applies in SIP networks where the SIP provider allocates the set of identities a user can claim (in headers like the From field) in requests the UA generates 🍓 It also assumes the provider knows the entire set of identities a user can legitimately claim, and that the user is willing to limit their claimed identities to that set. This is different from normal SIP usage, where the From field is explicitly an end-user specified field 💅

4.1.2 Usage of the P-Associated-URI header ✨

The registrar inserts the P-Associated-URI header field into the 200 OK response to a REGISTER request. The header field value is a list with zero or more URIs associated with the address-of-record 🎀

If the registrar supports the P-Associated-URI header extension, then the registrar MUST always insert the P-Associated-URI header field in all the 200 OK responses to a REGISTER request. That goes for initial registration, re-registration, and de-registration alike, and whether there are zero or more associated URIs 🫶

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. The presence of that header field in the 200 OK response for a REGISTER request implies the extension is supported at the registrar 🌈

The header value is a list of zero or more associated URIs for the address-of-record URI. The UAC MAY use any of the associated URIs to fill in the From header value, or any other SIP header value that gives info about the identity of the calling party, in a subsequent request 🧚

The UAC MAY check whether an associated URI is registered or not. It can do this by setting the To header value in a REGISTER sent to the registrar, without a Contact header. The 200 OK response will include a Contact header with the list of registered contact addresses. As described in SIP [1], the 200 OK response may contain a Contact header field with zero or more values (zero meaning the address-of-record is not registered) 🦋

4.1.2.2 Procedures at the registrar 👑

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

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

If the address-of-record under registration has no other SIP or SIPS URIs associated with it, the registrar MUST include an empty P-Associated-URI header value 🫧

4.1.2.3 Procedures at the proxy 💅

Okay bestie, this one is short and sweet. This memo does not define any procedure at the proxy, so the proxy gets no extra rules from this doc 🫶

4.2 The P-Called-Party-ID header 🎀

Okay so, a proxy server slaps a P-Called-Party-ID header onto the request, usually an INVITE, on its way to the destination 🦋 The value is whatever Request-URI the proxy received. The UAS then gets to figure out which address-of-record the invite was actually sent to. Think about it: a user might have a personal SIP URI and a business SIP URI, both working at once. Your business contacts use one, your family uses the other, and the UAS can play a different alerting tone depending on which one rang 🔔🌸

Users in the 3GPP IP Multimedia Subsystem (IMS) can get one or several SIP URIs (address-of-record) to identify themselves. For example, someone might have a business SIP URI and a personal one. The business one goes to co-workers, and the personal one goes to family 💼💜

Here's the tricky part. Both the business and the personal SIP URI can be registered with the SIP registrar at the same time, so both can receive invitations to new sessions 📞 When the user gets an invite to join a session, they should be aware of which of those registered SIP URIs the session was sent to.

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

So where's the problem? It shows up on the terminating side of session setup. The SIP proxy serving the UA gets an INVITE, and the SIP server retargets the SIP URI in the Request-URI field, swapping it for the SIP URI the user published in the Contact header field of their REGISTER request. Once the UAS gets the INVITE, it has no way to tell which address-of-record it was sent to 😭

People often say the To header field already tells you who the called user is, so this extension isn't needed. And to be fair, the To header field does carry the called party ID in most situations. But there are two special cases where that assumption breaks 🙈

  1. The session has been forwarded, redirected, etc., by previous SIP proxies, before arriving to the proxy which is serving the called user.
  2. The UAC builds an INVITE request and the To header field is not the same as the Request-URI.

The catch with the To header field is that the UAC fills it in, and proxies on the path don't change it. So if the UAC, for any reason, didn't put the destination user's address-of-record in the To header field, the destination user can't tell which address-of-record the session was meant for 🥺

There's another idea that builds on giving each address-of-record its own Contact header value at registration time. The UA can tell its registrations apart by assigning a different Contact header value to each one. For instance, when the UA registers the address-of-record sip:id1, the Contact header value can be sip:id1@ua, and the registration of sip:id2 can be bound to the Contact value sip:id2@ua 🧚

This approach assumes the UA explicitly registers each of its address-of-record URIs, so it has full control over the contact address values assigned to each registration. But if the UA doesn't have full control over its registered address-of-records, say because of a third party registration, this solution breaks down. That can happen with 3GPP registration, where the UA may have already told the network, by means outside of SIP, that some other address-of-record URIs should be automatically registered whenever the UA registers a particular one. This requirement is covered in the 3GPP Release 5 requirements on SIP [4].

Let's walk through an example of the problem, where some call forwarding happened in the session, so the UAC doesn't know the intended destination URI in the current INVITE 👀

We assume that a User Agent (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 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 from another proxy (P2) aimed at the user's business SIP address-of-record. This INVITE has been forwarded in the past, so the To header field doesn't have the user's SIP URI in it. 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 INVITE

The proxy P1 retargets the user and swaps the Request-URI for the SIP URI published during registration, which lives in the Contact header 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 gets the INVITE, it has no idea whether the invitation came from the business registration or the personal one 😩 Neither the UAS, nor proxies, nor application servers can offer 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 that names the address-of-record this session was headed to ✨

If this SIP extension is used, the proxy serving the called user gets the message flow F5, and it fills the P-Called-Party-ID header in message flow F6 with the contents of the Request-URI from F4. Check out flows F5 and F6 below 👇

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

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

When the UA gets the INVITE request F6, it can work out which address-of-record the session was meant for, and apply whatever service that address-of-record needs 🎉👑

4.2.1 Applicability statement for the P-Called-Party-ID header 🦋

The P-Called-Party-ID is useful when the UAS needs to know which address-of-record was in the Request-URI of the request, before the proxy retargets it to the contact address. The UAS might want to apply different audiovisual alerting effects or other filtering services, depending on where the request was headed. It's especially valuable when the UAS has registered several address-of-record URIs with its registrar. Without this extension, the UAS wouldn't know which address-of-record was in the INVITE request when it hit its proxy/registrar 🙃

Requirements for a more general solution are proposed in [12], but SIP hasn't adopted them, and no solution has been developed yet.

4.2.2 Usage of the P-Called-Party-ID header 🍓

The P-Called-Party-ID header field gives proxies and the UAS the address-of-record that was in the Request-URI of the request, before a proxy retargets it. This info is meant for later proxies on the path or for the UAS to use 💖

Usually, a SIP proxy inserts the P-Called-Party-ID header before it retargets the Request-URI in the SIP request. The header value is filled with the contents of the Request-URI, before that 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. Hard rule, no exceptions 🚫

A UAS may receive a SIP request that contains a P-Called-Party-ID header field. The header will be filled with the address-of-record the proxy received in the Request-URI of the request, before the proxy forwarded it 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, like 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 Contact information of the user MAY insert a P-Called-Party-ID header field in any of the requests listed in Table 1 (Section 5.7). The proxy MUST populate the header value with the contents of the Request-URI present in the SIP request that the proxy received 💅

The proxy that inserts the P-Called-Party-ID header needs information about the user, so the called party ID doesn't get delivered to the wrong place. That information may have been learned through a registration process, for instance 🫶

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

A SIP proxy MUST NOT insert a P-Called-Party-ID header in REGISTER requests. No P-Called-Party-ID in REGISTER, periodt 🙅‍♀️

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

okay so 3GPP networks are basically a whole ecosystem of home networks, visited networks, and subscribers 🌸 a home network can have roaming agreements with one or more visited networks, which means when a mobile terminal is roaming, it can use the visited network's resources totally transparently ✨ it just works, no cap

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 a way to know which visited network is actually serving the roaming UA. that's literally the whole job of this header 🧚

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 with the visited network exists, and to authorize the registration through that visited network 👑

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

the P-Visited-Network-ID is applicable whenever these 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, and generally supported by standard security mechanisms, e.g., IPsec, AKA, or TLS.
  2. An endpoint is using resources provided by one or more visited networks (a network to which the user does not have a direct business relationship).
  3. A proxy located in one of the visited networks wants to be identified at the user's home network.
  4. There is no requirement that every visited network needs to be identified at the home network. Networks that want to be identified use the extension defined in this document. 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 or dialog-initiating request (e.g., INVITE), or a standalone request outside a dialog (e.g., OPTIONS), to a proxy in a visited network.
  7. The request traverses, en route to its destination, a first proxy located in the visited network and a second proxy located in the home network, or its destination is the registrar in the home network.
  8. The registrar or home proxy verifies and authorizes the usage of resources (e.g., proxies) in the visited network.

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

the P-Visited-Network-ID header field carries the identifier of a visited network over 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 about 🫶

usually the home network authorizes the UA to roam to a particular visited network, and that requires an existing roaming agreement between the home and the visited network.

the home network could figure out which visited networks are involved by inspecting the domain names in the Via header fields, but that has a heavy dependency on DNS 🙈 it's also an option for a proxy to fill the via header with an IP address, for example, and without a reverse DNS entry, that IP address won't convey the information the home network wants.

Any SIP proxy that receives any of the requests indicated in Table 1 (Section 5.7) MAY insert a P-Visited-Network-ID header when it forwards the request. If a REGISTER 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 if the request does not already contain a P-Visited-Network-ID header 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's no requirement for the header value to be readable by the proxies 👀 so a first proxy might insert an encrypted header that only the registrar can decrypt. if the request then goes through a second proxy in the same administrative domain as the first, that second proxy may not be able to read the contents of the P-Visited-Network-ID header. in that situation, it will think its visited network identifier isn't already in the header value, so it inserts a new P-Visited-Network-ID header value (hopefully with the same identifier the first proxy inserted, although maybe not encrypted). when the request arrives at the registrar or proxy in the home network, it'll notice the header value is repeated, since both the first and the second proxy inserted it. the decrypted values should be the same, because both proxies were part of the same administrative domain. this situation isn't desirable, but it doesn't create any harm at the registrar or proxy in the home network 🫠

the P-Visited-Network-ID is normally used at registration, but this extension doesn't rule out other usages. for instance, a proxy located in a visited network that does not maintain registration state may insert a P-Visited-Network-ID header into any standalone request outside a dialog, or into a request that creates a dialog. at the time of writing, the only requests that create dialogs are INVITE [1], SUBSCRIBE [6] and REFER [11] ✨

to avoid conflicts with identifiers, especially as the number of roaming agreements between networks grows, you have to be careful when picking the value of the P-Visited-Network-ID. the identifier should be globally unique to avoid duplications. there are lots of mechanisms for creating globally unique identifiers across networks, and one of them is already in operation: DNS 🌈 the P-Visited-Network-ID doesn't have any connection to DNS, but the values in the header can be chosen from the network's own DNS entry representing its domain name. this guarantees the uniqueness of the value 🔥

4.3.2.1. Procedures at the UA 🎀

User agent clients SHOULD NOT insert a P-Visited-Network-ID header in any SIP message. 🙅‍♀️

4.3.2.2. Procedures at the registrar and proxy 👑

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

a SIP proxy or registrar located in the home network may use the contents of the P-Visited-Network-ID 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 whether a roaming agreement between the home and the visited networks exists or not. this means, for instance, it can authorize the actions of the request based on the contents of the P-Visited-Network-ID header 🧠

a SIP proxy located in the home network MUST delete this header when forwarding the message outside the home network administrative domain, in order to retain the user's privacy 🔒

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

the vibe check: privacy is the reason the MUST delete rule exists, so don't skip it 🫶

4.3.2.3. Examples of Usage 🍓

we'll look at examples in the context of this scenario, shown in the following network diagram:

            Scenario            UA --- P1 --- P2 --- REGISTRAR

this example shows the message sequence for a REGISTER transaction starting at UA1 and eventually arriving at REGISTRAR. P1 is the outbound proxy for UA1. in this case, P1 also inserts the P-Visited-Network-ID header. P1 then routes the REGISTER request to the Registrar via P2 🚀

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

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

in flow F2, proxy P2 adds its own identifier to the P-Visited-Network-ID header 🦋

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

finally, in flow F3, proxy P2 decides to insert its own identifier, derived from its own domain name 🎀

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

4.4 The P-Access-Network-Info header ✨

Okay bestie, this section is all about the P-Access-Network-Info header 🎀. It's super useful in SIP networks that also give you layer 2/layer 3 connectivity through different access technologies 🌐. SIP User Agents can use it to pass info about their access technology along to the proxies providing services 💅. The serving proxy can then use that info to optimize services for the UA ✨. Like, a 3GPP UA could use this header to share stuff about the access network, such as radio access technology and radio cell identity, with its home service provider 📡.

For this extension, an access network is the network giving you the layer 2/layer 3 IP connectivity, which is what lets a user reach the SIP capabilities and services they're getting 🦋.

Sometimes the SIP server providing services wants to know what kind of access network the UA is on 🤔. Some services are a better or worse fit depending on the access type, and some are way more valuable to subscribers when the proxy knows the access network details 💖.

Other times the server just wants rough location info so it can offer certain services 🗺️. Lots of location based services in wireless networks today need the home network to know which cell the user is being served by 📶.

There are also regulatory requirements saying that, for cellular radio systems, the identity of the cell where an emergency call is established has to be made available to the emergency authorities 🚨.

So the SIP server providing services to the user may want knowledge about the access network 🧠. To make that happen, we define a new private SIP extension header called P-Access-Network-Info 🎀. It carries info about the access network between the UAC and its serving proxy in the home network 🏠.

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

This mechanism is a good fit in environments where SIP services depend on SIP elements knowing the details about the IP and lower layer technologies a UA uses to connect to the SIP network 🔌. Specifically, the extension needs the UA to know which access technology it's using, and a proxy to want that info so it can provide services 💅. Generally, SIP is built on the "Everything over IP and IP over everything" principle, where the access technology isn't relevant for how SIP operates 🌈. Since SIP systems generally should not care or even know about the access technology, this SIP extension is not for general SIP usage 🙅‍♀️.

The info in the P-Access-Network-Info header is potentially very sensitive 😭. Protecting it properly depends on specific business and security relationships between the proxies that will see SIP messages containing this header 🔐. It also depends on the UA explicitly knowing that those relationships exist 🫶. So this mechanism is only suitable in environments where the right relationships are in place and the UA explicitly knows they exist 💜.

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

When a UA creates a SIP request or response that it knows is going to be securely sent to its SIP proxy providing services, it puts a P-Access-Network-Info header into the message ✉️. That header holds info on the access network the UA is using to get IP connectivity 📡. Intermediate proxies between the UA and the service proxy typically ignore the header 🙈. The service proxy can inspect the header and use the info inside to provide appropriate services, depending on the header's value ✨. Before it proxies the request onwards, that service proxy strips the header off the message 💅.

4.4.2.1 UA behavior

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

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

To do the deletion of the header, there also has to be transitive trust in the intermediate proxies between the UA and the proxy providing the services 🤝. That trust is established by business agreements between the home network and the access network, and it's generally backed up by standard security mechanisms, e.g., IPsec, AKA, and TLS 🛡️.

4.4.2.2 Proxy behavior

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

A proxy providing services to the UA may act upon any info present in the header value, if it's present, to provide a different service depending on the network or the location the UA is accessing the server through 📍. 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, typically located in the home network and therefore trusted, MUST delete the header when the SIP signaling is forwarded to a SIP server located in a non-trusted administrative network domain 🧹. The SIP server providing services to the UA uses the access network info, and it's of no interest to other proxies in different administrative domains 🙅.

4.5 The P-Charging-Function-Addresses header 💸

3GPP has defined a distributed architecture, which means multiple network entities get involved in providing access and services 🏗️. There's a need to tell each SIP proxy involved in a transaction about the common charging functional entities that should receive the generated charging records or charging events 📬.

The 3GPP solution defines two types of charging functional entities: Charging Collection Function (CCF) and Event Charging Function (ECF) 🧾. CCF is used for off-line charging (e.g., for postpaid account charging) 🐌. ECF is used for on-line charging (e.g., for pre-paid account charging) ⚡. There may be more than a single instance of CCF and ECF in a network, to provide redundancy 🛟. If there's more than one 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 in the sequence (if any) in the P-Charging-Function-Addresses header 🔁. The CCF and ECF addresses may be passed during the establishment of a dialog or in a standalone transaction 🧚. More detailed info about charging can be found in 3GPP TS 32.200 [16] and 3GPP TS 32.225 [17] 📚.

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

How a SIP proxy collects the values to fill the P-Charging-Function-Addresses header is outside the scope of this document 🙃. As an example, a SIP proxy may have preconfigured these addresses, or it may obtain them from a subscriber database 🗂️.

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

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

The P-Charging-Function-Addresses header is not included in a SIP message sent outside of the own administrative domain 🚧. The header is not applicable if the administrative domain doesn't provide a charging function 🙅‍♀️.

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

  1. A UA sends a REGISTER or dialog-initiating request (e.g., INVITE) 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 located in the administrative domain of the private network wants to generate charging records.
  3. A registrar, proxy or UA located in the private network has access to the addresses of the charging function entities for that network.
  4. There are other proxies located in the same administrative domain of the private network that generate charging records or charging events. Those proxies want to send the charging information, by means outside SIP, to the same charging collecting entities as the first proxy 🫶.

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

A SIP proxy that receives a SIP request MAY insert a P-Charging-Function-Addresses header prior to forwarding the request, if the header wasn't already present in the SIP request 🦋. The header value contains one or more parameters that hold the hostnames or IP addresses of the nodes that are willing to receive charging information 📨.

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

4.5.2.1 Procedures at the UA

This document doesn't specify any procedure at the UA with regard to the P-Charging-Function-Addresses header 🤷‍♀️. UAs need not understand this header 💅.

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

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 MAY insert a P-Charging-Function-Addresses header prior to forwarding the message 🌸. The header is populated with a list of the addresses of one or more charging entities where the proxy should send charging related information 📋.

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

4.5.2.3 Examples of Usage ✨

Okay bestie, let's walk through an example in this scenario 🗺️

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

In this scenario, 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 lands at UA2 📞 P1 is the outbound proxy for UA1. In this case, P1 also inserts charging information, then routes the call through P2 to UA2 💸

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

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

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

Now P1 and P2 both know the IP addresses of the entities that collect charging records or charging events 🙌 That means both proxies can send their charging info to the very same entities. Iconic teamwork 💜

4.6 The P-Charging-Vector header 💖

3GPP has defined a distributed architecture, which means multiple network entities get involved in providing access and services 🌐 Operators need the freedom to charge for that access and those services however they see fit 💅 That requires the entities (for example, SIP proxies) to coordinate with each other, and part of that is correlating the charging records that different entities create for the same session 🧩

The correlation info includes, but isn't limited to, a globally unique charging identifier, which makes billing way easier 🎀

A charging vector is a collection of charging information 📦 It can be filled in while a dialog is being set up, or for a standalone transaction outside a dialog. The info inside it may be filled in by multiple network entities (including SIP proxies), and it may be read by multiple network entities too 👀 There are three types of correlation information that get transferred: the IMS Charging Identity (ICID) value, the address of the SIP proxy that creates the ICID value, and the Inter Operator Identifiers (IOI) 🦋

The ICID is a charging value that identifies a dialog or a transaction outside a dialog 🪪 It's used to correlate charging records. The ICID MUST be a globally unique value. One way to get global uniqueness is to build the ICID from two parts: a locally unique value, plus the host name 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 🛫🛬 An IOI may be generated from each side of the dialog, so that each side's network is identified 🌈

There's also access network charging information expected to be present 📡 It consists of network-specific identifiers for the access level (for example, a UMTS radio access network or IEEE 802.11b). This memo doesn't describe the details of the information for each type of network, so no spoilers here 🙈

We define the SIP private header P-Charging-Vector. 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. Only one instance of the header MUST be present in a particular request or response 🧁

How a SIP proxy gathers the values that fill in the P-Charging-Vector is outside the scope of this document 🤷‍♀️

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

The P-Charging-Vector header applies within a single private administrative domain, or between different administrative domains that have a trust relationship with each other 🤝

The P-Charging-Vector header is not included in a SIP message sent to another network if there's no trust relationship. The header doesn't apply if the administrative domain handles charging in a way that doesn't need records from multiple network entities (for example, SIP proxies) to be correlated 🙅‍♀️

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

  1. A UA sends a REGISTER or dialog-initiating request (for example, INVITE), or a standalone transaction request outside a dialog, to a proxy located in the administrative domain of a private network 📬
  2. A registrar, proxy, or UA located in the administrative domain of the private network wants to generate charging records 📝
  3. A proxy or UA 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 passed through on their way to the first private network, wants to generate charging records and correlate those records with the ones from 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 🛠️

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

Typically, a SIP proxy that receives a SIP request without a P-Charging-Vector header may insert one, filled with whichever parameters are available at that SIP proxy 🧚

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

4.6.2.1 Procedures at the UA 🙋‍♀️

This document doesn't specify any procedure at the UA for the P-Charging-Vector header. UAs don't need to understand this header 😌

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 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 that has the P-Charging-Vector header, it may pull the information out of the header value and use it for application-specific logic, that is, charging 💰 If the next hop for the message is within the trusted domain, then the proxy SHOULD include the P-Charging-Vector header in the outbound message 🫡 If the next hop is outside the trusted domain, then the proxy MAY remove the P-Charging-Function-Addresses header 🧹

Depending on 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 🍓

Let's look at an example in this scenario:

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

This example shows the message sequence for an INVITE transaction that starts at UA1 and eventually arrives at UA2 📞 P1 is the outbound proxy for UA1. In this case, P1 also inserts charging information, then routes the call through P2 to UA2 ⚡

Message sequence for INVITE using P-Charging-Vector:

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

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

5. Formal Syntax 📜

All of the mechanisms in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [3] 🧠 Several BNF definitions are inherited from SIP and aren't repeated here, so you'll need to be familiar with the notation and contents of SIP [1] and RFC 2234 [3] to follow along 🤓

5.1 P-Associated-URI header syntax 🔗

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

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

5.2 P-Called-Party-ID header syntax 📣

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

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

5.3 P-Visited-Network-ID header syntax 🌍

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

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

5.4 P-Access-Network-Info header syntax 📶

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

   P-Access-Network-Info  = "P-Access-Network-Info" HCOLON
                            access-net-spec
   access-net-spec        = access-type *(SEMI access-info)
   access-type            = "IEEE-802.11a" / "IEEE-802.11b" /
                            "3GPP-GERAN" / "3GPP-UTRAN-FDD" /
                            "3GPP-UTRAN-TDD" /
                            "3GPP-CDMA2000" / token
   access-info            = cgi-3gpp / utran-cell-id-3gpp /
                            extension-access-info
   extension-access-info  = gen-value
   cgi-3gpp               = "cgi-3gpp" EQUAL
                            (token / quoted-string)
   utran-cell-id-3gpp     = "utran-cell-id-3gpp" EQUAL
                            (token / quoted-string)

The access-info may contain additional information relating to the access network 💫 The values for "cgi-3gpp" and "utran-cell-id-3gpp" are defined in 3GPP TS 24.229 [15] 💖

5.5 P-Charging-Function-Addresses header syntax

okay so the P-Charging-Function-Addresses header has its own grammar, and it's giving very organized 💅

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

5.6 P-Charging-Vector header syntax

the P-Charging-Vector gets its own grammar too 🎀

P-Charging-Vector     = "P-Charging-Vector" HCOLON icid-value
                        *(SEMI charge-params)
charge-params         = icid-gen-addr / orig-ioi /
                        term-ioi / generic-param
icid-value            = "icid-value" EQUAL gen-value
icid-gen-addr         = "icid-generated-at" EQUAL host
orig-ioi              = "orig-ioi" EQUAL gen-value
term-ioi              = "term-ioi" EQUAL gen-value

bestie, the P-Charging-Vector has to include the icid-value parameter. that's the IMS charging ID, and it's the thing that lets people match up charging records and events later 🧚 the first proxy that gets the request is the one that makes this value ✨

the icid-gen-addr parameter holds the host name or IP address of the proxy that generated the icid-value. so you always know who made it 👑

the orig-ioi and term-ioi parameters are the originating and terminating interoperator identifiers. they're how charging records get correlated between different operators 🌈 the originating ioi stands for the network that's responsible for the charging records on the originating side of the session or standalone request. the terminating ioi does the same job for the terminating side 💜

5.7 Table of new headers

okay so Table 1 takes the headers from this document and extends them into a bunch of other SIP docs. it's a whole family tree 🦋 the table covers Table 2 in SIP [1], section 7.1 of the SIP-specific event notification [6], tables 1 and 2 in the SIP INFO method [8], tables 1 and 2 in Reliability of provisional responses in SIP [7], tables 1 and 2 in the SIP UPDATE method [9], tables 1 and 2 in the SIP extension for Instant Messaging [10], and table 1 in the SIP REFER method [11]:

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

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

                    Table 1: Header field support

6. Security Considerations

okay this part is serious, so let's go 🔥 security is not a vibe we skip!

6.1 P-Associated-URI

the info in the P-Associated-URI header isn't seen as super sensitive 💅 it's mostly informational, so the UAC can see what the registrar automatically associated. if there's no end-to-end protection at the SIP layer, proxies between the registrar and the UA could change what the header says. annoying? yes. a big disaster? nah, it shouldn't have major impacts 🙈

the lack of encryption, end-to-end or hop-by-hop, can leak some privacy about the list of authorized identities. like, a user who registers sip:user1@example.com might get another SIP URI, sip:first.last@example.com, back in the P-Associated-URI header. an eavesdropper could collect that. if the user doesn't want those associated URIs out there, the eavesdropper could get access to private URIs 😭 so it is RECOMMENDED that this extension gets used in a secured environment, where SIP messages are encrypted either end-to-end or hop-by-hop 🔒

6.2 P-Called-Party-ID

because of how the P-Called-Party-ID header works, it doesn't add any big security concern 🌸 an attacker can change what the header says, but that won't hurt session establishment.

an eavesdropper may collect the list of identities a user is registered with, and that can have privacy implications. to help with that, this extension SHOULD only be used in a secured environment, where SIP messages are encrypted either end-to-end or hop-by-hop 💜

6.3 P-Visited-Network-ID

the P-Visited-Network-ID header assumes there's a trust relationship between a home network and one or more visited networks it passes through 🦋 other proxies sitting between the visited-network proxy that inserts the header and the registrar or home proxy could change the P-Visited-Network-ID value. so intermediaries in this mechanism MUST apply a hop-by-hop integrity protection mechanism, such as IPsec or other available mechanisms, to prevent these attacks 🛡️

6.4 P-Access-Network-Info

the Trust Domain is formally defined in the Short term requirements for Network Asserted Identity [13] document. for this doc, the 3GPP trust domain means the collection of SIP proxies and application servers run by a 3GPP network operator that follow the requirements in 3GPP TS 24.229 [15] 🎀

this extension assumes the UA trusts the access network, because the UA's home network has a trust relationship with that access network, as covered earlier in this doc.

the info the UAC adds to the header should only go to trusted entities, and it shouldn't be used outside the trusted administrative network domain 🌈

the SIP proxy that provides services to the user uses the info in this header to offer extra services, and UAs are expected to give correct info. but there are no security problems if a UA inserts incorrect info. networks that base services on what's in the P-Access-Network-Info header will need to trust the UA sending it. a rogue UA that sends false access network info will do no more harm than stopping the user from using certain services 🙃

this mechanism was designed mostly for private systems like 3GPP, and most security requirements get met through private standardized solutions 🧚

for example, 3GPP uses the P-Access-Network-Info header to carry fairly sensitive stuff like the cell ID. so that info MUST NOT be sent outside the 3GPP domain 🚫

a 3GPP UA knows it's operating within a trusted domain.

the 3GPP UA also knows whether a secure association to the home network domain for transporting SIP signaling is currently available. because of that, the sensitive info in the P-Access-Network-Info header SHOULD NOT be sent in any initial unauthenticated and unprotected requests (e.g., REGISTER) 👀

any UA using this extension that isn't part of a private trusted domain shouldn't treat the mechanism as secure, so it SHOULD NOT send sensitive info in the P-Access-Network-Info header 😬

any proxy operating in a private trust domain where the P-Access-Network-Info header is supported is required to delete the header, if it's present, from any message before forwarding it outside the trusted domain 🗑️

so a network that requires its UA to send info in the P-Access-Network-Info header has to make sure either that the info isn't sensitive, or that it never gets sent outside the trust domain. no shortcuts, babe 💅

a proxy that gets a message with the P-Access-Network-Info header from a non-trusted entity can't guarantee the validity of the contents 😭

6.5 P-Charging-Function-Addresses

it's totally expected, as normal behavior, that proxies within a closed network will modify the values of the P-Charging-Function-Addresses header and insert it into a SIP request or response 🫶 but the proxies that share this info MUST have a trust relationship.

if an untrusted entity got inserted between trusted entities, it could swap in a different charging function address. so an integrity protection mechanism, such as IPsec or other available mechanisms, MUST be applied to prevent these attacks. since each trusted proxy might need to view or modify the values in the P-Charging-Function-Addresses header, the protection should be applied hop-by-hop 🔐

6.6 P-Charging-Vector

same energy here 🌸 it's normal for proxies in a closed network to modify the values of the P-Charging-Vector and insert it into a SIP request or response. but the proxies sharing this info MUST have a trust relationship.

if an untrusted entity got inserted between trusted entities, it could mess with the charging correlation mechanism 😤 so an integrity protection mechanism, such as IPsec or other available mechanisms, MUST be applied to prevent these attacks. since each trusted proxy might need to view or modify the values in the P-Charging-Vector header, the protection should be applied hop-by-hop 🔒

7. IANA Considerations

this document defines several private SIP extension header fields, and they all start with the prefix "P-" 🎀

those extension headers got added to the registry of SIP header fields defined in SIP [1]. the Working Group handled the expert review that process needs, so that's sorted 💜

these extensions are registered as private extension header fields:

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


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


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


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


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


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

8. Contributors

the extensions in this document were first specified across several docs, and the people behind them deserve the flowers 💐 Miguel Garcia-Martin authored the P-Associated-URI, P-Called-Party-ID, and P-Visited-Network-ID headers 🌟 Duncan Mills authored the P-Access-Network-Info header 🍓 Eric Henrikson authored the P-Charging-Function-Addresses and P-Charging-Vector headers 🧁 and Rohan Mahy helped bring all of these extensions together into a single document 👑

9. Acknowledgments 🎀

okay so the authors gave a big shoutout to 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 reviewing this doc and leaving their comments. literally the real MVPs ✨

10. Normative References 📚

bestie, these are the docs you MUST have read to actually get this one. no skipping 💅

  • [1] 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.
  • [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

11. Informative References 🦋

these ones are more like "good to know" reads, not required reading, but they're giving context ngl 🌸

  • [4] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", Work in Progress.
  • [5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
  • [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
  • [7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
  • [8] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
  • [9] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
  • [10] Campbell, B., Editor, Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
  • [11] Sparks, R., "The SIP Refer Method", Work in Progress.
  • [12] Barnes, M., "SIP Generic Request History Capability Requirements", Work in Progress.
  • [13] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
  • [14] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS); Stage 2 (Release 5)", 3GPP 23.228, September 2002, <ftp://ftp.3gpp.org/Specs/archive/23_series/23.228/>.
  • [15] 3GPP, "TS 24.229: IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 5)", 3GPP 24.229, September 2002, <ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
  • [16] 3GPP, "TS 32.200: Telecommunication Management; Charging management; Charging principles (Release 5)", 3GPP 32.200, June 2002, <ftp://ftp.3gpp.org/Specs/archive/32_series/32.200/>.
  • [17] 3GPP, "TS 32.225: Telecommunication Management; Charging management; Charging Data Description for IP Multimedia Subsystem (Release 5)", 3GPP 32.225, September 2002, <ftp://ftp.3gpp.org/Specs/archive/32_series/32.225/>.

Authors' Addresses 💌

the squad behind this RFC 💖

  • Miguel A. Garcia-Martin, Ericsson, Hirsalantie 11, Jorvas FIN-02420, Finland, EMail: miguel.a.garcia@ericsson.com
  • Eric Henrikson, Lucent, 11601 Willows Rd, Suite 100, Redmond, WA 98052, USA, EMail: ehenrikson@lucent.com
  • Duncan Mills, Vodafone, The Courtyard, 2-4 London Road, Newbury, Berkshire RG14 1JX, UK, EMail: duncan.mills@vf.vodafone.co.uk

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. 🫶

📦 where this page comes from