RFC 5503
Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture
Private SIP Proxy-to-Proxy Extensions for PacketCable DCS 💖
Okay bestie, this is RFC 5503 🎀 It's an Informational doc (so it's not a formal Internet standard 🌸) published by the IETF in March 2009. The title is Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture. It was written by F. Andreasen (Cisco), B. McKibben (CableLabs), and B. Marshall (AT&T) ✨. It obsoletes RFC 3603 and doesn't list any documents it updates 🦋.
This is Part 1 of 7 🧚 Let's go!
Status of This Memo ✨
This memo is just here to give information to the Internet community 💅 It is not a standard of any kind. Distribution is totally unlimited, so share away 🌈
Copyright Notice 💜
Copyright (c) 2009 belongs to the IETF Trust and the people named as the document's authors. All rights reserved 🔒
This doc falls under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were on the publication date. Please actually read those, bestie, because they spell out what you can and can't do with it 🫶 You can find them at http://trustee.ietf.org/license-info.
Here's the tricky bit 💀 Some material in here came from IETF Documents or IETF Contributions that were published or made public before November 10, 2008. The people who own the copyright on some of that stuff may not have given the IETF Trust permission to allow changes outside the IETF Standards Process. So unless you've got a proper license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and you can't make derivative works outside it either. The one exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🌸
Abstract 🦋
So here's the big picture 🌟 To run residential phone service at massive scale across different domains, trusted elements owned by different service providers have to swap trusted info. That info carries customer-specific details and expectations about the parties on the call 👑
This doc describes private extensions to the Session Initiation Protocol (SIP), as defined in RFC 3261 💅 They let trusted entities in the PacketCable Distributed Call Signaling Architecture exchange customer information and billing information. The extensions cover a lot of ground 😭 They support access network coordination to prevent theft of service, let a customer trace harassing calls, and support operator services and emergency services, plus various other regulatory stuff.
The big catch is that these extensions are only meant for closed administrative domains, or for federations of administrative domains that have agreed on policies ahead of time, where coordinating charging and other functions is required 🔥 Don't go using them anywhere else 🙈
Table of Contents 🎀
1. Applicability Statement .........................................4
2. Introduction ....................................................4
3. Trust Boundary ..................................................6
4. Conventions Used in This Document ...............................7
5. P-DCS-TRACE-PARTY-ID ............................................7
5.1. Syntax .....................................................8
5.2. Procedures at an Untrusted User Agent Client (UAC) .........9
5.3. Procedures at a Trusted User Agent Client (UAC) ............9
5.4. Procedures at an Untrusted User Agent Server (UAS) .........9
5.5. Procedures at a Trusted User Agent Server (UAS) ............9
5.6. Procedures at Proxy .......................................10
5.6.1. Procedures at Originating Proxy ....................10
5.6.2. Procedures at Terminating Proxy ....................11
6. P-DCS-OSPS .....................................................11
6.1. Syntax ....................................................11
6.2. Procedures at an Untrusted User Agent Client (UAC) ........12
6.3. Procedures at a Trusted User Agent Client (UAC) ...........12
6.4. Procedures at an Untrusted User Agent Server (UAS) ........13
6.5. Procedures at a Trusted User Agent Server (UAS) ...........13
6.6. Procedures at Proxy .......................................14
7. P-DCS-BILLING-INFO .............................................14
7.1. Syntax ....................................................16
7.2. Procedures at an Untrusted User Agent Client (UAC) ........18
7.3. Procedures at a Trusted User Agent Client (UAC) ...........18
7.4. Procedures at an Untrusted User Agent Server (UAS) ........18
7.5. Procedures at a Trusted User Agent Server (UAS) ...........18
7.6. Procedures at Proxy .......................................19
7.6.1. Procedures at Originating Proxy ....................19
7.6.2. Procedures at Terminating Proxy ....................20
7.6.3. Procedures at Tandem Proxy .........................21
8. P-DCS-LAES and P-DCS-Redirect ..................................21
8.1. Syntax ....................................................23
8.2. Procedures at an Untrusted User Agent Client (UAC) ........24
8.3. Procedures at a Trusted User Agent Client (UAC) ...........24
8.4. Procedures at an Untrusted User Agent Server (UAS) ........25
8.5. Procedures at a Trusted User Agent Server (UAS) ...........25
8.6. Procedures at Proxy .......................................26
8.6.1. Procedures at Originating Proxy ....................26
8.6.2. Procedures at Terminating Proxy ....................28
9. Security Considerations ........................................29
10. IANA Considerations ...........................................29
11. Changes since RFC 3603 ........................................31
12. Acknowledgments ...............................................32
13. References ....................................................32
13.1. Normative References .....................................32
13.2. Informative References ...................................331. Applicability Statement 🌸
This is the part that tells you where this stuff actually works 🧚 The Session Initiation Protocol (SIP) [RFC3261] extensions in this doc assume certain things about network topology, how SIP links to the layers below it, and the availability of transitive trust 😭 Those assumptions usually don't hold across the Internet as a whole, so please don't assume they do 🙈
As for where these headers are allowed: they're only for closed administrative domains, or federations of administrative domains that agreed on policies beforehand, where charging and other functions need coordinating. The architecture in [DCSARCH] is a good example 💅 Using them outside that kind of setup could leak sensitive or private info, which is not a vibe ⚠️ Users should also give their consent to the privacy implications of the policies in [DCSARCH], and that's strongly encouraged inside those domains too 🫶
One more thing, and it's important 💖 This doc uses [RFC2119] language, but the normative language only applies inside the area this doc covers. Like the technology itself, it doesn't extend to the general Internet 🌈
2. Introduction ✨
okay so bestie, the big goal here is deploying a SIP based residential phone service at super huge scale across different domains 📞🌸. That means trusted boxes owned by different service providers have to swap trusted info about billing and about the people on the call. no cap, that's the whole vibe 💅
There are lots of billing models for making money off phone service today 💸. Charging for calls is tightly tied to how network resources get used. Going through all those numerous and varying methods is outside the scope of this doc, so we're not doing that here 🙈
A key principle behind the Distributed Call Signaling (DCS) architecture described in [DCSARCH] is that network service providers need to be able to control and monitor network resources 👑. They can earn revenue from using those resources, and also from delivering enhanced services like telephony. DCS also gets that call signaling and resource management need to work together 🫶. This teamwork makes sure users are authenticated and authorized before they get access to network resources and billable enhanced services. iconic, honestly 🔥
DCS Proxies, as defined in [DCSARCH], have access to subscriber information and act as policy decision points and trusted intermediaries along the call signaling path 🧚. Edge routers provide the network connectivity and the resource policy enforcement mechanism, and they also capture and report connectivity and resource usage information 🦋. Edge routers need billing info they can log with Record-Keeping or Billing servers. The DCS Proxy is the central point where call signaling and resource management meet, so it can provide that info based on the authenticated identity of the calling and called parties 💖. Since DCS Proxies trust each other, they can be relied upon to exchange trusted billing information about the parties in a call ✨. See [DCSARCH] for a description of the trust boundary and of trusted versus untrusted entities 💜.
So for all these reasons, it makes sense to consider defining SIP header extensions that let DCS Proxies exchange information during call setup 🎀. The extensions only show up on trusted network segments, get inserted when entering a trusted network region, and get removed before leaving trusted network segments 🌈.
A ton of information gets pulled by an originating DCS Proxy while it's handling a connection setup request from a user agent 😭. That includes location info about the subscriber (super essential for emergency services calls), billing info, and station info (like a coin-operated phone) 🍓. Also, while translating the destination number, stuff like the local-number-portability office code gets obtained, and every other proxy handling that call will need it too 🔥.
For Usage Accounting records, you need an identifier that can be attached to all the event records made for a call 📝. The SIP Call-ID header field can't be that identifier, bestie 🙅♀️. It's chosen by the originating user agent, and it may not be unique across all past calls and current calls. Also, since the service provider is the one using this identifier, it should be picked in a manner and a format that meets the service provider's needs 💅.
Billing info may not be unique for each user (think of calls from an office, all billed to the same account) 🏢. It may also not be identical for every call one user makes (think prepaid calls, credit card calls, collect calls, and so on) 💳. So billing info has to be carried separately from the calling and called party identification 🦋. Some billing models also call for split-charging, where multiple entities get billed for portions of the call 🍰.
Adding a SIP General Header Field lets you capture billing info and billing identification for the duration of the call 🎀.
The billing extensions only appear on trusted network segments, and a DCS Proxy MAY insert them in INVITE and REFER requests and INVITE responses in a trusted network segment. They get removed before leaving trusted network segments 🫧.
Current residential phone service needs even more than billing 😳. There's customer-originated trace (for harassing or obscene calls) 📵, operator services like busy line verification and emergency interrupt (started by an operator from an Operator Services Position System (OSPS)) ☎️, emergency services like 9-1-1 calls to a Public Service Access Point (PSAP) and the handling that follows 🚨, and support for Electronic Surveillance and Law Enforcement access as required by applicable legislation and court orders ⚖️. In all of these cases, extra info about the call and the subscribers on it needs to be exchanged between the proxies 🧠.
3. Trust Boundary 🛡️
The DCS architecture [DCSARCH] draws a trust boundary around the various systems and servers owned by, operated by, and/or controlled by the service provider 🏰. Those trusted systems include the proxies and servers like bridge servers, voicemail servers, announcement servers, and so on. Outside the trust boundary, you'll find the customer premises equipment and various application and media servers run by third-party service providers 🌍.
Certain subscriber-specific info, like billing and accounting info, stays inside the trust boundary 🔒. Other subscriber-specific info, like endpoint identity, may be shown to untrusted endpoints, or it may be withheld based on subscriber profiles 🫣.
The User Agent (UA) might be inside the trust boundary or outside it, depending on exactly what function is being performed and exactly how 🤷♀️. So the procedures a user agent follows are different depending on whether the UA is inside or outside the trust boundary 💜.
That's why the procedures for user agents are split into trusted user agents and untrusted user agents 🎀. And since UAs can support client and server functions, the UA sections include procedures for the User Agent Client (UAC) and User Agent Server (UAS) 🧚.
4. Conventions Used in This Document 📚
Here's the key-word stuff, bestie 🤓. 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, [RFC2119] 🫶.
The term "private-URL" refers to a SIP URI that is generated by a proxy, contains a "hostport" that identifies the proxy, and contains a "userinfo" string that is generated by the proxy too 🦋. The userinfo typically contains (or points to) info that is not to be disclosed outside the trusted domain of the proxies. Examples are billing account numbers, electronic surveillance indication, electronic surveillance parameters, and call redirection information 🕵️♀️. So the info is either stored locally by the proxy, or encrypted with a private key known only to the proxy and encoded in a character string in the userinfo portion of the URL 🔐. A checksum is included in the userinfo data to detect tampering 🚫.
The mechanism a proxy uses to recognize a userinfo as a private-URL, and to decode and recover the original info, is local to the proxy and is not subject to standardization 🙃. Some possible implementations include an initial magic cookie (for example, z9hG4Bk followed by the pointer/information), or use of a reserved "user" name (for example, "private") with the optional "password" containing the pointer/information 🧁.
5. P-DCS-TRACE-PARTY-ID 🕵️♀️
In the telephone network, calling identity info supports regulatory stuff like the Customer Originated Trace service 📞. That service lets the called party report obscene or harassing calls to law enforcement 🚓. It works independently of caller-id, and even works if the caller asked for anonymity 🎭. Here, the calling party is identified as the station that originated the call. For this service to be dependable, the called party has to be able to trust that the calling identity info being presented is valid 💯. One way to do that is described in [RFC3325] 🔑.
To start a customer-originated-trace from an untrusted User Agent Client (UAC), there's an additional header defined for the INVITE request ✨. It's called P-DCS-Trace-Party-ID, and it doesn't appear in any other request or response 🙅♀️. The untrusted UAC also includes the Target-Dialog header field, defined in [RFC4538], in the INVITE request, so it can explicitly identify the call to be traced 🎯. The entity addressed by the Request-URI does the service-provider-specific work of recording and reporting the caller identity in the P-DCS-Trace-Party-ID, for law enforcement action 👮♀️. Then it forwards the call to either an announcement server or the service provider's business office, to collect more info about the complaint 📋. A trusted UAC doesn't use this header, because it starts this action locally 🫡.
5.1. Syntax 🧩
The ABNF description of this header is below (some terms used in this ABNF are defined in [RFC3261]) 🤓:
P-DCS-Trace-Party-ID = "P-DCS-Trace-Party-ID" HCOLON name-addr
*1(SEMI timestamp-param) *(SEMI trace-param)
timestamp-param = "timestamp=" 1*DIGIT ["." 1*DIGIT]
trace-param = generic-param ; defined in RFC 3261This document adds the following entry to Table 2 of [RFC3261] 📊:
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-Trace-Party-ID R dmr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -The addr-spec contained in name-addr holds a URL that identifies the remote endpoint 🎯. Addr-spec typically contains a tel URL or SIP URI giving the identity of the remote endpoint, as provided in the signaling messages that set up the session to be traced 📞.
The timestamp-param holds the value of the time the UA determines it received the session initiation request of the call that's requested to be traced ⏰. The timestamp-param is populated using the Network Time Protocol timestamp format defined in RFC 1305 [RFC1305], which is also used by the Simple Network Time Protocol [RFC4330] 🕰️. The timestamp SHOULD be encoded in UTF-8 Format per [RFC3629] 🔤. And the trace-param is a generic parameter for future extensions 🔮.
Here's an example of the P-DCS-Trace-Party-ID header 💖:
P-DCS-Trace-Party-ID: <sip:+12345678912@domain.com;user=phone>;
timestamp=3434688831.23275.2. Procedures at an Untrusted User Agent Client (UAC) 💌
Okay bestie, an untrusted UAC MUST insert a P-DCS-Trace-Party-ID header into the initial INVITE message for a customer-originated-trace request 🕵️♀️ The trace request can be kicked off during the dialog, or even after the dialog or call being traced has been released. The UAC MUST use a SIP URI in the Request-URI with userinfo set to "call-trace" and hostport identifying the call tracing entity for the untrusted UA 🎯 The [RFC3603] version of the header didn't have the timestamp-param parameter, but the syntax is backwards compatible with [RFC3603], so no drama 🫶 A UAC that follows this updated spec MUST insert the timestamp and the Target-Dialog header field defined in [RFC4538] if the UAC knows them.
Now the anonymous situation 🙈 If it's an anonymous malicious call and the remote party is not known to the untrusted UAC, the untrusted UAC SHOULD indicate the user as anonymous in the P-DCS-Trace-Party-ID. For example, it looks like this: sip:anonymous@anonymous.invalid
5.3. Procedures at a Trusted User Agent Client (UAC) 🎀
A trusted UAC handles the customer-originated-trace in a way that's pretty similar to the trusted User Agent Server (UAS), which we'll get to below ✨ The big rule here is that a trusted UAC MUST NOT include this header in any request 🚫
5.4. Procedures at an Untrusted User Agent Server (UAS) 🧚
This header MUST NOT appear in any response sent by a UAS. Not in any response, bestie 💀
5.5. Procedures at a Trusted User Agent Server (UAS) 👑
Here's the main event 🔥 If the P-DCS-Trace-Party-ID header is in the initial INVITE request from a UAC, and the Request-URI of that INVITE has userinfo set to "call-trace" and hostport set to the UAS, then the UAS MUST perform the service-provider-specific functions of recording and reporting the caller identity and any associated trace parameters from the Target-Dialog header field, for law enforcement action 🚨 After that, the UAS MUST redirect the call with a 3xx response to either an announcement server or the service provider's business office, so they can collect more info about the complaint 💅
This header MUST NOT appear in any response sent by a UAS.
Also, if the P-DCS-Trace-Party-ID header is NOT in the initial INVITE request from a UAC, but the Request-URI of the INVITE has userinfo set to "call-trace", the UAS MUST reject the request. No trace without the header, periodt 🙅♀️
5.6. Procedures at Proxy 🦋
There are two sets of proxy procedures: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy 🌈 An originating proxy is a proxy that received the INVITE request from an untrusted endpoint. A terminating proxy is a proxy that sends the INVITE request to an untrusted endpoint.
If a proxy both receives the INVITE request from an untrusted endpoint AND sends it to an untrusted endpoint, it performs both sets of procedures. Double the responsibility, double the glow-up 💖
5.6.1. Procedures at Originating Proxy 🌸
If the P-DCS-Trace-Party-ID header is in the initial INVITE request from the UAC, and the Request-URI of the INVITE has userinfo other than "call-trace", and hostport set to something other than a potentially provisioned call tracing entity, then the proxy MAY reject the request, or it MAY remove the P-DCS-Trace-Party-ID header from the request 🤷♀️ If the header is present in a valid request and contains a private-URL that identifies the proxy in the hostport, then the originating proxy SHOULD replace the private-URL with its original contents. That means the verified identity of the caller of the session being traced, plus the trace parameters from the Target-Dialog header fields defined in [RFC4538] 🔍
The proxy records the caller URL and target dialog IDs on sessions directed toward the untrusted UAC, but only if the network operator provisioned it to do so ⚙️ If the P-DCS-Trace-Party-ID header is in a valid request and contains an anonymous caller indication in the name-addr parameter, the originating proxy MUST replace the anonymous URL with the verified identity of the caller of the session being traced, if that identity is available and recorded by the proxy. Otherwise, the proxy does not replace the anonymous URL 🫣
If the originating proxy is provisioned to store URLs and target dialog IDs for incoming calls, and the proxy notices that the URL and target dialog ID in a trace request do NOT match a recorded incoming dialog request, then the proxy MUST reject the trace call request ❌
Last but not least, the originating proxy does not add the P-DCS-Trace-Party-ID header to a request that doesn't already have it 🙅♀️
5.6.2. Procedures at Terminating Proxy 🌙
This header MUST NOT appear in any request or response sent by a terminating proxy to an untrusted endpoint. Hard boundary, no exceptions 🛑
6. P-DCS-OSPS 📞
Some calls have special call processing needs that normal user agent call processing can't always meet 🎧 For example, when someone is already on a call and another call comes in, that second call might get rejected with a busy signal. But some PSTN operator services need special treatment. Specifically, the Busy Line Verification (BLV) and Emergency Interrupt (EI) services that an operator starts from an Operator Services Position System (OSPS) on the PSTN need this 🧑💼 Emergency calls to a 9-1-1 Public Service Access Point (PSAP) can also cause trunk signaling that makes the operator ringback with a howling tone or a sustained ring on the originating line (this varies by country, fyi 🌍).
So to tell the SIP user agent that a call needs special treatment, we use a new P-DCS-OSPS header 💜 It has a field that can be set to a value that says when a special type of call processing is requested. We define three values: "BLV" for busy line verification, "EI" for emergency interrupt, and "RING" for operator ringback (for example, the howling or sustained tone ring in the US) 🔔
If the user agent decides to honor the request, its response to an INVITE with either "BLV" or "EI" will NOT be a busy indication 📵 Since "EI" and "RING" only happen on established dialogs, they can also show up in UPDATE requests 🔄
6.1. Syntax 🧾
The ABNF for the P-DCS-OSPS header goes like this (some terms used in this ABNF are defined in [RFC3261]):
P-DCS-OSPS = "P-DCS-OSPS" HCOLON OSPS-Tag
OSPS-Tag = "BLV" / "EI" / "RING" / tokenThis document adds the following entry to Table 2 of [RFC3261] 📋
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-OSPS R dr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - o - -The OSPS-Tag value of "token" is defined for extensibility and is reserved for future use 🔮
6.2. Procedures at an Untrusted User Agent Client (UAC) 🚷
The P-DCS-OSPS header MUST NOT be sent in a request from an untrusted UAC. No sneaking it in, bestie 🙅♀️
6.3. Procedures at a Trusted User Agent Client (UAC) 🏛️
This header is usually only inserted by a Media Gateway Controller [DCSARCH] that is controlling a Media Gateway with special trunks to a PSTN OSPS system or PSAP. That trunk group is usually called a BLV-trunk group, and it uses special signaling procedures that stop people from using it by accident 🧯 Calls that start at the PSTN OSPS system get sent over this trunk group, and they result in an INVITE request with the P-DCS-OSPS header.
This header MAY be sent in an INVITE request, and it MUST NOT appear in any message other than the ones listed below 📨
The OSPS-Tag value "BLV" MUST NOT appear in any request other than an initial INVITE request that establishes a new dialog 🆕
The OSPS-Tag value "EI" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a preexisting dialog established with the OSPS-Tag value of "BLV", or (2) an UPDATE request within a preexisting dialog established with the OSPS-Tag value of "BLV" 🚨
The OSPS-Tag value "RING" MUST NOT appear in any request or response other than (1) a subsequent INVITE within a preexisting dialog established by a UAC to an operator or PSAP, or (2) an UPDATE request within a preexisting dialog established by a UAC to an operator or PSAP 🔔
6.4. Procedures at an Untrusted User Agent Server (UAS) 🛡️
If the UAS gets an INVITE request with an OSPS-Tag of "BLV", and the dialog identification matches an existing dialog, it MUST reject the request with a 403 (Forbidden) response 🙅♀️
If the UAS gets an INVITE/UPDATE request with an OSPS-Tag value of "EI" or "RING", and the dialog identification does NOT match an existing dialog that was established with the OSPS-Tag value of "BLV", it MUST reject the request with a 403 (Forbidden) response 🚫
If the UAS gets an INVITE with an OSPS-Tag value of "BLV" and it is not willing to cooperate in offering this service, it MUST reject the request with a 403 (Forbidden) response 🙅♀️
The UAS SHOULD NOT reject an INVITE with a "BLV" OSPS-Tag because of a busy condition 📵 The UAS MUST NOT respond with a 3xx-Redirect response code to an INVITE with a "BLV" OSPS-Tag. And the UAS SHOULD NOT alert the user of the incoming call attempt if the "BLV" OSPS-Tag is present in the INVITE 🔕
If an INVITE with an OSPS-Tag of "BLV" is accepted (for example, when all quality-of-service (QoS) pre-conditions are met), the UAS MUST send an audio stream on this connection to the address and port given in the Session Description Protocol (SDP) of the INVITE 🎶 The UAS MAY mix the two ends of an existing active call and send the resulting media stream to that address and port 🎚️ Or, the UAS MAY send a copy of the local voice stream and, if there's no activity on the local voice stream, send a copy of the received voice stream of an existing call. If the UAS is idle, the UAS SHOULD send a stream of silence packets to OSPS 🤫 If the UAS is ringing or in ringback, the UAS SHOULD send a ringback stream to OSPS 🔁
If an INVITE/UPDATE with an OSPS-Tag of "EI" is accepted, the UAS MUST enable communication between the UAC and the local user 🗣️ The UAS MAY put any existing call on hold, or start an ad hoc conference 🤙
If an INVITE/UPDATE with an OSPS-Tag of "RING" is accepted, the UAS MUST perform operator ringback in accordance with local procedures. For example, it can generate a 3-second howling tone or a sustained ring, depending on the state of the user equipment 🔔
6.5. Procedures at a Trusted User Agent Server (UAS) 👑
The procedures at a trusted UAS MUST be identical to those described in 6.4. Same rules, same glow, no exceptions ✨
6.6. Procedures at Proxy 🌐
In the DCS architecture, the OSPS is considered a trusted UAC 🏅 If a proxy receives a P-DCS-OSPS header in a request from an untrusted source, it MUST either remove the header or reject the request with a 403 (Forbidden) response 🧹
A proxy that implements a call-forwarding service MUST NOT respond to an INVITE request with a 3xx response if the request contained the P-DCS-OSPS header 📞🚫
7. P-DCS-BILLING-INFO ✨
okay billing bestie 💅 there are SO many ways to make money off phone calls and honestly it's a whole mess, tightly tied to network resources. we're not getting into all those methods here 🙈
proxies are the main characters here 👑 they can see subscriber info, make the policy calls, and act as trusted middlemen along the call signaling path. edge routers do the networking and enforce resource policy, and they also record how much connection and resource stuff got used. the edge routers need billing info they can log with Record-Keeping or Billing servers 🧾. the proxy is the central coordinator between call signaling and resource management, so it's the one that can provide this info based on the authenticated identity of the calling and called parties. proxies trust each other, so they can be relied on to swap trusted billing info about the parties in a call 🤝
for Usage Accounting records you need an identifier that can be tied to every event record made for a call 🎀. the SIP Call-ID header field can't do this job, because the originating user agent picks it, and it might not be unique across past and current calls ngl. also, since the service provider is the one using this ID, it should be picked in a way and a format that works for the service provider's needs 💖
billing info isn't always unique per user 💀 think about calls from an office, all billed to the same account. it also isn't always the same for every call a single user makes. think prepaid calls, credit card calls, collect calls, all of it. so the billing info has to be carried separately from the calling and called party identification. and some billing models do split-charging, where multiple entities get billed for different parts of the call 🍰
the new SIP General Header Field is what lets us capture billing info and billing identification for the whole duration of the call. it's giving main character energy ✨
the billing extensions only show up on trusted network segments 🔒. they MAY be inserted by a proxy or trusted UA in INVITE and SUBSCRIBE requests in a trusted network segment, and they get removed before leaving trusted network segments. the P-DCS-Billing-Info header extension is only used on requests and responses between proxies and trusted UAs. it is never sent to an untrusted UA, and untrusted UAs are expected to not send this header 🫶
7.1. Syntax
the DCS-Billing-Info header is defined by the ABNF below (some terms in it come from [RFC3261] 📚):
P-DCS-Billing-Info = "P-DCS-Billing-Info" HCOLON
Billing-Correlation-ID "/" FEID
*(SEMI Billing-Info-param)
Billing-Correlation-ID = 1*48(HEXDIG)
FEID = 1*16(HEXDIG) "@" host
Billing-Info-param = RKS-Group-ID-param / Charge-param /
Calling-param / Called-param /
Routing-param / Loc-Routing-param /
JIP-param / generic-param
RKS-Group-ID-param = "rksgroup" EQUAL RKS-Group-ID
RKS-Group-ID = token
Charge-param = "charge" EQUAL Acct-Charge-URI
Acct-Charge-URI = LDQUOT addr-spec RDQUOT
Calling-param = "calling" EQUAL Acct-Calling-URI
Acct-Calling-URI = LDQUOT addr-spec RDQUOT
Called-param = "called" EQUAL Acct-Called-URI
Acct-Called-URI = LDQUOT addr-spec RDQUOT
Routing-param = "routing" EQUAL Acct-Routing-URI
Acct-Routing-URI = LDQUOT addr-spec RDQUOT
Loc-Routing-param = "locroute" EQUAL Acct-Loc-Routing-URI
Acct-Loc-Routing-URI = LDQUOT addr-spec RDQUOT
JIP-param = "jip" EQUAL jip
jip = LDQUOT 1*phonedigit-hex jip-context RDQUOT
jip-context = ";jip-context=" jip-descriptor
jip-descriptor = global-hex-digits
global-hex-digits = "+" 1*3(phonedigit) *phonedigit-hex
phonedigit = DIGIT / [ visual-separator ]
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator = "-" / "." / "(" / ")"this doc adds one entry to Table 2 of [RFC3261] 📋:
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-Billing-Info admr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -the P-DCS-Billing-Info extension holds an identifier that an event recorder can use to link multiple usage records, maybe from different sources, to one billable account 🧾💫. it also holds the subscriber account info, plus anything else needed for accurate billing of the service. this header is only used between proxies and trusted UAs 🔐
the Billing-Correlation-ID (BCID) is defined in [PCEM] as a 24-byte binary structure. it has 4 bytes of NTP timestamp, 8 bytes for the unique identifier of the network element that made the ID, 8 bytes for the time zone, and 4 bytes of monotonically increasing sequence number from that network element 🌸. this ID is meant to be globally unique within the system for a window of several months. it MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 48 characters. leading zeroes MAY be suppressed 🙌
the Financial-Entity-ID (FEID) is defined in [PCEM] as an 8-byte structure. it holds the financial identifier for that domain, followed by a domain name 🏦. the FEID can be tied to a type of service, and the same provider could assign it to multiple domains. a domain can have multiple assigned FEIDs too. this 8-byte structure MUST be encoded in the P-DCS-Billing-Info header as a hexadecimal string of up to 16 characters. trailing zeroes MAY be suppressed. "Host" is where the domain name goes 🧚
the RKS-Group-ID points to a Record-Keeping server (or a group of cooperating servers) for the event messages about this call 📨. it's used to control certain procedure optimizations when multiple event message streams go to the same Record-Keeping server 🦋
the other parameters hold the info needed to generate event message records 💅. Acct-Charge-URI, Acct-Calling-URI, Acct-Called-URI, Acct-Routing-URI, and Acct-Loc-Routing-URI are each defined as URLs. they should all contain tel URLs with E.164 formatted addresses. these fields get further defined in [PCEM] under the element identifiers "Charge_Number" (element ID 16), "Calling_Party_Number" (element ID 4), "Called_Party_Number" (element ID 5), "Routing Number" (element ID 25), and "Location_Routing_Number" (element ID 22) 🎀
the JIP-param carries the calling jurisdiction information, or numbering plan area, of the network where the call started 🗺️. it's further defined in [PCEM] under the element identifier "Jurisdiction_Information_Parameter" (element ID 82). an older [RFC3603] compliant implementation may not use the JIP-param 🙈
7.2. Procedures at an Untrusted User Agent Client (UAC)
this header is never sent to an untrusted UA, and untrusted UAs are expected to not send it either 🚫
7.3. Procedures at a Trusted User Agent Client (UAC)
the UAC MUST generate the Billing-Correlation-ID for the call 🆔, and put it in the P-DCS-Billing-Info header in the initial INVITE or SUBSCRIBE message sent to the terminating entity, along with the charging info for the call. the UAC MUST include its FEID, and the RKS-Group-ID for the Record-Keeping server the UAC is using. if the UAC did a Local Number Portability (LNP) query, it MUST include the Routing Number and Location Routing Number that the query returned. if it's available to the UAC, the UAC MUST include the JIP-param 💖
if the response to the initial INVITE is a 3xx-Redirect, the UAC makes a new initial INVITE request to the destination in the Contact header field, the standard SIP way 📞. if a UAC gets a 3xx-Redirect response to an initial INVITE, the new INVITE the UAC generates MUST contain the P-DCS-Billing-Info header field values from the 3xx-Redirect response 🔁. if the UAC is acting as a back-to-back user agent (B2BUA), it MAY skip making a new INVITE and generate a private-URL instead, placing it in the Contact header field of a 3xx-Redirect response sent to the originating endpoint. this private-URL MUST contain (or point to) the P-DCS-Billing-Info value, which shows the charging arrangement for the new call, and it MUST have an expiration time very shortly in the future. that limits the originator's ability to reuse this private-URL for multiple calls 🔒✨
a UAC that puts a Refer-To header in a REFER request MUST include a P-DCS-Billing-Info header in the Refer-To's URL. that P-DCS-Billing-Info header MUST include the accounting info of the REFER initiator. no skipping this one, bestie 💅
7.4. Procedures at an Untrusted User Agent Server (UAS)
this header is never sent to an untrusted UAS, and an untrusted UAS never sends it either 🙅♀️
7.5. Procedures at a Trusted User Agent Server (UAS)
the UAS MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE or SUBSCRIBE message 🎉. this P-DCS-Billing-Info header MUST include the Billing-Correlation-ID the UAS generated, the FEID of the UAS, and the RKS-Group-ID of the Record-Keeping server the UAS is using. the UAS MAY change the values of Acct-Charge-URI if it wants to override the billing info that was in the INVITE (for example, on a toll-free call 📞). deciding to do this, and what the new Acct-Charge-URI contains, MUST be determined by service provider policy provisioned in the UAS 📋. if the UAS did an LNP query, it MUST include the Routing Number and Location Routing Number that the query returned 🧚
the UAS MUST add a P-DCS-Billing-Info header to a 3xx-Redirect response to an initial INVITE 🦋. this gives the accounting info for the call forwarder, for the call segment going from the destination to the forwarded-to destination 💜
7.6. Procedures at Proxy 🎀
Okay bestie, there are three flavours of proxy procedures here 💅: (1) the originating proxy, (2) the terminating proxy, and (3) the tandem proxy.
The originating proxy is the one that got the INVITE or SUBSCRIBE request from an untrusted endpoint 🦋.
The terminating proxy is the one that sends the INVITE or SUBSCRIBE request to an untrusted endpoint 🌸.
Any proxy that is neither an originating proxy nor a terminating proxy is a tandem proxy 🧚.
For mid-call changes, like call transfers 🔁, the proxy that receives the request from an untrusted endpoint counts as the initiating proxy, and the proxy that sends the request to a non-trusted endpoint counts as the recipient proxy. The initiating proxy's procedures get bundled with the originating proxy ones, and the recipient proxy's procedures get bundled with the terminating ones 💜.
A proxy that both receives the request from an untrusted endpoint and sends it to an untrusted endpoint does both sets of procedures. Main character energy 👑.
7.6.1. Procedures at Originating Proxy 🦋
The originating proxy MUST generate the Billing-Correlation-ID for the call, and insert it into the P-DCS-Billing-Info header in the initial INVITE or SUBSCRIBE message sent to the terminating entity, along with the charging information for the call. The originating proxy MUST include its FEID and the RKS-Group-ID for the Record-Keeping server being used by the originating proxy. If the originating proxy performed an LNP query, it MUST include the Routing Number, Location Routing Number, and JIP-param returned by the query. Any P-DCS-Billing-Info header present from an untrusted UA MUST be removed 🧹.
If the Request-URI contains a private-URL, and the decoded username contains billing information, the originating proxy MUST generate a P-DCS-Billing-Info header with that decrypted information. Otherwise, the originating proxy MUST determine the accounting information for the call originator and insert a P-DCS-Billing-Info header including that information 📋.
If the response to the initial INVITE is a 3xx-Redirect, received prior to a non-100 provisional response, the originating proxy generates a new initial INVITE request to the destination specified in the Contact header field, as per standard SIP. If an originating proxy receives a 3xx-Redirect response to an initial INVITE prior to a non-100 provisional response, the INVITE generated by the proxy MUST contain the P-DCS-Billing-Info header from the 3xx-Redirect response 🔀.
If the response to the initial INVITE is a 3xx-Redirect, received after a non-100 provisional response, the originating proxy generates a private-URL and places it in the Contact header of a 3xx-Redirect response sent to the originating endpoint. This private-URL MUST contain (or contain a pointer to) the P-DCS-Billing-Info value, which indicates the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the originator to re-use this private-URL for multiple calls. Not letting it be reused for a whole bunch of calls, iconic 🔒.
An originating proxy that processes a REFER request from an untrusted UA MUST include a P-DCS-Billing-Info header in the Refer-To's URL. This P-DCS-Billing-Info header MUST include the accounting information of the initiator 💸.
7.6.2. Procedures at Terminating Proxy 🌸
The terminating proxy MUST NOT send the P-DCS-Billing-Info header to an untrusted destination 🙅♀️.
The terminating proxy MUST include a P-DCS-Billing-Info header in the first reliable 1xx (except 100) or 2xx response to an initial INVITE or SUBSCRIBE message. This P-DCS-Billing-Info header MUST include the Billing-Correlation-ID generated by the terminating proxy, the FEID of the terminating proxy, and the RKS-Group-ID of the Record-Keeping server being used by the terminating proxy. The terminating proxy MAY change the values of Acct-Charge-URI if it wishes to override the billing information that was present in the INVITE (e.g., for a toll-free call). The decision to do this and the contents of the resulting P-DCS-Billing-Info header MUST be determined by service provider policy provisioned in the terminating proxy. If the terminating proxy performed an LNP query, it MUST include the Routing Number and Location Routing Number returned by the query ✨.
The terminating proxy MUST add P-DCS-Billing-Info headers to a 3xx-Redirect response to an initial INVITE, giving the accounting information for the call forwarder, for the call segment from the destination to the forwarded-to destination 🔁.
A proxy receiving a mid-call REFER request that includes a Refer-To header generates a private-URL and places it in the Refer-To header sent to the endpoint. This private-URL MUST contain the P-DCS-Billing-Info value, which indicates the charging arrangement for the new call, and an expiration time very shortly in the future, to limit the ability of the endpoint to re-use this private-URL for multiple calls 🎟️.
7.6.3. Procedures at Tandem Proxy 🧚
If the tandem proxy performed an LNP query, it MUST insert the Routing Number and Location Routing Number returned by the query into the P-DCS-Billing-Info header in the first reliable 1xx/2xx/3xx (except 100) response 🪄.
8. P-DCS-LAES and P-DCS-Redirect 🕵️♀️
NOTE: According to RFC 2804 [RFC2804], the IETF supports documentation of lawful intercept technology if it is necessary to develop it. The following section provides such documentation. The [RFC2119] language, as stated above, describes the requirements of the specification only if implemented, and strictly within the applicability domain described above. See RFC 2804 for description of issues regarding privacy, security, and complexity in relation to this technology. Lowkey a serious topic, so read this one carefully 🫶.
The P-DCS-LAES extension contains the information needed to support Lawfully Authorized Electronic Surveillance. This header contains the address and port of an Electronic Surveillance Delivery Function for delivery of a duplicate stream of event messages related to this call. The header fields MAY also contain the associated BCID for the event stream as well as additional address and port for delivery of call content and associated cccid. The BCID is used to correlate a series of events associated with a single call or session. The cccid is used to identify an intercepted call content to an intercepted call. The P-DCS-LAES header is only used between proxies and trusted UAs. The P-DCS-LAES header defined here is not backwards compatible with that defined in [RFC3603], which is deprecated by the document. This version of the P-DCS-LAES header adds a cccid parameter to support the intercept of content, and deletes security key information. This version does not mandate the use of the BCID 🔍.
The P-DCS-Redirect extension contains call identifying information needed to support the requirements of Lawfully Authorized Electronic Surveillance of redirected calls. This header is only used between proxies and trusted UAs 📞.
Note that there is overlap in function between the P-DCS-Redirect header and the History-Info header specified in RFC 4244. The original P-DCS-Redirect came to existence in RFC 3603 before the History-Info. Therefore, the P-DCS-Redirect header is continued here for backwards compatibility with existing implementations 🕰️.
Use of P-DCS-LAES and P-DCS-Redirect is controlled by a combination of legislation, regulation, and court orders, which MUST be followed. In certain cases, inclusion of these headers will be mandated, and therefore MUST be present in the requests and responses indicated. In other cases, inclusion of these headers will be forbidden, and therefore MUST NOT be present in the request and responses indicated. In the sub-sections that follow, use of "SHOULD" is intended to capture these conflicting situations, e.g., a P-DCS-LAES header SHOULD be included in an initial INVITE means either that it MUST be included or that it MUST NOT be included, based on the applicable court orders 🏛️.
8.1. Syntax 📝
The formats of the P-DCS-LAES and P-DCS-Redirect headers are given by the following ABNF (some terms used in this ABNF are defined in [RFC3261] and [RFC5234]):
P-DCS-LAES = "P-DCS-LAES" HCOLON Laes-sig
*(SEMI Laes-param)
Laes-sig = hostport
Laes-param = Laes-content / Laes-cccid
Laes-bcid / generic-param
Laes-content = "content" EQUAL hostport
Laes-bcid = "bcid" EQUAL 1*48(HEXDIG)
Laes-cccid = "cccid" EQUAL 1*8(HEXDIG)
P-DCS-Redirect = "P-DCS-Redirect" HCOLON Called-ID
*(SEMI redir-params)
Called-ID = LDQUOT addr-spec RDQUOT
redir-params = redir-uri-param / redir-count-param /
generic-param
redir-uri-param = "redirector-uri" EQUAL Redirector
Redirector = LDQUOT addr-spec RDQUOT
redir-count-param = "count" EQUAL Redir-count
Redir-count = 1*DIGITThis document adds the following entry to Table 2 of [RFC3261]:
Header field where proxy ACK BYE CAN INV OPT REG PUB
------------ ----- ----- --- --- --- --- --- --- ---
P-DCS-LAES adr - - - o - - -
P-DCS-Redirect adr - - - o - - -
SUB NOT REF INF UPD PRA MSG
--- --- --- --- --- --- ---
- - - - - - -
- - - - - - -The values of Laes-sig and Laes-content are addresses of the Electronic Surveillance Delivery Function, and used as the destination address for call-identifying information and call-content, respectively. Laes-bcid contains a correlation ID that is used to link a sequence of intercepted call processing events related to a single call. Laes-cccid contains an identifier of the intercepted call content. The Laes-bcid field MAY be present. The BCID is included per network operator configuration to support events reported as defined in [PCEM]. The Laes-cccid field MAY be present when the Laes-content field is present. The Laes-cccid is included per network operator configuration for networks where entities receiving the intercepted contents may act a media relay functions to other surveillance functions that are the source of the content surveillance request. The design of multiple surveillance entities that receive call content is beyond the scope of this document 🧐.
The P-DCS-Redirect header contains redirection information. The Called-ID indicates the original destination requested by the user (e.g., number dialed originally), the redir-uri-param indicates the entity performing the redirection, and the Redir-count indicates the number of redirections that have occurred. For example, if A calls B, who forwards to C, who forwards to D, then, when C forwards to D, the Called-ID will be A, redir-uri-param will be C, and count will be 2 🔁✨.
8.2. Procedures at an Untrusted User Agent Client (UAC) 🚫
This header MUST NOT be sent to an untrusted UAC, and MUST NOT be sent by an untrusted UAC 🙅♀️.
8.3. Procedures at a Trusted User Agent Client (UAC) 💅
okay so the trusted UAC checks whether the originating subscriber has an outstanding lawfully authorized surveillance order 👀. If there is one, it MAY include this info in the Authorization for Quality of Service [PCDQOS] 🎀, or it MAY signal this info to the device doing the intercept (e.g., a Media Gateway) 🫶. If neither of those happens, intercept access points get instructed to do call content and/or call data intercept by mechanisms that are outside the scope of this document 🧚.
If the P-DCS-LAES header shows up in the first reliable 1xx (except 100), 2xx, or 3xx response 🌈 (which means surveillance is needed on the terminating subscriber, but the terminating equipment can't handle that part 😭), the UAC MAY include this info in the Authorization for Quality of Service, or MAY signal it to the device doing the intercept (e.g., a Media Gateway). Otherwise, intercept access points get instructed to do call content and/or call data intercept by mechanisms that are outside the scope of this document 💖.
Now, if a 3xx-Redirect response to the initial INVITE request comes back, and there's a P-DCS-LAES header in that 3xx response, the UAC SHOULD include that header unchanged in the reissued INVITE 🦋. The UAC SHOULD also include a P-DCS-Redirect header with the original dialed number, the most recent redirecting party, and the number of redirections that have occurred 📞. Is it technically possible for the originating equipment to do this surveillance (or add onto its existing surveillance of the call)? Yes 🙃. BUT the surveillance system is designed so the terminating equipment handles surveillance for all the intermediate forwardings, so that's the vibe 🍓.
A UAC that includes a Refer-To header in a REFER request, when the originating subscriber has an outstanding lawfully authorized surveillance order, SHOULD include a P-DCS-LAES header attached to the Refer-To ✨. The UAC MAY also include a P-DCS-Redirect header 💜. The P-DCS-LAES header MAY include the Laes-bcid parameter set to a value that uniquely identifies the call 🆔. It SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages 📨, and it SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is going to be intercepted 🎧. It MAY include the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is going to be intercepted 🎶.
🚨 The trusted UAC MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity. Not even a little bit, bestie 🙅♀️.
8.4. Procedures at an Untrusted User Agent Server (UAS) 🥺
this one is short and sweet 🍬. This header MUST NOT be sent to an untrusted UAS, and MUST NOT be sent by an untrusted UAS 🔒.
8.5. Procedures at a Trusted User Agent Server (UAS) 🌸
the UAS checks for an outstanding lawfully authorized surveillance order for the terminating subscriber, or for the presence of the P-DCS-LAES header in the INVITE request 🔍. If either one is there, the UAS MAY include this info in the authorization for Quality of Service [PCDQOS] 🎀. Otherwise, intercept access points get instructed to do call content and/or call data intercept by mechanisms that are outside the scope of this document 🧚.
If the terminating equipment can't do the required surveillance (for example, if the destination is a voicemail server 📼), the UAS SHOULD include a P-DCS-LAES header in the first reliable 1xx (except 100), 2xx, or 3xx response 🙋♀️, asking the originating proxy to do the surveillance 🫶. The P-DCS-LAES header MAY include the Laes-bcid parameter with a value that uniquely identifies the call 🆔. It SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages 📨, and it SHOULD include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is going to be intercepted 🎧. It MAY include the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is going to be intercepted 🎶.
If the response to the initial INVITE request is a 3xx-Redirect response, and there's an outstanding lawfully authorized surveillance order for the terminating subscriber, the UAS SHOULD include a P-DCS-LAES header in the 3xx-Redirect response, with the contents described above 🦋.
🚨 The trusted UAS MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity. Same energy as the UAC, no exceptions 💅.
8.6. Procedures at Proxy 🧚♀️
there are two sets of proxy procedures: (1) the procedures at an originating proxy, and (2) the procedures at a terminating proxy 🌈. The originating proxy is the proxy that receives the INVITE request from an untrusted endpoint 📥.
The terminating proxy is the proxy that sends the INVITE request to an untrusted endpoint 📤.
For mid-call changes like call transfers, the proxy that receives the request from an untrusted endpoint counts as the initiating proxy 🔁, and the proxy that sends the request to an untrusted endpoint counts as the recipient proxy 📬. The initiating proxy's procedures are included with the originating proxy ones, and the recipient proxy's procedures are included with the terminating proxy ones 🫶.
A proxy that both receives the INVITE request from an untrusted endpoint and sends the INVITE request to an untrusted endpoint MUST NOT generate P-DCS-LAES nor P-DCS-Redirect headers 🙅♀️. And a proxy that is neither an originating proxy nor a terminating proxy SHOULD pass the P-DCS-Laes and P-DCS-Redirect headers along in requests and responses 🎀.
8.6.1. Procedures at Originating Proxy 👑
the originating proxy MUST remove any P-DCS-LAES and P-DCS-Redirect headers in requests or responses to or from an untrusted proxy or untrusted UA 🧹. Bye bye, headers 👋.
The originating proxy checks for an outstanding lawfully authorized surveillance order for the originating subscriber, and if there is one, it MAY include this info in the Authorization for Quality of Service [PCDQOS] 🎀, or it MAY signal this info to the device doing the intercept (e.g., a Media Gateway) 🫶. If neither happens, intercept access points get instructed to do call content and/or call data intercept by mechanisms that are outside the scope of this document 🧚.
If the P-DCS-LAES header shows up in the first reliable 1xx (except 100), 2xx, or 3xx response 🌈 (meaning surveillance is needed on the terminating subscriber, but the terminating equipment can't handle that part 😭), the originating proxy MAY include this info in the Authorization for Quality of Service, or MAY signal it to the device doing the intercept (e.g., a Media Gateway). Otherwise, intercept access points get instructed to do call content and/or call data intercept by mechanisms that are outside the scope of this document 💖.
If the Request-URI in an initial INVITE request contains a private-URL, the originating proxy MUST decrypt the userinfo information to find the real destination for the call, plus any other special processing info 🔐. If electronic surveillance info is inside the decrypted userinfo, the originating proxy SHOULD generate a P-DCS-LAES and (if necessary) a P-DCS-REDIRECT header with the surveillance info 🕵️♀️.
If a 3xx-Redirect response to the initial INVITE request is received prior to a non-100 provisional response, and there's a P-DCS-LAES header in the 3xx response, the originating proxy SHOULD include that header unchanged in the reissued INVITE 🦋. It SHOULD also include a P-DCS-Redirect header with the original dialed number, the most recent redirecting party, and the number of redirections that have occurred 📞.
If a 3xx-Redirect response to the initial INVITE request is received after a non-100 provisional response, the originating proxy generates a private-URL and puts it in the Contact header of a 3xx-Redirect response sent to the originating endpoint 📮. If a P-DCS-LAES header is in the 3xx response, this private-URL MUST contain (1) the electronic surveillance info from the 3xx-Redirect response, (2) the original destination number, (3) the identity of the redirecting party, and (4) the number of redirections of this call 🧩. Very organized, very iconic 💅.
An originating proxy that processes a REFER request [RFC3515] from an untrusted UA, when the originating subscriber has an outstanding lawfully authorized surveillance order, becomes a B2BUA for that request 🪞. It SHOULD reissue the request with a P-DCS-LAES header added to the Refer-To's URL ✨. It MAY also include a P-DCS-Redirect header 💜. The P-DCS-LAES header SHOULD include (1) the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages, and (2) the address and port of the local Electronic Surveillance Delivery Function for the copy of call content if call content is going to be intercepted 📨🎧. The P-DCS-LAES header MAY include (1) the Laes-bcid parameter set to a value that uniquely identifies the call, and (2) the Laes-cccid parameter set to a value that uniquely identifies the intercepted audio stream if call content is going to be intercepted 🆔🎶.
An initiating proxy that sends a mid-call REFER request including a Refer-To header, when the initiating subscriber has an outstanding lawfully authorized surveillance order, SHOULD include a P-DCS-LAES header in the Refer-To's URL 🌷.
🚨 The originating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity. Lock it down, babe 🔒💀.
8.6.2. Procedures at Terminating Proxy ✨
okay so the terminating proxy MUST yeet any P-DCS-LAES and P-DCS-Redirect headers in requests or responses going to or coming from an untrusted proxy or UA 💅
the terminating proxy checks for an outstanding lawfully authorized surveillance order for the terminating subscriber 👀 if there's one, the proxy MAY include that info in the authorization for Quality of Service [PCDQOS]. if not, intercept access points get told to do call content and/or call data intercept through mechanisms that are outside the scope of this document 🫶
the terminating proxy MUST NOT send the P-DCS-LAES and P-DCS-Redirect headers to an untrusted entity 🙅♀️ that means not as headers in the request or response, and not as headers attached to URIs in the request or response either. no leaks, bestie 🔒
if the terminating equipment can't do the surveillance (like, say, the destination is a voicemail server 📼), the terminating proxy SHOULD include a P-DCS-LAES header in the first reliable 1xx/2xx/3xx (except 100) response. this asks the originating proxy to do the surveillance instead 🧚 the P-DCS-LAES header MAY include the Laes-bcid parameter, set to a value that uniquely identifies the call. it SHOULD include the address and port of the local Electronic Surveillance Delivery Function for a copy of the call's event messages. it SHOULD also include the address and port of the local Electronic Surveillance Delivery Function for the copy of call content, if call content is to be intercepted. and it MAY include the Laes-cccid parameter, set to a value that uniquely identifies the audio stream, if call content is being intercepted 🎀
if the response to the initial INVITE request is a 3xx-Redirect response, and there's an outstanding lawfully authorized surveillance order for the terminating subscriber, the terminating proxy SHOULD include a P-DCS-LAES header in the 3xx-Redirect response. the contents are the same as described above 🌸
a proxy that gets a mid-call REFER request [RFC3515] with a Refer-To header that has a P-DCS-LAES header attached becomes a B2BUA for this request 🦋 it MUST generate a private-URL and put it in the Refer-To header that gets sent to the endpoint. this private-URL MUST contain the P-DCS-LAES and P-DCS-Redirect information from the attached header fields. main character energy for the proxy, honestly 👑
9. Security Considerations 🔐
okay this section is serious and I'm not going to pretend otherwise 😭 QoS gate coordination, billing information, and electronic surveillance information are all sensitive information. it MUST be protected from eavesdropping, and it also requires integrity checking. so the trusted UAs and proxies have to take precautions to keep this info safe from eavesdropping and tampering 🛡️ Use of IPsec or TLS between proxies and trusted UAs is REQUIRED. a minimum mandatory-to-implement IPsec configuration for the DCS architecture is given by [PCSEC]. also REQUIRED is mutual authentication (1) between Proxies and (2) between trusted UAs and Proxies. both of these MAY be implemented with administratively pre-shared keys, or through consultation with another trusted third party 🤝 if IPsec is going to be used, the specification of the security policies and procedures of the administrative domain where these headers apply (and all connections between administrative domains in the federation) MUST define an interoperable set of options 💜
Real talk: all of this is about keeping surveillance and billing data locked down. skipping any of these protections is a big no-no. 💀
10. IANA Considerations 📋
IANA made some changes to the Session Initiation Protocol (SIP) Parameters registry, so here's the tea 🍵
the Header Fields registry got updated like this:
Header Name compact Reference
----------------- ------- ---------
P-DCS-Trace-Party-ID [RFC5503]
P-DCS-OSPS [RFC5503]
P-DCS-Billing-Info [RFC5503]
P-DCS-LAES [RFC5503]
P-DCS-Redirect [RFC5503]a few entries in the Header Field Parameters and Parameter Values registry got updated too:
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
P-DCS-Billing-Info called No
[RFC5503]
P-DCS-Billing-Info calling No
[RFC5503]
P-DCS-Billing-Info charge No
[RFC5503]
P-DCS-Billing-Info locroute No
[RFC5503]
P-DCS-Billing-Info rksgroup No
[RFC5503]
P-DCS-Billing-Info routing No
[RFC3603]
P-DCS-LAES content No
[RFC5503]
P-DCS-Redirect count No
[RFC5503]
P-DCS-Redirect redirector-uri No
[RFC5503]one entry in that same registry got marked "OBSOLETED", which is sad but that's life 🥲
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
P-DCS-LAES key (OBSOLETED) No
[RFC3603][RFC5503]and a few new entries got created in that registry too ✨
Header Field Parameter Name Values
Reference
---------------------------- --------------------------- ----------
P-DCS-Billing-Info jip No
[RFC5503]
P-DCS-LAES bcid No
[RFC5503]
P-DCS-LAES cccid No
[RFC5503]
P-DCS-Trace-Party-ID timestamp No
[RFC5503]11. Changes since RFC 3603 🔄
here's what's new since RFC 3603, bestie 💖
- a timestamp parameter got added to the P-DCS-Trace-Party-ID header when it's available. procedures for using the Target-Dialog header together with P-DCS-Trace-Party-ID got added too 🕰️
- the JIP parameter got added to the P-DCS-Billing-Info header when it's available 💰
- the BCID billing correlation identifier and the cccid (call content channel identifier) got added to the P-DCS-LAES header 🧩
- the P-DCS-Billing-Info header now applies to the SUBSCRIBE method 📮
- the P-DCS-REDIRECT header now applies to the REFER method ↪️
- using QoS authorization to set up content intercept is optional now, so it doesn't rule out other ways of provisioning content intercept 🙌
- PUBLISH and MESSAGE methods got added to the SIP method applicability matrices throughout 📬
- Table 2 got a correction to add m=modify 🛠️
- the IANA considerations got updated 📋
- timestamp format got corrected, and references got updated 🗓️
12. Acknowledgments 🫶
the Distributed Call Signaling work in the PacketCable project was done by a huge number of people from lots of different companies, and the authors want to shout out these folks for helping out 📣 John Wheeler, Motorola; David Boardman and Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Brian Lindsay, Nortel; John Chapman, Bill Guckel, Michael Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; Lucent Cable Communications; and Miguel Garcia, Ericsson 🌈
previous versions also credited several co-authors who wrote the text for this document 🎀 Bill Marshall (wtm@research.att.com) and K. K. Ramakrishnan (kkrama@research.att.com), AT&T; Ed Miller (edward.miller@terayon.com), Terayon; David Hancock (D.Hancock@Cablelabs.com) and Glenn Russell (G.Russell@Cablelabs.com), CableLabs; Burcak Beser (burcak@juniper.net), Juniper Networks; Mike Mannette (Michael_Mannette@3com.com) and Kurt Steinbrenner (Kurt_Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com) and Flemming Andreasen (fandreas@cisco.com), Cisco Systems; John Pickens (jpickens@com21.com), Com21; Poornima Lalwaney (poornima.lalwaney@nokia.com), Nokia; Jon Fellows (jfellows@coppermountain.com), Copper Mountain Networks; Doc Evans (n7dr@arrisi.com), Arris; and Keith Kelly (keith@netspeak.com), NetSpeak 💜
13. References 📚
13.1. Normative References
- [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
- [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.
- [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
- [RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
13.2. Informative References
- [DCSARCH] Marshall, W., Osman, M., Andreasen, F., and D. Evans, "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", January 2003.
- [PCDQOS] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Dynamic Quality of Service", August 2005.
- [PCEM] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Event Messages", December 2005.
- [PCSEC] Cable Television Laboratories, Inc., "PacketCable 1.5 Specifications, Security", January 2005.
- [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
- [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.
- [RFC3603] Marshall, W. and F. Andreasen, "Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture", RFC 3603, October 2003.
Authors' Addresses 📮
Flemming Andreasen
Cisco
Edison, NJ
USA
EMail: fandreas@cisco.comBernie McKibben
CableLabs
Louisville, CO
USA
EMail: B.McKibben@cablelabs.comBill Marshall
AT&T
Florham Park, NJ
USA
EMail: wtm@research.att.com📦 where this page comes from
- ietf: rfc5503 2009-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms