RFC 4006
Diameter Credit-Control Application
RFC 4006: Diameter Credit-Control Application ✨
Part 1 of 27 🎀
- Series: Network Working Group, Request for Comments 4006 🌸
- Category: Standards Track 💖
- Date: August 2005 📅
- Authors: H. Hakala and L. Mattila (Ericsson), J-P. Koskinen, M. Stura, and J. Loughney (Nokia) 👩💻
- Obsoletes / Updates: The title block doesn't list anything this RFC obsoletes or updates. 🧚
Status of This Memo 🫶
Okay so this one is an Internet standards track protocol for the whole Internet community, and it's basically asking everyone to talk about it and send ideas for making it better 💬. If you want to know where this protocol actually stands, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📖. And the best part? Distribution of this memo is unlimited 🦋.
Copyright Notice 📜
Copyright (C) The Internet Society (2005). Mama Internet Society has the rights to this one 💅.
Abstract ✨
So this document defines a Diameter application that lets you do real-time credit-control for all kinds of end user services 🔥. We're talking network access, Session Initiation Protocol (SIP) services, messaging services, and download services. Literally everything you use online that needs to check your balance before it lets you through 💜.
Table of Contents 🌈
1. Introduction................................................. 4
1.1. Requirements Language................................. 5
1.2. Terminology........................................... 5
1.3. Advertising Application Support....................... 7
2. Architecture Models.......................................... 7
3. Credit-Control Messages...................................... 9
3.1. Credit-Control-Request (CCR) Command.................. 9
3.2. Credit-Control-Answer (CCA) Command................... 11
4. Credit-Control Application Overview.......................... 11
4.1. Service-Specific Rating Input and Interoperability.... 13
5. Session Based Credit-Control................................. 15
5.1. General Principles.................................... 15
5.2. First Interrogation................................... 21
5.3. Intermediate Interrogation............................ 27
5.4. Final Interrogation................................... 29
5.5. Server-Initiated Credit Re-Authorization.............. 30
5.6. Graceful Service Termination.......................... 32
5.7. Failure Procedures.................................... 38
6. One Time Event............................................... 41
6.1. Service Price Enquiry................................. 42
6.2. Balance Check......................................... 42
6.3. Direct Debiting....................................... 43
6.4. Refund................................................ 44
6.5. Failure Procedure..................................... 44
7. Credit-Control Application State Machine..................... 46
8. Credit-Control AVPs.......................................... 55
8.1. CC-Correlation-Id AVP................................. 58
8.2. CC-Request-Number AVP................................. 58
8.3. CC-Request-Type AVP................................... 58
8.4. CC-Session-Failover AVP............................... 59
8.5. CC-Sub-Session-Id AVP................................. 59
8.6. Check-Balance-Result AVP.............................. 60
8.7. Cost-Information AVP.................................. 60
8.8. Unit-Value AVP........................................ 61
8.9. Exponent AVP.......................................... 61
8.10. Value-Digits AVP...................................... 61
8.11. Currency-Code AVP..................................... 62
8.12. Cost-Unit AVP......................................... 62
8.13. Credit-Control AVP.................................... 62
8.14. Credit-Control-Failure-Handling AVP................... 62
8.15. Direct-Debiting-Failure-Handling AVP.................. 63
8.16. Multiple-Services-Credit-Control AVP.................. 64
8.17. Granted-Service-Unit AVP.............................. 65
8.18. Requested-Service-Unit AVP............................ 66
8.19. Used-Service-Unit AVP................................. 66
8.20. Tariff-Time-Change AVP................................ 67
8.21. CC-Time AVP........................................... 67
8.22. CC-Money AVP.......................................... 67
8.23. CC-Total-Octets AVP................................... 68
8.24. CC-Input-Octets AVP................................... 68
8.25. CC-Output-Octets AVP.................................. 68
8.26. CC-Service-Specific-Units AVP......................... 68
8.27. Tariff-Change-Usage AVP............................... 68
8.28. Service-Identifier AVP................................ 69
8.29. Rating-Group AVP...................................... 69
8.30. G-S-U-Pool-Reference AVP.............................. 69
8.31. G-S-U-Pool-Identifier AVP............................. 70
8.32. CC-Unit-Type AVP...................................... 70
8.33. Validity-Time AVP..................................... 70
8.34. Final-Unit-Indication AVP............................. 71
8.35. Final-Unit-Action AVP................................. 72
8.36. Restriction-Filter-Rule AVP........................... 72
8.37. Redirect-Server AVP................................... 73
8.38. Redirect-Address-Type AVP............................. 73
8.39. Redirect-Server-Address AVP........................... 74
8.40. Multiple-Services-Indicator AVP....................... 74
8.41. Requested-Action AVP.................................. 74
8.42. Service-Context-Id AVP................................ 75
8.43. Service-Parameter-Info AVP............................ 76
8.44. Service-Parameter-Type AVP............................ 76
8.45. Service-Parameter-Value AVP........................... 77
8.46. Subscription-Id AVP................................... 77
8.47. Subscription-Id-Type AVP.............................. 77
8.48. Subscription-Id-Data AVP.............................. 78
8.49. User-Equipment-Info AVP............................... 78
8.50. User-Equipment-Info-Type AVP.......................... 78
8.50. User-Equipment-Info-Value AVP......................... 79
9. Result Code AVP Values....................................... 79
9.1. Transient Failures.................................... 79
9.2. Permanent Failures.................................... 80
10. AVP Occurrence Table......................................... 80
10.1. Credit-Control AVP Table.............................. 81
10.2. Re-Auth-Request/Answer AVP Table...................... 82
11. RADIUS/Diameter Credit-Control Interworking Model............ 82
12. IANA Considerations.......................................... 85
12.1. Application Identifier................................ 86
12.2. Command Codes......................................... 86
12.3. AVP Codes............................................. 86
12.4. Result-Code AVP Values................................. 86
12.5. CC-Request-Type AVP................................... 86
12.6. CC-Session-Failover AVP............................... 86
12.7. CC-Unit-Type AVP...................................... 87
12.8. Check-Balance-Result AVP.............................. 87
12.9. Credit-Control AVP.................................... 87
12.10. Credit-Control-Failure-Handling AVP................... 87
12.11. Direct-Debiting-Failure-Handling AVP.................. 87
12.12. Final-Unit-Action AVP................................. 87
12.13. Multiple-Services-Indicator AVP....................... 87
12.14. Redirect-Address-Type AVP............................. 88
12.15. Requested-Action AVP.................................. 88
12.16. Subscription-Id-Type AVP.............................. 88
12.17. Tariff-Change-Usage AVP............................... 88
12.18. User-Equipment-Info-Type AVP.......................... 88
13. Credit-Control Application Related Parameters................ 88
14. Security Considerations...................................... 89
14.1. Direct Connection with Redirects...................... 90
15. References................................................... 91
15.1. Normative References.................................. 91
15.2. Informative References................................ 92
16. Acknowledgements............................................. 93
Appendix A Credit-Control Sequences.............................. 94
A.1. Flow I................................................ 94
A.2. Flow II............................................... 96
A.3. Flow III.............................................. 98
A.4. Flow IV............................................... 99
A.5. Flow V................................................ 100
A.6. Flow VI............................................... 102
A.7. Flow VII.............................................. 103
A.8. Flow VIII............................................. 105
A.9. Flow IX............................................... 107
Authors' Addresses............................................... 112
Full Copyright Statement......................................... 114Okay bestie, that's the whole map 🗺️💖 Part 2 picks up the story with Section 1, Introduction, so stay tuned 🧚✨
1. Introduction ✨
okay bestie, so this doc is literally the spec for a Diameter application that does real-time credit-control 💅 🎀 It's for all kinds of end-user services: network access, SIP services, messaging, download services, the whole squad. It gives a general solution to real-time cost and credit-control 🔥
The prepaid model is SO successful. Like, GSM network operators with prepaid plans saw their customer base and revenues grow a lot 📈 Prepaid stuff is now popping up on wireless and wireline networks everywhere 🌈
Next-gen wireless networks need more than what the Diameter base protocol gives you 🧚 The 3GPP Charging and Billing requirements [3GPPCHARG] say an application has to be able to rate service information in real-time. It's also necessary to check that the end user's account covers the requested service before the service starts 🙈 And if an account runs out or expires, the user must be denied the ability to compile more chargeable events. Harsh, but that's the point 💀
Users also need to be told what charges will be levied for a service they request 🍓 Plus, some services like gaming and advertising can credit and debit a user's account, so that's a whole vibe too ✨
Other Diameter applications handle service-specific authorization, but they don't do credit authorization for prepaid users 😭 So credit authorization shall be generic and applicable to all the service environments needed to support prepaid services. No exceptions, periodt 💅
To make all this work, credit-control communication has to happen between the network element providing the service (like a Network Access Server, a SIP Proxy, or an Application Server) and a credit-control server 🫶
Quick scope check: this spec is about credit authorization. Service-specific authorization and authentication is out of scope 🦋
1.1. Requirements Language
In this document, the key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [KEYWORDS]. Those capitalized words are the important ones, bestie 👑
1.2. Terminology
Let's go through the vocab, it's giving glossary energy 📚
AAA
Authentication, Authorization, and Accounting 🔐
AA answer
AA answer is the generic name for a service-specific authorization and authentication answer. AA answer commands are defined in service-specific authorization applications, like [NASREQ] and [DIAMMIP] 💜
AA request
AA request is the generic name for a service-specific authorization and authentication request. AA request commands are also defined in service-specific authorization applications, like [NASREQ] and [DIAMMIP] 🌸
Credit-control
Credit-control is a mechanism that talks to an account in real-time and controls or monitors the charges for service usage. It's a whole process: checking whether credit is available, reserving credit, deducting credit from the end user account when the service is done, and refunding any reserved credit that didn't get used. Iykyk 🧚
Diameter Credit-control Server
A Diameter credit-control server is the prepaid server. It does real-time rating and credit-control. It lives in the home domain, and service elements or Diameter AAA servers hit it in real-time to figure out the price and do credit-control before the service event is delivered to the end user. It may also talk to business support systems 🎀
Diameter Credit-control Client
A Diameter credit-control client is an entity that talks to a credit-control server. It keeps an eye on the usage of the granted quota based on what the credit-control server tells it to do 👀
Interrogation
The Diameter credit-control client uses interrogation to start a session-based credit-control process. During that process, it's used to report the used quota and ask for a new one. An interrogation maps to a request/answer transaction 🦋
One-time event
Basically, a request/answer transaction of type event ✨
Rating
The act of determining the cost of the service event 💰
Service
A type of task that a service element performs for an end user 🌈
Service Element
A network element that provides a service to end users. The Service Element may include the Diameter credit-control client, or another entity (like a RADIUS AAA server) that can act as a Credit-control client on behalf of the Service Element. In that latter case, the interface between the Service Element and the Diameter credit-control client is outside the scope of this specification. Examples of Service Elements include Network Access Server (NAS), SIP Proxy, and Application Servers such as messaging server, content server, and gaming server 🎮
Service Event
An event relating to a service provided to the end user 🫧
Session based credit-control
This is a credit-control process that uses several interrogations: the first, a possible intermediate, and the final one. The first interrogation reserves money from the user's account and starts the process. The intermediate interrogations may be needed to request new quota while the service is being rendered. The final interrogation is used to exit the process. The credit-control server is required to maintain session state for session-based credit-control. So the server has to remember the vibes the whole time 🧠
1.3. Advertising Application Support
Diameter nodes conforming to this specification MUST advertise support by including the value of 4 in the Auth-Application-Id of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [DIAMBASE]. Non-negotiable, bestie 💖
2. Architecture Models 🏗️
The current accounting models in Radius Accounting [RFC2866] and the Diameter base [DIAMBASE] aren't enough for real-time credit-control, where credit-worthiness has to be figured out before service initiation 🙅♀️ Also, the existing Diameter authorization applications, [NASREQ] and [DIAMMIP], only do service authorization and don't do credit authorization for prepaid users. So a new type of server is needed in the AAA infrastructure: the Diameter credit-control server 🔥 It's the entity responsible for credit authorization for prepaid subscribers, and it's giving main character energy 👑
A service element may authenticate and authorize the end user with the AAA server using AAA protocols, like RADIUS or the Diameter base protocol with a possible Diameter application 🔐
Accounting protocols like RADIUS accounting and the Diameter base accounting protocol can give accounting data to the accounting server after service is initiated. They can also send possible interim reports until service completion 📊 But for real-time credit-control, these authorization and accounting models just aren't sufficient 😭
When real-time credit-control is needed, the credit-control client contacts the credit-control server with info about a possible service event 📞 The credit-control process figures out potential charges and checks whether the end user's account balance can cover the cost of the service being rendered 💅
Figure 1 shows the typical credit-control architecture. It has a Service Element with an embedded Diameter credit-control client, a Diameter credit-control server, and an AAA server. A Business Support System is usually deployed, and it includes at least the billing functionality 🍓 The credit-control server and AAA server are logical entities in this model, so the real setup can squish them into a single host 🫶 The credit-control protocol is the Diameter base protocol with the Diameter credit-control application.
Service Element AAA and CC
+----------+ +---------+ Protocols+-----------+ +--------+
| End |<---->|+-------+|<------------>| AAA | |Business|
| User | +->|| CC || | Server |->|Support |
| | | || Client||<-----+ | | |System |
+----------+ | |+-------+| | +-----------+ | |
| +---------+ | ^ +--------+
+----------+ | | CC Protocol | ^
| End |<--+ | +-----v----+ |
| User | +------>|Credit- | |
+----------+ Credit-Control |Control |--------+
Protocol |Server |
+----------+
Figure 1: Typical credit-control architectureWhen an end user requests services like SIP or messaging, the request is usually forwarded to a service element (like a SIP Proxy) in the user's home domain 🏠 In some cases, a service element in the visited domain can offer services to the end user, but a commercial agreement must exist between the visited domain and the home domain. Network access is an example of a service offered in the visited domain, where the NAS, through an AAA infrastructure, authenticates and authorizes the user with the user's home network 🌐
There can be multiple credit-control servers in the system for redundancy and load balancing ⚖️ The system can also have separate rating server(s), and accounts can live in a centralized database 🗄️ To make sure the end user's account isn't debited or credited multiple times for the same service event, only one place in the credit-control system should do duplicate detection 🙈 System internal interfaces can exist to relay messages between servers and an account manager. But the detailed architecture of the credit-control system and its interfaces are implementation specific and out of scope for this specification 🤐
Protocol transparent Diameter relays can exist between the credit-control client and credit-control server. Diameter Redirect agents can also exist, which refer credit-control clients to credit-control servers and let them talk directly. These agents transparently support the Diameter credit-control application 🦋 The different roles of Diameter Agents are defined in Diameter base [DIAMBASE], section 2.8.
If Diameter credit-control proxies exist between the credit-control client and the credit-control server, they MUST advertise the Diameter credit-control application support 📣
3. Credit-Control Messages 💌
This section defines new Diameter message Command-Code values that MUST be supported by all Diameter implementations that conform to this specification. The Command Codes are as follows:
Command-Name Abbrev. Code Reference
-----------------------------------------------------------
Credit-Control-Request CCR 272 3.1
Credit-Control-Answer CCA 272 3.2Diameter Base [DIAMBASE] defines the Command Code ABNF specification in section 3.2. These formats are what you'll see in Credit-Control messages 🧚✨
3.1. Credit-Control-Request (CCR) Command ✨
okay so the CCR is the message that's indicated by the command-code field being set to 272 and the 'R' bit being set in the Command Flags field 💅 the Diameter credit-control client sends it to the credit-control server to ask for credit authorization for a given service 🎀
The Auth-Application-Id MUST be set to the value 4, which basically tells everyone this is the Diameter credit-control application 💖
Message Format
<Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Service-Context-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ User-Name ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
*[ Subscription-Id ]
[ Service-Identifier ]
[ Termination-Cause ]
[ Requested-Service-Unit ]
[ Requested-Action ]
*[ Used-Service-Unit ]
[ Multiple-Services-Indicator ]
*[ Multiple-Services-Credit-Control ]
*[ Service-Parameter-Info ]
[ CC-Correlation-Id ]
[ User-Equipment-Info ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]3.2. Credit-Control-Answer (CCA) Command 🦋
the CCA is indicated by the command-code field being set to 272 and the 'R' bit being cleared in the Command Flags field 🫶 it's the reply that goes from the credit-control server back to the Diameter credit-control client, acknowledging a Credit-Control-Request command, and it's giving very "I got you" energy ✨
Message Format
<Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Application-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ User-Name ]
[ CC-Session-Failover ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
[ Granted-Service-Unit ]
*[ Multiple-Services-Credit-Control ]
[ Cost-Information]
[ Final-Unit-Indication ]
[ Check-Balance-Result ]
[ Credit-Control-Failure-Handling ]
[ Direct-Debiting-Failure-Handling ]
[ Validity-Time]
*[ Redirect-Host]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ Failed-AVP ]
*[ AVP ]4. Credit-Control Application Overview 🌸
the credit authorization process happens before and during service delivery to the end user, and it usually needs the user's authentication and authorization before any request even gets sent to the credit-control server 🔐 this credit-control application supports two different credit authorization models: credit authorization with money reservation and credit authorization with direct debiting 💅 in both models, the credit-control client asks the credit-control server for credit authorization before it lets any service be delivered to the end user 🎀
in the first model, the credit-control server rates the request, reserves a suitable amount of money from the user's account, and sends back the matching amount of credit resources 💸 ngl the word "money" is a bit misleading here, because credit resources may not actually be monetary credit 🙈 they can be granted to the credit control client as units (like data volume or time) that get metered instead 📊
once the client gets a successful credit authorization answer with some credit resources, it lets service delivery happen and starts keeping an eye on how much of the granted resources gets used 👀 when those credit resources are used up, or the service has been successfully delivered or terminated, the client reports the used amount back to the server 🫶 the server then deducts that used amount from the end user's account, and it may do rating and make a new credit reservation if the service is still going 🔁 this whole thing is done with session based credit-control, which covers the first interrogation, possible intermediate interrogations, and the final interrogation ✨ for session based credit-control, both the credit control client and the credit-control server are REQUIRED to maintain credit-control session state, so they both have to keep track of the session together 🧚 session based credit-control gets explained in more detail, with more variations, in section 5 💜
in contrast, credit authorization with direct debiting is a single transaction process 💥 the credit-control server directly deducts a suitable amount of money from the user's account as soon as it gets the credit authorization request ✨ after a successful credit authorization answer comes back, the credit-control client lets service delivery happen for the end user 🦋 this process is done with the one-time event, and session state is not maintained 🙅
in a multi-service environment, an end user can send an additional service request (like a data service) during an ongoing service (like a voice call) toward the same account 📱 or, during an active multimedia session, an additional media type can get added to the session, which causes a new simultaneous request toward the same account 🎬 so this has to be considered when credit resources are granted to the services 🌈
the credit-control application also supports operations like service price enquiry, user's balance check, and refund of credit on the user's account 💰 these are done with the one-time event too, and session state is not maintained either 🌸
there's also a flexible credit-control application specific failure handling 🛡️ it lets the home service provider model the credit-control client behavior according to its own credit risk management policy 👑
the Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP are defined to decide what happens if sending credit-control messages to the credit-control server has been temporarily prevented 🚧 using them is flexible, because failure handling for the credit-control session and for one time event direct debiting may be different 🧁
4.1. Service-Specific Rating Input and Interoperability 🧚
the Diameter credit-control application gives you the framework for credit-control, so it's got generic mechanisms that support multiple service applications 🎀 because of that, the credit-control application doesn't define AVPs that could be used as input in the rating process 🙃 listing the possible services that could use this Diameter application is out of scope for this generic mechanism, so we're not doing that here 🙅♀️
it's pretty reasonable to expect that a service level agreement will exist between providers of the credit-control client and the credit-control server 📜 that agreement would cover the charging, the services offered, roaming agreements, the agreed rating input (i.e., AVPs), and so on 💅
so, it's assumed that a Diameter credit-control server will only provide service for Diameter credit-control clients that have agreed beforehand on the content of credit-control messages 🤝 is it possible for any arbitrary Diameter credit-control client to swap credit-control messages with any Diameter credit-control server? yes, obviously 🙄 but there's a much higher chance that unsupported services/AVPs could show up in the credit-control message, and then the server rejects the request with an appropriate result-code 💀
4.1.1. Specifying Rating Input AVPs 💜
there are two ways to give rating input to the credit-control server: either by using AVPs or by putting them inside the Service-Parameter-Info AVP 🎁 here are the general principles for sending rating parameters:
1a. The service SHOULD re-use existing AVPs if it can use AVPs defined in existing Diameter applications (e.g., NASREQ for network access services) 🔁 re-using existing AVPs is strongly recommended in [DIAMBASE] 🙌 for AVPs of type Enumerated, the service may need a new value to be defined, and new AVP values get allocated as specified in [DIAMBASE], section 1.2 📝
1b. New AVPs can be defined if the existing AVPs don't give enough rating information 🆕 in that case, the procedures defined in [DIAMBASE] for creating new AVPs MUST be followed 📋
1c. For services that are specific to just one vendor's implementation, a Vendor-Specific AVP code for Private use can be used 🔒 where a Vendor-Specific AVP is implemented by more than one vendor, allocating global AVPs is encouraged instead, so check out [DIAMBASE] 🌍
2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g., ASN.1 BER) 📦 this can be handy because it avoids unnecessary conversions from an existing data format to an AVP format 🧠 in this case, the rating input is embedded in the Service-Parameter-Info AVP as defined in section 8.43 🎀
last but not least, new service applications SHOULD favor the use of explicitly defined AVPs as described in items 1a and 1b, because that makes interoperability so much easier 💖✨
4.1.2. Service-Specific Documentation ✨
okay so the service-specific rating input AVPs, the stuff inside Service-Parameter-Info or Service-Context-Id (defined in section 8.42), are NOT in scope for this doc 🙈 to keep things interoperable, it is RECOMMENDED that the rating input and the Service-Context-Id values get coordinated through an informational RFC or some other permanent, easy-to-find reference. the spec from another cooperative standards body (like 3GPP, OMA, and 3GPP2) SHOULD be used. BUT private services are a thing too 💅 those can run under agreements between the credit-control server and client providers, and then vendor-specific AVPs can be used.
this spec, plus those service-specific docs, together govern the credit-control message 🫶 the service docs decide which existing or new AVPs count as rating input (the ones that don't define brand new credit-control applications), so a Diameter credit-control client that supports a given service has to include them in the Credit-Control-Request command as *[AVP]. if Service-Parameter-Info is used, the service-specific doc MUST spell out the exact content of that grouped AVP. no guessing allowed, bestie 😭
the Service-Context-Id AVP MUST show up at the command level of a Credit-Control Request, so everyone knows which service-specific doc applies. and the exact service or rating group is uniquely identified by the combo of Service-Context-Id plus Service-Identifier or Rating-Group 🎀
4.1.3. Handling of Unsupported/Incorrect Rating Input 🙅♀️
Diameter credit-control implementations are required to support the Mandatory rating AVPs in the service-specific docs for the services they support, following the 'M' bit rules in [DIAMBASE] 💖
if a rating input needed for rating is incorrect in the Credit-Control request, OR the credit-control server doesn't support the requested service context (the one named by the Service-Context-Id AVP at command level), the Credit-Control-Answer MUST carry the error code DIAMETER_RATING_FAILED 💀 a CCA with this error MUST include one or more Failed-AVP AVPs listing the missing and/or unsupported AVPs that caused the failure. and a Diameter credit-control client that gets DIAMETER_RATING_FAILED back in response to a request MUST NOT send similar requests in the future. not me sending the same broken request again 🙈✨
4.1.4. RADIUS Vendor-Specific Rating Attributes 🧚
when service-specific docs include RADIUS vendor-specific attributes that could be used as rating input, the rules in [NASREQ] for formatting the Diameter AVP MUST be followed 🌸
for example, if the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. the Diameter AVP data field holds only the attribute value of the RADIUS attribute. iconic formatting, no notes 👑
5. Session Based Credit-Control 🦋
5.1. General Principles 💜
okay so for session-based credit-control, there are several interrogations: the first one, an intermediate one (optional), and the final one 🌈 this is shown in Figures 2 and 3.
if the credit-control client does credit-reservation before granting service to the end user, it MUST use several interrogations toward the credit-control server (aka session-based credit-control) ✨ and in that case, the credit-control server MUST maintain the credit-control session state. main character energy 👑
every credit-control session MUST have a globally unique Session-Id as defined in [DIAMBASE], and it MUST NOT change during the lifetime of the session 🫶
some apps need multiple credit-control sub-sessions 🍓 those send messages with the same constant Session-Id, but a different CC-Sub-Session-Id AVP. if several sub-sessions are in use, all of them MUST be closed separately before the main session closes, so units per sub-session can be reported. no CC-Sub-Session-Id means no sub-sessions are in use 💅
heads up 🙈 the service element might send a service-specific re-authorization message to the AAA server when the authorization-lifetime expires during an ongoing credit-control session. BUT that re-authorization does NOT mess with the credit authorization going on between the credit-control client and server, because credit authorization is controlled by the burning rate of the granted quota 💖
if the service-specific re-authorization fails, the user gets disconnected, and the credit-control client MUST send a final interrogation to the credit-control server 😭
the Diameter credit-control server may want to control the validity time of the granted quota and/or how many intermediate interrogations happen ✨ so it MAY include the Validity-Time AVP in the answer to the credit-control client. when Validity-Time expires, the credit-control client MUST generate a credit-control update request and report the used quota to the server 🦋 it's up to the server to decide what Validity-Time value gets used for consuming the granted service units. if Validity-Time is used, its value SHOULD be given as input to set the session supervision timer Tcc (and the session supervision timer MAY be set to two times the Validity-Time value, as defined in section 13) 🌸 since update requests also get produced when granted service units run out and/or for mid-session service events, leaving out Validity-Time does NOT mean intermediate interrogation for credit-control isn't happening. iykyk 💀
5.1.1. Basic Tariff-Time Change Support 🎀
the Diameter credit-control server and client MAY optionally support a tariff change mechanism 🧚 the server may include a Tariff-Time-Change AVP in the answer message. note: the granted units should be allocated on a worst-case basis in case a tariff change is coming up, so the total reported used units never go over the credit reservation 🙈
when the client reports used units and a tariff change happened during the reporting period, the client MUST itemize the units used before and after the change separately 🫶 if the client can't tell whether units straddling the tariff change were used before or after it, it MUST itemize those units in a third category 🍓
if a client doesn't support the tariff change mechanism and gets a CCA carrying the Tariff-Time-Change AVP, it MUST terminate the credit-control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP 💀
for time-based services, the quota is continuously consumed at the regular rate of 60 seconds per minute ⏰ when credit resources get allocated, the server already knows how many units get consumed before the tariff time change and how many after it ✨ and if the end-user closes the session before the allotted quota is used up, the server can work out the units consumed at the before rate and the units at the after rate 💅 no extra traffic between client and server is needed for tariff time changes on continuous time-based services, so the tariff change mechanism isn't used for them 🌈 for time-based services where the quota is NOT continuously consumed at a regular rate, the tariff change mechanism described for volume and event units MAY be used 🦋
5.1.2. Credit-Control for Multiple Services within a (sub-)Session ✨
okay so, when a user is using a bunch of different services in the same session and each one has its own price, the credit-control has to happen for each service on its own 💅. If you lump everything into separate credit-control sub-sessions to get that, the signaling load and resource usage on both the client and the server go way up 😭. Picture this: during one network access session, the end user is hopping between several http-services that each cost something different. The access stuff like QoS is shared by everything riding on the same access bearer, but the bearer's cost can change depending on what's inside it 🎀.
So the credit-control application lets you do independent credit-control for multiple services inside one credit-control (sub-)session, and it's the optional Multiple-Services-Credit-Control AVP in Credit-Control-Request and Credit-Control-Answer messages that makes it happen 🦋. You can request and hand out resources as a credit pool that's shared across several services, and you can group services into rating groups for even more aggregation 🫶. You can also request and allocate quotas per service. When quotas go into a pool through the Multiple-Services-Credit-Control AVP, they still stay as their own objects, so each one can be re-authorized on its own whenever it needs to be 🌸. Quotas can also get their own result codes, validity times, and Final-Unit-Indications, which is so iconic 👑.
A Rating-Group is a bundle of services, each one identified by a Service-Identifier, that all cost the same and share a rating type (like $0.1/minute 💸). The spec assumes the service element already has the Rating-Groups, Service-Identifiers, and their parameters that say what to meter. Doing the metering itself is outside this spec, so don't worry about that part here 🙈. Examples of those parameters are the IP 5-tuple and the HTTP URL. Service-Identifiers are what let you authorize credit per service and also give you itemized usage reports, which is super useful ✨. It's up to the credit-control server whether it authorizes credit for one service, several services, or the whole rating-group 🧚. The client SHOULD still always report used units at the finest level of granularity it supports, though 💅. When quota goes to a rating-group, every service in that group draws from that same allotted quota 🍓. Here's a little picture of how service-identifiers, rating-groups, credit pools, and the credit-control (sub-)session all fit together:
DCC (Sub-)Session
|
+------------+-----------+-------------+--------------- +
| | | | |
Service-Id a Service-Id b Service-Id c Service-Id d.....Service-Id z
\ / \ / /
\ / \ / /
\ / Rating-Group 1.......Rating-Group n
\ / | |
Quota ---------------Quota Quota
| / |
| / |
Credit-Pool Credit-PoolIf you're doing independent credit-control for multiple services, the validity-time and final-unit-indication SHOULD be there, either inside the Multiple-Services-Credit-Control AVP(s) or as single AVPs at the command level 🌈. The Result-Code AVP MAY show up at the command level and also inside the Multiple-Services-Credit-Control AVP 🎀. But if the command-level Result-Code says something other than SUCCESS, that command-level one wins over anything inside the Multiple-Services-Credit-Control AVP 👑.
The credit-control client MUST say it supports independent credit-control of multiple services within a (sub-)session by putting the Multiple-Services-Indicator AVP in the very first interrogation 🫶. A credit-control server that doesn't support this feature MUST treat the Multiple-Services-Indicator AVP and any Multiple-Services-Credit-Control AVPs it gets as invalid AVPs 😬. If the client told the server it supports this, then a server that wants to use the feature MUST send the granted units inside the Multiple-Services-Credit-Control AVP tied to the matching service-identifier and/or rating-group 🦋.
Now, nobody wants a bunch of parallel, usually tiny, credit reservations all hitting the same account. That's called credit fragmentation, and it also piles unnecessary load onto the server 🙃. So the fix is to hand out service units as a pool that works across several services or rating groups 💖. You do that by giving the units as a quota for one particular service or rating group in the Multiple-Services-Credit-Control AVP, and you also include a reference to a credit pool for that unit type ✨.
That reference includes a multiplier, which is derived from the rating parameter. It converts service units of one specific type into the abstract service units in the pool 🧮. For example, if service 1 is rated at $1/MB and service 2 is rated at $0.5/MB, the multipliers could be 10 and 5 for services 1 and 2 🍓.
Let S be the total service units in the pool, let M1, M2, ..., Mn be the multipliers for services 1, 2, ..., n, and let C1, C2, ..., Cn be the resources used in the session. Then the pool credit is used up, and re-authorization MUST be sought, when:
C1*M1 + C2*M2 + ... + Cn*Mn >= SThe total credit in the pool, S, is worked out from the quotas that are currently allocated to the pool:
S = Q1*M1 + Q2*M2 + ... + Qn*MnIf services or rating groups get added to or taken out of the pool, the total credit gets adjusted to match 🔥. When services or rating groups are removed, the amount you take out is the consumed one, which is Cx*Mx 🫠.
You can ask for re-authorizations for an individual service or rating group at any time, for example when a 'non-pooled' quota runs out or when the Validity-Time expires ⏰.
When there are multiple G-S-U-Pool-Reference AVPs (section 8.30) with the same G-S-U-Pool-Identifier inside one Multiple-Services-Credit-Control AVP (section 8.16) along with the Granted-Service-Unit AVP, they MUST have different CC-Unit-Type values, and each one draws from the credit pool separately 🎀. Say you have one multiplier for time (M1t) and one for volume (M1v). Then the resources used from the pool come to C1t*M1t + C1v*M1v, where C1t is the time unit and C1v is the volume unit 🧚.
If service units come inside a Multiple-Services-Credit-Control AVP without a matching G-S-U-Pool-Reference AVP, they're handled on their own, separate from any credit pool and from every other service or rating group in the session 🦋.
The credit pool idea is the best tool for avoiding the over-reservation problem of the basic single-quota tariff time change mechanism, which is the one described in section 5.1.1 💅. So Diameter credit-control clients and servers that do independent credit-control of multiple services SHOULD use the credit pool concept when they handle a tariff time change 🌸. The Diameter credit-control server SHOULD put both the Tariff-Time-Change and Tariff-Change-Usage AVPs into two quota allocations in the answer message, meaning two instances of the Multiple-Services-Credit-Control AVP 💖. One of the granted units is for use before the potential tariff change, and the second set is for use after a tariff change ✨. Both granted unit quotas MUST carry the same Service-Identifier and/or Rating-Group 🫶. This dual-quota setup makes sure the total reported used units never go over the credit reservation 🔒. The Diameter credit-control client reports the used units from before and after the tariff change together, in one instance of the Multiple-Services-Credit-Control AVP 🌈.
Failure handling for credit-control sessions is defined in section 5.7, and it's reflected in the basic credit-control state machine in section 7 🛠️. Clients and servers that do independent credit-control of multiple services in a (sub-)session MUST make sure their failure handling and general behavior are fully consistent with those sections, while still being able to handle parallel ongoing credit re-authorization within a (sub-)session 🧠. That's why it's RECOMMENDED that Diameter credit-control clients keep a PendingU message queue and restart the Tx timer (section 13) every single time they send a CCR message with the value UPDATE_REQUEST while they're in the PendingU state 💜. Once answers to all the pending messages have come back, the state machine moves to the OPEN state and Tx gets stopped 🏁. Whatever action gets taken when the session runs into a problem under section 5.7 hits all the ongoing services too. For example, if failing over to a backup server is possible, that failover affects every CCR message with the value UPDATE_REQUEST in the PendingU queue 🚨.
Here's the tricky bit: the client may send CCR messages with the value UPDATE_REQUEST while it's still in PendingU, meaning it doesn't wait for an answer to the ongoing credit re-authorization 🏃♀️. Because of that, the gap between those requests can be really short, and the server may not have received the earlier request or requests yet 😵💫. So in this situation the server may get requests out of sequence, and it SHOULD NOT treat that as an error condition 🙏. The proper move is to return an answer to each of those requests 💅✨.
5.2. First Interrogation 🦋
okay bestie, this is the moment the credit-control dance actually starts 💅 When session based credit-control is required (like when the auth server says "hey, this one's a prepaid user" 👀), the first interrogation MUST be sent before the Diameter credit-control client lets any service event reach the end user. 🔥 The CC-Request-Type gets set to INITIAL_REQUEST in the request. Main character energy, literally the opening scene ✨
Now, if the client already knows what the service event costs (ex: a content server selling ringtones 🎵 knows the price), then the monetary amount goes in the Requested-Service-Unit AVP. But if the client has no clue what it costs, the Requested-Service-Unit AVP MAY contain the number of requested service events instead 🌸 When the Multiple-Services-Credit-Control AVP is in play, it MUST contain the Requested-Service-Unit AVP, because that's how you say "yes, I want quota for this service/rating-group" 🎀 And when there are multiple services going on, the Service-Identifier AVP or the Rating-Group AVP inside the Multiple-Services-Credit-Control AVP is always the one telling you which service we're talking about 🧚
Extra info about the service event that needs rating MAY be sent as service specific AVPs, or it MAY be sent inside the Service-Parameter-Info AVP at command level 🦋 And the Service-Context-Id AVP tells you which service specific document applies to the request. Iconic organization, no notes 📝
Two more vibes: the Event-Timestamp AVP SHOULD be included in the request, and it holds the time the service event was requested in the service element ⏰ The Subscription-Id AVP SHOULD be included too, so the credit-control server knows whose account this is 💖 The credit-control client MAY include the User-Equipment-Info AVP, so the server gets a little hint about what kind of device the end user is using and what it can do 📱 What the server does with that info? Not this document's problem, that's outside the scope 🙈
The credit-control server SHOULD rate the service event and make a credit-reservation from the end user's account that covers the cost 💰 If the Requested-Service-Unit AVP is type money, then no rating is needed, but that monetary amount still gets reserved from the account. Simple, clean, iconic 💅
The credit-control server sends back the Granted-Service-Unit AVP in the Answer message. This tells the client how many service units it can hand out to the end user until a new Credit-Control-Request MUST be sent to the credit-control server 🌈 If the Answer carries several unit types, the credit-control client MUST handle each unit type separately, no mixing 🫶 The Granted-Service-Unit type can be time, volume, service specific, or money, depending on the service event ⭐ Once a session is going, the unit type(s) SHOULD NOT be changed. Don't be that friend who switches up the plan mid-hangout 😭
There MUST be a maximum of one instance of the same unit type in one Answer message. BUT (and this is a big but 🫣), if multiple quotas get conveyed to the client in the Multiple-Services-Credit-Control AVPs, it's possible to have two instances of the same unit type tied to one service-identifier/rating-group. This usually happens when a tariff time change is coming up and the server wants to tell apart the quota before and after the change ⏳✨
If the credit-control server decides no further control is needed for the service, it MAY include a result code saying credit-control is not applicable (ex: the service is free of charge 🍓). That result code at command level means the credit-control session is getting terminated 👋
The Credit-Control-Answer message MAY also include the Final-Unit-Indication AVP, which says "these are the final units for the service" 🥹 After the end user uses up those units, the Diameter credit-control-client MUST behave as described in section 5.6. Plot twist, but it's coming 🎭
This document gives you two different ways to do the first interrogation, depending on the network architecture 🦋 Approach one: send credit-control messages after the user's authorization and authentication happen. Approach two: use service specific authorization messages for the first interrogation during authorization/authentication, then use credit-control messages for the intermediate and final interrogations. If a credit-control client supports both, it SHOULD be configurable which one it uses 🔧
In service environments like the Network Access Server (NAS), doing the first interrogation as part of authorization/authentication is the move, because it's way more protocol efficient ⚡ Any further credit authorizations after that get handled with the credit-control commands defined here. Credit-control clients in these environments SHOULD support this method 💜 If the credit-control server and AAA server are separate physical boxes, the service element sends the request to the AAA server, which then either makes its own request or passes the request along to the credit-control server 📦
In other service environments, like the 3GPP network and some SIP scenarios, registration/access to the network is pretty decoupled from the actual service request 🌸 Authentication/authorization happens once at registration or access and doesn't run again for every service event the subscriber asks for. So in these places, it makes more sense to do the first interrogation after the user has been authenticated and authorized. The first, intermediate, and final interrogations all use the credit-control commands defined here 🧁
Other IETF standards, or standards from other standardization bodies, might define the most suitable method for their own architectures 🌍
5.2.1. First Interrogation after Authorization and Authentication ✨
So the Diameter credit-control client in the service element might ask the authorization server whether credit-control is required, based on what it knows about the end user 👀 If it is, the credit-control server has to be contacted before service delivery starts. The accounting protocol and the credit-control protocol can run in parallel, and the authorization server may also decide whether the parallel accounting stream is needed 🫶
Here's the vibe check with both protocols running in parallel, where the service element talks to the credit-control server directly (more credit-control sequence examples are in Annex A, bestie 📚):
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Registration | AA request/answer(accounting,cc or both)|
|<----------------->|<------------------>| |
| : | | |
| : | | |
| Service Request | | |
|------------------>| | |
| | CCR(Initial,Credit-Control AVPs) |
| +|---------------------------------------->|
| CC stream|| | CCA(Granted-Units)|
| +|<----------------------------------------|
| Service Delivery | | |
|<----------------->| ACR(start,Accounting AVPs) |
| : |------------------->|+ |
| : | ACA || Accounting stream |
| |<-------------------|+ |
| : | | |
| : | | |
| | CCR(Update,Used-Units) |
| |---------------------------------------->|
| | | CCA(Granted-Units)|
| |<----------------------------------------|
| : | | |
| : | | |
| End of Service | | |
|------------------>| CCR(Termination, Used-Units) |
| |---------------------------------------->|
| | | CCA |
| |<----------------------------------------|
| | ACR(stop) | |
| |------------------->| |
| | ACA | |
| |<-------------------| |
Figure 2: Protocol example with first interrogation after user's
authorization/authentication5.2.2. Authorization Messages for First Interrogation ✨
Okay bestie, so the Diameter credit-control client in the service element MUST actively co-operate with the authorization/authentication client when it builds the AA request 🫶. It does that by adding the right credit-control AVPs. The credit-control client MUST add the Credit-Control AVP to show off its credit-control capabilities, and it MAY add other relevant credit-control specific AVPs to the proper authorization/authentication command 💅. That command is how it does the first interrogation toward the home Diameter AAA server 🦋. The Auth-Application-Id gets set to the right value from the relevant service specific authorization/authentication application document (like [NASREQ] or [DIAMMIP]) 🎀. The home Diameter AAA server authenticates and authorizes the subscriber, and then figures out whether credit-control is needed for them 👑.
If credit-control is NOT needed for the subscriber, the home Diameter AAA server just responds as usual with an appropriate AA answer message 🌸. But if credit-control IS required and the Credit-Control AVP with the value CREDIT_AUTHORIZATION was in the authorization request, the home AAA server MUST contact the credit-control server to do the first interrogation 🔥. And if credit-control is required but the Credit-Control AVP wasn't in the authorization request at all, the home AAA server MUST send an authorization reject answer message 💀.
The Diameter AAA server that supports credit-control has to send the Credit-Control-Request command (CCR) defined in this document to the credit-control server 🧚. It fills in the CCR using the service specific AVPs that feed into the rating process, and maybe some credit-control AVPs it got in the AA request too 🍓. The credit-control server reserves money from the user's account, rates the request, and sends a Credit-Control-Answer message back to the home Diameter AAA server 💜. That answer includes the Granted-Service-Unit AVP(s) and MAY include other credit-control specific AVPs, as appropriate ✨. The credit-control server also MAY set the Validity-Time, and it MAY include the Credit-Control-Failure-Handling AVP and the Direct-Debiting-Failure-Handling AVP. Those tell everyone what to do if sending credit-control messages to the credit-control server has been temporarily blocked 🌈.
When the home Diameter AAA server gets the Credit-Control-Answer from the credit-control server, it fills the AA answer with the credit-control AVPs it received and with the right service attributes for the authorization/authentication specific application (like [NASREQ] or [DIAMMIP]) 💖. Then it forwards the packet to the credit-control client 🦋. If the home Diameter AAA server gets a credit-control reject message, it just generates an appropriate authorization reject message for the credit-control client, and it includes the credit-control specific error code 😭.
In this model, the credit-control client sends its further credit-control messages to the credit-control server through the home Diameter AAA server 🫶. When it gets a successful authorization answer with the Granted-Service-Unit AVP(s), the credit-control client grants the service to the end user and generates an intermediate credit-control request using the credit-control commands 🎀. The CC-Request-Number of the first UPDATE_REQUEST MUST be set to 1. (For how to produce a unique value for the CC-Request-Number AVP, see section 8.2 💅.)
If service specific re-authorization happens (that is, the authorization-lifetime expires), the credit-control client MUST add the Credit-Control AVP with the value RE_AUTHORIZATION to the service specific re-authorization request 🙈. That tells the credit-control server it MUST NOT be contacted. When session based credit-control is used for the subscriber, there's a constant stream of credit-control messages flowing through the home Diameter AAA server 🌊. The home Diameter AAA server can use that message flow to figure out the user's activity is still going on, so it is recommended to set the authorization-lifetime to a reasonably high value when credit-control is used for the subscriber ⭐.
In this scenario, the home Diameter AAA server MUST advertise support for the credit-control application to its peers during the capability exchange process 👑.
The figure below shows how the authorization/authentication messages get used to do the first interrogation. The parallel accounting stream isn't shown, so don't panic if you don't see it 🙈.
Service Element Diameter
End User (CC Client) AAA Server CC Server
| Service Request | AA Request (CC AVPs) |
|------------------>|------------------->| |
| | | CCR(Initial, CC AVPs)
| | |------------------->|
| | | CCA(Granted-Units)
| | |<-------------------|
| | AA Answer(Granted-Units) |
| Service Delivery |<-------------------| |
|<----------------->| | |
| : | | |
| : | | |
| : | | |
| | | |
| | CCR(Update,Used-Units) |
| |------------------->| CCR(Update,Used-Units)
| | |------------------->|
| | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<-------------------|
| |<-------------------| |
| : | | |
| : | | |
| End of Service | | |
|------------------>| CCR(Termination,Used-Units) |
| |------------------->| CCR(Term.,Used-Units)
| | |------------------->|
| | | CCA |
| | CCA |<-------------------|
| |<-------------------| |
Figure 3: Protocol example with use of the
authorization messages for the first interrogation5.3. Intermediate Interrogation 🦋
Alright, here's the big one. When all the granted service units for one unit type are spent by the end user, or the Validity-Time has expired, the Diameter credit-control client MUST send a new Credit-Control-Request to the credit-control server 🔥. If credit-control for multiple services is applied in one credit-control session (meaning units tied to Service-Identifier(s) or Rating-Group are granted), a new Credit-Control-Request MUST be sent to the credit-control server when the credit reservation has been wholly consumed, or when the Validity-Time expires 💅. It's always up to the Diameter credit-control client to send a new request well in advance of the previous one expiring, so the service element doesn't get interrupted 🫶. Even if the granted service units reserved by the credit-control server haven't been spent when the Validity-Time expires, the Diameter credit-control client MUST still send a new Credit-Control-Request to the credit-control server 🌸.
There can also be mid-session service events that affect the rating of the current service events 🌈. When that happens, a spontaneous update (a new Credit-Control-Request) SHOULD be sent with information about the service event, even if all the granted service units haven't been spent or the Validity-Time hasn't expired ✨.
When the used units get reported to the credit-control server, the credit-control client won't have any units in its possession until new granted units come back from the credit-control server 😭. Once those new granted units arrive, they apply from the point where the measurement of the reported used units stopped 💜. Where independent credit-control of multiple services is supported, this process may be run for one or more services, a single rating-group, or a pool within the (sub)session 🧚.
The CC-Request-Type AVP is set to the value UPDATE_REQUEST in the intermediate request message 🎀. The Subscription-Id AVP SHOULD be included in the intermediate message to identify the end user at the credit-control server 🍓. The Service-Context-Id AVP shows which service specific document applies to the request 💖.
The Requested-Service-Unit AVP MAY contain the new amount of requested service units 🌟. Where the Multiple-Services-Credit-Control AVP is used, it MUST contain the Requested-Service-Unit AVP if a new quota is requested for the associated service/rating-group 👑. The Used-Service-Unit AVP contains the amount of used service units, measured from the point when the service became active or, if interim interrogations are used during the session, from the point when the previous measurement ended ⭐. The same unit types used in the previous message SHOULD be used. And if several unit types were included in the previous answer message, the used service units for each unit type MUST be reported 🙈.
The Event-Timestamp AVP SHOULD be included in the request, and it contains the time of the event that triggered the sending of the new Credit-Control-Request ⏰.
The credit-control server MUST deduct the used amount from the end user's account 💀. It MAY rate the new request and make a new credit reservation from the end user's account that covers the cost of the requested service event 🦋.
A Credit-Control-Answer message with the CC-Request-Type AVP set to the value UPDATE_REQUEST MAY include the Cost-Information AVP, which holds the accumulated cost estimation for the session, without taking any credit reservation into account 💰.
The Credit-Control-Answer message MAY also include the Final-Unit-Indication AVP to show that the answer message contains the final units for the service 🏁. After the end user has used up these units, the Diameter credit-control-client MUST behave as described in section 5.6 😤.
There can be several intermediate interrogations within a session 💅✨.
5.4. Final Interrogation 🧚
okay bestie, so when the end user ends the service session, or when the graceful service termination from section 5.6 happens, the Diameter credit-control client MUST send a final Credit-Control-Request message to the credit-control server 💌. The CC-Request-Type AVP gets set to TERMINATION_REQUEST, and the Service-Context-Id AVP tells you which service specific document applies to the request 🎀.
The Event-Timestamp AVP SHOULD be included in the request, and it holds the time when the session was terminated ⏰.
The Used-Service-Unit AVP has the amount of used service units, measured from the point when the service became active. If interim interrogations were used during the session, it's measured from the point when the previous measurement ended instead 📏. If several unit types were in the previous answer message, then the used service units for each unit type MUST be reported 💅.
After final interrogation, the credit-control server MUST refund the reserved credit amount that wasn't used to the end user's account, and deduct the used monetary amount from the end user's account 💸.
A Credit-Control-Answer message with CC-Request-Type set to TERMINATION_REQUEST MAY include the Cost-Information AVP, which holds the estimated total cost for the session in question 🧾.
If the user logs off during an ongoing credit-control session, or some other reason logs them off (e.g., final-unit indication causes user logoff according to local policy), the service element may, according to application specific policy, send a Session-Termination-Request (STR) to the home Diameter AAA server as usual [DIAMBASE]. Figure 4 shows the case where the final-unit indication causes logoff once the final granted units are consumed and the STR gets generated 🌊.
Service Element AAA Server CC Server
End User (CC Client)
| Service Delivery | | |
|<----------------->| | |
| : | | |
| : | | |
| : | | |
| | | |
| | CCR(Update,Used-Units) |
| |------------------->| CCR(Update,Used-Units)
| | |------------------->|
| | CCA(Final-Unit, Terminate)
| CCA(Final-Unit, Terminate)|<-------------------|
| |<-------------------| |
| : | | |
| : | | |
| Disconnect user | | |
|<------------------| CCR(Termination,Used-Units) |
| |------------------->| CCR(Term.,Used-Units)
| | |------------------->|
| | | CCA |
| | CCA |<-------------------|
| |<-------------------| |
| | STR | |
| |------------------->| |
| | STA | |
| |<-------------------| |Figure 4: User disconnected due to exhausted account
5.5. Server-Initiated Credit Re-Authorization 🦋
the Diameter credit-control application supports server-initiated re-authorization, and it's honestly so iconic 👑. The credit-control server MAY optionally initiate the credit re-authorization by issuing a Re-Auth-Request (RAR) as defined in the Diameter base protocol [DIAMBASE]. The Auth-Application-Id in the RAR message is set to 4 to indicate Diameter Credit Control, and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY 🌸.
Section 5.1.2 defines the feature that enables credit-control for multiple services within a single (sub-)session, where the server can authorize credit usage at a different level of granularity 🍓. The server may also give credit resources to multiple services or rating groups as a pool (see section 5.1.2 for details and definitions). So based on its service logic and what it knows about the ongoing session, the server can decide to request credit re-authorization for a whole (sub-)session, a single credit pool, a single service, or a single rating-group 🧠.
To request credit re-authorization for a credit pool, the server includes the G-S-U-Pool-Identifier AVP in the RAR message to indicate the affected pool. To request it for a service or a rating-group, the server includes the Service-Identifier AVP or the Rating-Group AVP in the RAR message, respectively. To request it for all the ongoing services within the (sub-)session, the server includes none of the above mentioned AVPs in the RAR message 🫶.
If a credit re-authorization is not already ongoing (i.e., the credit-control session is in Open state), a credit control client that receives an RAR message with a Session-Id equal to a currently active credit-control session MUST acknowledge the request by sending the Re-Auth-Answer (RAA) message. It MUST also initiate the credit re-authorization toward the server by sending a Credit-Control-Request message with the CC-Request-Type AVP set to UPDATE_REQUEST. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to say that an additional message (i.e., a CCR message with UPDATE_REQUEST) is required to complete the procedure ✨. If a quota was allocated to the service, the credit-control client MUST report the used quota in the Credit-Control-Request 📊. Note that the end user doesn't need to be prompted for the credit re-authorization, because it's totally transparent to them (it happens only between the credit-control client and the credit-control server) 🙈.
Where multiple services in a user's session are supported, the procedure in the paragraph above runs at the granularity the server asked for in the RAR message 💜.
If credit re-authorization is already ongoing when the RAR message arrives (i.e., a RAR-CCR collision), the credit-control client successfully acknowledges the request but does not start a new credit re-authorization 🙅♀️. The Result-Code 2001 (DIAMETER_SUCCESS) SHOULD be used in the RAA message to show that a credit re-authorization procedure is already ongoing (i.e., the client was in PendingU state when the RAR was received). The credit-control server SHOULD process the Credit-Control-Request as if it was received in answer to the server initiated credit re-authorization, and should consider the server initiated credit re-authorization process successful once it receives the Re-Auth-Answer message 🤝.
When multiple services are supported in a user's session, the server may request credit re-authorization for a credit pool (or for the (sub-)session) while a credit re-authorization is already ongoing for some of the services or rating-groups 🌀. In that case, the client acknowledges the server's request with an RAA message and MUST send a new Credit-Control-Request message to re-authorize the remaining services/rating-groups. The Result-Code 2002 (DIAMETER_LIMITED_SUCCESS) SHOULD be used in the RAA message to say that an additional message (i.e., a CCR message with the value UPDATE_REQUEST) is required to complete the procedure. The server then processes the received requests and returns an appropriate answer to both requests 🎉.
The procedures above are enabled for each of the possibly active Diameter credit-control sub-sessions. The server MAY request re-authorization for an active sub-session by including the CC-Sub-Session-Id AVP in the RAR message, in addition to the Session-Id AVP 🫧.
5.6. Graceful Service Termination 🦋
Okay so, when the user's account runs out of money 💀, they usually aren't allowed to keep racking up chargeable events. BUT the home service provider might still offer some services, like a service portal where the user can refill the account, and the user gets to enjoy that for a limited time ⏳. How long that is usually depends on the home service provider's policy 💅.
This section defines the optional graceful service termination feature that MAY be supported by the credit-control server. Credit-control client implementations MUST support the Final-Unit-Indication with at least the teardown of the ongoing service session once the subscriber has consumed all the final granted units 🔥.
Where independent credit-control of multiple services in a single credit-control (sub-)session is supported, it's possible to use graceful service termination for each of the services/rating-groups independently 🌈. Naturally, the graceful service termination process defined in the following sub-sections applies to the specific service/rating-group that the server requests ✨.
In some service environments (e.g., NAS), graceful service termination may be used to redirect the subscriber to a service portal for online balance refill or other services offered by the home service provider 🎀. In this case, the graceful termination process installs a set of packet filters that restrict the user's access capability only to/from the specified destinations. All the IP packets not matching the filters will be dropped or, possibly, re-directed to the service portal 🙈. The user may also be sent an appropriate notification explaining why access has been limited. These actions may be communicated explicitly from the server to the client or may be configured per-service at the client. Explicitly signaled redirect or restrict instructions always take precedence over configured ones 👑.
It's also possible to use graceful service termination to connect the prepaid user to a top-up server that plays an announcement and prompts the user to replenish the account 🧚. In this case, the credit-control server sends only the address of the top-up server where the prepaid user shall be connected after the final granted units have been consumed. An example of this is given in Appendix A (Flow VII) 💜.
The credit-control server MAY initiate graceful service termination by including the Final-Unit-Indication AVP in the Credit-Control-Answer, to indicate that the message contains the final units for the service 🍓.
When the credit-control client receives the Final-Unit-Indication AVP in the answer from the server, its behavior depends on the value indicated in the Final-Unit-Action AVP. The server may request the following actions: TERMINATE, REDIRECT, or RESTRICT_ACCESS 😭.
Here's a figure showing the graceful service termination procedure described in the following sub-sections 📊:
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Service Delivery | | |
|<----------------->| | |
| |CCR(Update,Used-Units) |
| |------------------->|CCR(Update,Used-Units)
| : | |------------------->|
| : | |CCA(Final-Unit,Action)
| : | |<-------------------|
| |CCA(Final-Unit,Action) |
| |<-------------------| |
| | | |
| : | | |
| : | | |
| : | | |
| /////////////// |CCR(Update,Used-Units) |
|/Final Units End/->|------------------->|CCR(Update,Used-Units)
|/Action and // | |------------------->|
|/Restrictions // | | CCA(Validity-Time)|
|/Start // | CCA(Validity-Time)|<-------------------|
| ///////////// |<-------------------| |
| : | | |
| : | | |
| Replenish Account +-------+ |
|<-------------------------------------------->|Account| |
| | | +-------+ |
| | | RAR |
| + | RAR |<===================|
| | |<===================| |
| | | RAA | |
| ///////////// | |===================>| RAA |
| /If supported / | | CCR(Update) |===================>|
| /by CC Server/ | |===================>| CCR(Update) |
| ///////////// | | |===================>|
| | | | CCA(Granted-Unit)|
| | | CCA(Granted-Unit)|<===================|
| Restrictions ->+ |<===================| |
| removed | | |
| : | | |
| OR | CCR(Update) | |
| Validity-Time ->|------------------->| CCR(Update) |
| expires | |------------------->|
| | | CCA(Granted-Unit)|
| | CCA(Granted-Unit)|<-------------------|
| Restrictions ->|<-------------------| |
| removed | | |Figure 5: Optional graceful service termination procedure 🎨
5.6.1. Terminate Action 💖
The Final-Unit-Indication AVP with Final-Unit-Action TERMINATE doesn't include any other information, so it's super simple 🫶. When the subscriber has consumed the final granted units, the service element MUST terminate the service 🛑. This is the default handling whenever the credit-control client receives an unsupported Final-Unit-Action value, and it MUST be supported by all the Diameter credit-control client implementations conforming to this specification 💅. A final Credit-Control-Request message MUST be sent to the credit-control server if the Final-Unit-Indication AVP indicating action TERMINATE was present at command level. The CC-Request-Type AVP in that request is set to the value TERMINATION_REQUEST ✨.
5.6.2. Redirect Action 🦋
Okay so the Final-Unit-Indication AVP with Final-Unit-Action set to REDIRECT tells the service element doing this action 💅 that, once the final granted units are all used up, the user MUST be re-directed to the address in the Redirect-Server AVP. Here's how it goes.
The credit-control server sends the Redirect-Server AVP in the Credit-Control-Answer message. When that happens, the service element MUST redirect or connect the user to the destination in Redirect-Server, if possible. If the end user gets redirected (using protocols other than Diameter) to that server, or gets connected to the top-up server, they might need another authorization (and maybe authentication) before they can top up the account 🙈. That part is out of scope for this spec, so it's not on us.
The credit-control server MAY also add one or more Restriction-Filter-Rule AVPs or one or more Filter-Id AVPs to the Credit-Control-Answer message 🌈. This lets the user reach other services, like zero-rated ones. If it does, the access device MUST drop every packet that doesn't match the IP filters in that Credit-Control-Answer, and, if possible, redirect the user to the destination in Redirect-Server.
Another entity besides the credit-control server can also set up the access device with suitable IP packet filters, to be used alongside the Diameter credit-control application. That case gets its own section, which is 5.6.3 ✨.
When the final granted units have been used up, the credit-control client MUST perform an intermediate interrogation 🔥. The point of this is to tell the credit-control server that the specified action has started and to report the used units. The credit-control server MUST deduct the used amount from the end user's account, but it MUST NOT make a new credit reservation 🙅♀️. The credit-control client can still send intermediate interrogations before all the final granted units are gone, though. That might be when rating and money reservation are needed, like when Validity-Time expires or when a mid-session service event changes the rating of the current service. So the credit-control client MUST NOT include any rating-related AVP in a request sent after all the final granted units are consumed. That's how the server knows the requested final unit action has started and that rating and money reservation aren't needed. (When the Multiple-Services-Credit-Control AVP is used, Service-Identifier or Rating-Group gets included to show which services we're talking about 💜.) Naturally, the Credit-Control-Answer doesn't contain any granted service unit, and it MUST include the Validity-Time AVP. That's how the credit-control client knows how long the subscriber can keep using network resources before the next intermediate interrogation goes out to the server ⏰.
When Validity-Time expires, the credit-control client sends a Credit-Control-Request (UPDATE_REQUEST) like normal 🌸. This message doesn't include the Used-Service-Unit AVP, because there's no allotted quota to report. The credit-control server processes the request and MUST perform the credit reservation. If the subscriber still hasn't topped up by then, whether they get disconnected or get access to services the credit-control server doesn't control for an unlimited time depends on the home service provider's policy 👑. (Heads up: that second option means the service element shouldn't remove the restriction filters when the credit-control session ends.) The server returns the right Result-Code (see section 9.1) in the Credit-Control-Answer message to carry out the policy-defined action 💅. Otherwise, new quota comes back, and the service element MUST remove all the restrictions that the graceful service termination process activated. Then it continues the credit-control session and the service session as usual ✨.
The credit-control client doesn't have to wait for Validity-Time to run out. It may send a spontaneous update (a brand-new Credit-Control-Request) if the service element can tell, for example, that the end user talked to the top-up server 🦋. Appendix A (Figure A.8) has an example of this.
Also, the credit-control server might already have kicked off this whole process during the first interrogation 🎀. But the user's account could be empty at that point. In that case the subscriber can be given a chance to top up and keep going 🫶. The credit-control client gets a Credit-Control-Answer (or a service-specific authorization answer) with Final-Unit-Indication and Validity-Time AVPs, but no Granted-Service-Unit. It immediately starts graceful service termination, and it doesn't send any message to the server to do that 😭. Appendix A has an example of this case too.
5.6.3. Restrict Access Action 🔒
A Final-Unit-Indication AVP with Final-Unit-Action set to RESTRICT_ACCESS tells the device doing this action that the user's access MUST be restricted 🚫. The restriction follows either the IP packet filters in the Restriction-Filter-Rule AVP(s) or the IP packet filters identified by the Filter-Id AVP(s). The credit-control server SHOULD include either the Restriction-Filter-Rule AVP or the Filter-Id AVP in the Credit-Control-Answer message 💖.
Again, another entity working alongside the Diameter credit-control application can set up the access device with appropriate IP packet filters. That entity might, for instance, configure the access device with IP flows that are allowed to pass when the Diameter credit-control application indicates RESTRICT_ACCESS or REDIRECT. The access device lets IP packets through according to the filter rules received in the Credit-Control-Answer message, plus the ones configured by that other entity 🧚. But when the user's account can't cover the cost of the requested service, the action to take is the credit-control server's responsibility, since it controls the prepaid subscriber 👑.
If some other entity working with the Diameter credit-control application has already set up the access device with all the filter rules needed for the end user, then the credit-control server presumably doesn't need to send any extra filter 🙈. So it is RECOMMENDED that credit-control server implementations supporting graceful service termination can be configured to send the Restriction-Filter-Rule AVP, the Filter-Id AVP, or neither of those 🍓.
When the final granted units have been used up, the credit-control client MUST perform an intermediate interrogation 🔥. The credit-control client and the credit-control server handle this intermediate interrogation and carry out the following procedures, exactly as described in the previous section for the REDIRECT action ✨.
The credit-control server may start the graceful service termination with the RESTRICT_ACCESS action already on the first interrogation 💜. That works just like the previous section describes for the REDIRECT action.
5.6.4. Usage of the Server-Initiated Credit Re-Authorization 🌈
Once the subscriber tops up the account, they're probably expecting all the restrictions from the graceful termination procedure to vanish right away, with unlimited service access coming back immediately 🥹. For the best user experience, the credit-control server implementation MAY support server-initiated credit re-authorization (see section 5.5) 🎀. If it does, then after a successful top-up, the credit-control server sends a Re-Auth-Request (RAR) message to ask for credit re-authorization 💌.
The credit-control client starts the credit re-authorization by sending a Credit-Control-Request with the CC-Request-Type AVP set to UPDATE_REQUEST 🦋. The Used-Service-Unit AVP isn't included, since there's no allotted quota to report. The Requested-Service-Unit AVP MAY be included in the request. Once the credit-control client successfully receives the Credit-Control-Answer with new Granted-Service-Unit, every restriction that was activated for graceful service termination MUST be removed from the service element 🧹. Then the credit-control session and the service session carry on as usual 💅✨.
5.7. Failure Procedures 💔✨
okay so this section is about what the credit-control client does when things go sideways 😭 its behavior in fault situations is controlled by the Credit-Control-Failure-Handling AVP (CCFH) 🫶. the CCFH can come from the Diameter home AAA server, from the credit-control server, or be configured locally 🎀. if the home AAA server sends one, it overrides the local config 👑. and a CCFH in the Credit-Control-Answer from the credit-control server always overrides whatever's already there 💅
the authorization server MAY include the Accounting-Realtime-Required AVP to decide what happens if sending accounting records to the accounting server has been temporarily blocked, as defined in [DIAMBASE] 🧚. it is RECOMMENDED that the client also set up a backup accounting flow toward an accounting server 🌸. mixing Accounting-Realtime-Required and Credit-Control-Failure-Handling AVPs lets you build different safety levels 🦋. for example, if the CCFH is CONTINUE for the credit-control flow and Accounting-Realtime-Required is DELIVER_AND_GRANT for the accounting flow, the service can still be granted to the end user even when the connection to the credit-control server is down 🙈. the catch is that the accounting server has to be able to collect the accounting info, and info has to be flowing between the accounting server and the credit-control server 😤
okay now the vibe shifts 🥹 the credit-control application is real-time and bi-directional between the credit-control client and the credit-control server, so using alternative destinations and buffering messages might not be enough when comms fail 😵💫. the credit-control server has to keep session state, so moving the message stream to a backup server takes a complex context transfer solution 🧩. whether the stream moves to a backup credit-control server during an ongoing session depends on the CC-Session-Failover AVP 🔁. BUT failover can happen anywhere along the path between the client and server if a transport failure is detected with a peer, as described in [DIAMBASE] 💀. which means the credit-control server might get duplicate messages 👯. the server can spot duplicates or out-of-sequence messages using its session state machine (section 7), the Session-Id AVP, and the CC-Request-Number AVP 🕵️♀️
if a failure happens during an ongoing session, the client may move the stream to an alternative server, but only if the CC-server indicated FAILOVER_SUPPORTED in the CC-Session-Failover AVP 🌈. a secondary credit-control server name, received from the home Diameter AAA server or configured locally, can be used as the address of the backup 🫶. if CC-Session-Failover is set to FAILOVER_NOT_SUPPORTED, the stream MUST NOT be moved to a backup server 🚫
for new sessions, failover to an alternative credit-control server SHOULD be performed if possible ✨. like, if the client can tell the primary server is unavailable, it can set up the new sessions with a possibly available secondary server 🧚
the AAA transport profile [AAATRANS] defines the application layer watchdog algorithm, which enables failover from a peer that has failed 🐣. it's controlled by a watchdog timer (Tw) defined in [AAATRANS] ⏱️. the recommended default initial value for Tw (Twinit) is 30 seconds 🍓. Twinit can go as low as 6 seconds, BUT according to [AAATRANS], setting it too low is likely to mean more duplicates AND more spurious failover and failback attempts 😬. the Diameter base protocol is shared by several different types of Diameter AAA applications that can run on the same service element 🏠. so tuning Twinit lower to meet real-time needs (like credit-control) will definitely cause those problems 😭. prepaid users, though, expect an answer from the network in a reasonable time ⏰. so the credit-control client reacts faster than the base protocol would 🏃♀️. this spec therefore defines the timer Tx, which the credit-control client uses (as defined in section 13) to supervise its communication with the credit-control server 🎯. when Tx elapses, the client takes an action toward the end user according to the Credit-Control-Failure-Handling AVP 💅
when Tx expires, the Diameter credit-control client ALWAYS terminates the service if the CCFH AVP is TERMINATE. (lowercase-ish drama, sorry 😂) the session may be moved to an alternative server ONLY if a protocol error DIAMETER_TOO_BUSY or DIAMETER_UNABLE_TO_DELIVER is received before Tx expires 🔄. so TERMINATE is NOT the move if you want proper failover 🙅♀️
⚠️ if the CCFH AVP isCONTINUEorRETRY_AND_TERMINATE, the service gets granted to the end user when Tx expires 🎉. a late answer with granted-units can still show up if base protocol transport failover happened on the path to the credit-control server 📬. (the Twinit default is 3 times the recommended Tx value, fyi 🤓)
so the client SHOULD grant the service, start monitoring resource usage, and wait for that possible late answer until the request times out (e.g., 120 seconds) ⏳. if the request fails and CC-Session-Failover is FAILOVER_NOT_SUPPORTED, the client terminates or continues the service depending on the CCFH, and MUST free all the reserved resources for the session 🧹. if DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY comes back, or the request times out, AND CC-Session-Failover is FAILOVER_SUPPORTED, the client MAY send the request to a backup server, if possible 🛟. if the backup gives a successful answer, the client continues the session with that server 🥳. but if the re-transmitted request ALSO fails, the client terminates or continues the service depending on the CCFH, and MUST free all the reserved resources for the session 💀
if a communication failure happens during graceful service termination, the service element SHOULD always terminate the ongoing service session 🛑
if the credit-control server detects a failure during an ongoing session, it terminates the session and returns the reserved units back to the end user's account 💸
the supervision session timer Tcc (as defined in section 13) is what the credit-control server uses to supervise the session ⏲️
last bit, promise 🫶. to support failover between credit-control servers, info about the session and account state SHOULD be transferred between the primary and secondary servers 🤝. implementations that support session failover MUST also ensure they can properly detect duplicate or out-of-sequence messages 🔍. the communication between the servers is an implementation issue and is outside the scope of this specification 🙃
6. One Time Event ⚡
the one-time event is for when the server doesn't need to keep any state, like checking how much a service costs 🧾. using a one-time event means the user has already been authenticated and authorized beforehand 🔐.
the one time event can be used when the client wants to know the cost of a service event, or check the account balance WITHOUT reserving any credit 👀. it can also be used to refund service units to the user's account, or to direct-debit without any credit-reservation 💳. here's how it flows (Figure 6) 👇
Diameter
End User Service Element AAA Server CC Server
(CC Client)
| Service Request | | |
|------------------>| | |
| | CCR(Event) | |
| |------------------->| CCR(Event) |
| | |------------------->|
| | | CCA(Granted-Units)|
| | CCA(Granted-Units)|<-------------------|
| Service Delivery |<-------------------| |
|<----------------->| | |
Figure 6: One time eventin environments like the 3GPP architecture, the one time event can be sent from the service element directly to the credit-control server 🛰️
6.1. Service Price Enquiry 🏷️
sometimes the credit-control client needs to know the price of a service event 🤔. there might be services from application service providers whose prices aren't known to the client 🙈. and the end user might want an estimate of the price before asking for the service 💭
a Diameter credit-control client requesting cost info MUST set the CC-Request-Type AVP to EVENT_REQUEST, include the Requested-Action AVP set to PRICE_ENQUIRY, and put the requested service event info into the Service-Identifier AVP in the Credit-Control-Request message 📝. extra service event info can go in service-specific AVPs or inside the Service-Parameter-Info AVP 🎀. the Service-Context-Id AVP tells you which service-specific document applies to the request 📄
the credit-control server calculates the cost of the requested event, but it does NOT do any account balance check or credit-reservation 🙅♀️
the estimated cost comes back to the client in the Cost-Information AVP in the Credit-Control-Answer message 💖
6.2. Balance Check 💖
okay so the Diameter credit-control client might only need to check that the end user's account balance covers a certain service 💅 and it does NOT reserve any units from the account while it's checking. ngl that's kind of the whole point. the catch is that this doesn't guarantee the credit will still be there when the client sends a separate request to debit the account later 😭
a Diameter credit-control client asking for the balance check MUST set the CC-Request-Type AVP to EVENT_REQUEST, include a Requested-Action AVP set to CHECK_BALANCE, and include the Subscription-Id AVP so the credit-control server knows which end user it's dealing with 🫶 the Service-Context-Id AVP tells the server which service-specific document the request is about 📄
the credit-control server does the balance check, but it does NOT make any credit reservation from the account 🙅♀️ the result (ENOUGH_CREDIT or NO_CREDIT) comes back to the client in the Check-Balance-Result AVP, inside the Credit-Control-Answer message 🎀
6.3. Direct Debiting 🌸
some service events always succeed in the service environment ✨ and the time between invoking the service and actually delivering it to the end user can be so long that session-based credit control would make the sessions unreasonably long 🙈 for these, the Diameter credit-control client can use the one-time event scenario for direct debiting. the client SHOULD be sure that the requested service event execution would succeed when this scenario is used 🔥
in the Credit-Control-Request message, CC-Request-Type is set to EVENT_REQUEST and Requested-Action is set to DIRECT_DEBITING. the Subscription-Id AVP SHOULD be included so the credit-control server can identify the end user 💜 the Event-Timestamp AVP SHOULD be included too, and it should contain the time when the service event is requested in the service element ⏰ the Service-Context-Id AVP points to the service-specific document for the request 🧚
if the client knows what the service event costs, it MAY put the monetary amount in the Requested-Service-Unit AVP 💰 if it doesn't know the cost, the Requested-Service-Unit AVP MAY hold the number of requested service events instead. the Service-Identifier AVP always says which service is involved 🍓 any extra service event information that needs rating MAY be sent as service-specific AVPs or inside the Service-Parameter-Info AVP 🦋
the credit-control server SHOULD rate the service event and deduct the matching monetary amount from the end user's account 💅 if the Requested-Service-Unit AVP is of type money, no rating is needed, but the matching monetary amount still gets deducted from the account.
the credit-control server sends the Granted-Service-Unit AVP back in the Credit-Control-Answer message. this AVP says how many service units the client can provide to the end user ✨ its type can be time, volume, service specific, or money, depending on the service event 🌈
if the server decides no credit control is needed for the service, it can return a result code saying credit control is not applicable (for example, the service is free of charge) 🎉
just for info, the Credit-Control-Answer message MAY also include the Cost-Information AVP, which holds the estimated total cost of the requested service 📊
6.4. Refund 🍓
some services refund service units to the end user's account, like gaming services 🎮
the credit-control client MUST set CC-Request-Type to EVENT_REQUEST and Requested-Action to REFUND_ACCOUNT in the Credit-Control-Request message. the Subscription-Id AVP SHOULD be included so the credit-control server can identify the end user 🫶 the Service-Context-Id AVP indicates the service-specific document for the request 📄
the Diameter credit-control client MAY include the monetary amount to be refunded in the Requested-Service-Unit AVP 💸 the Service-Identifier AVP always indicates the service concerned. if the client doesn't know the refunded monetary amount, it MAY send service-specific AVPs or the Service-Parameter-Info AVP alongside the Service-Identifier AVP, with extra service event information to be rated 🧾
just for info, the Credit-Control-Answer message MAY also include the Cost-Information AVP, which holds the estimated monetary amount of the refunded units 💖
6.5. Failure Procedure 💀
failover to an alternative credit-control server is allowed for a one-time event, because the server doesn't keep session state 🏃♀️ so if the credit-control client gets a protocol error like DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY, it can re-send the request to an alternative server, if one is possible 🔁 there MAY be protocol-transparent Diameter relays, redirect agents, or Diameter credit-control proxies between the client and the server. failover can happen at any point along the path between the client and the server when a transport failure is detected with a peer, as described in [DIAMBASE] 🛤️ requests can get duplicated for lots of reasons, so the credit-control server is responsible for real-time duplicate detection. implementation issues for duplicate detection are discussed in [DIAMBASE], Appendix C 🧠
when the credit-control client detects a communication failure with the credit-control server, what happens next depends on the requested action ⚡ the timer Tx (as defined in section 13) is what the client uses to supervise its communication with the credit-control server ⏱️
if the requested action is PRICE_ENQUIRY or CHECK_BALANCE and a communication failure is detected, the credit-control client SHOULD forward the request messages to an alternative credit-control server, if possible 🌈 the secondary credit-control server name, if the client received one from the home Diameter AAA server, can be used as the address of the backup server 📮
if the requested action is DIRECT_DEBITING, the Direct-Debiting-Failure-Handling AVP (DDFH) controls what the credit-control client does 🎀 the DDFH may be received from the home Diameter AAA server or may be configured locally 🏠 the credit-control server can also send the DDFH in any CCA message, to be used for direct debiting events compiled after that point. a DDFH value received from the home Diameter AAA server overrides the locally configured value, and a DDFH value received from the credit-control server in a Credit-Control-Answer message always overrides any existing value 👑
if the DDFH is set to TERMINATE_OR_BUFFER, the credit-control client SHOULD NOT grant the service if it can tell, possibly after a re-transmission attempt to an alternative credit-control server, from the result code or error code in the answer that the units have not been debited 🚫 otherwise, the client SHOULD grant the service to the end user and store the request in the credit-control application level non-volatile storage. (heads up: re-sending the request later is NOT a guarantee that the service will be debited, because the user's account may be empty when the server successfully processes it 😬) the client MUST mark these request messages as possible duplicates by setting the T-flag in the command header, as described in [DIAMBASE], section 3 🏷️
if the Direct-Debiting-Failure-Handling AVP is set to CONTINUE, the service SHOULD be granted, even if credit-control messages can't be delivered and aren't buffered 🥳
if the timer Tx expires, the credit-control client MUST continue the service and wait for a possible late answer ⏳ if the request times out, the client re-transmits it (marked with the T-flag) to a backup credit-control server, if possible. if the re-transmitted request also times out, or if a temporary error comes back in the answer, the client buffers the request when the Direct-Debiting-Failure-Handling AVP is set to TERMINATE_OR_BUFFER. if a failed answer comes back for the re-transmitted request, the client frees all the resources reserved for the event message and deletes the request, no matter what the DDFH value is 🗑️
a Credit-Control-Request with the requested action REFUND_ACCOUNT should always be stored in the credit-control application level non-volatile storage in case of a temporary failure 💾 the client MUST mark the re-transmitted request message as a possible duplicate by setting the T-flag in the command header, as described in [DIAMBASE], section 3 🔖
for stored requests, the implementation may choose to limit the number of re-transmission attempts and to define a re-transmission interval ⏲️
note that only one place in the credit-control system SHOULD be responsible for duplicate detection 🫵 if there's only one credit-control server in the given realm, that server may perform duplicate detection. if there's more than one credit-control server in a given realm, only one entity in the credit-control system should be responsible, so the end user's account doesn't get debited or credited multiple times for the same service event 💅
7. Credit-Control Application State Machine 🦋
this section defines the credit-control application state machine ✨
the first four state machines are for credit-control clients to follow. the first covers session-based credit control when the first interrogation happens as part of the authorization/authentication process. the second covers session-based credit control when the first interrogation happens after the authorization/authentication process. the requirements on which state machines have to be supported are discussed in section 5.2 📋
the third state machine covers session-based credit control for the intermediate and final interrogations. the fourth covers event-based credit control. all implementations that conform to this specification MUST observe these latter state machines 🫶
the fifth state machine shows the credit-control session from the credit-control server's point of view 🖥️
any event that isn't listed in the state machines MUST be treated as an error condition, and a corresponding answer, if applicable, MUST be returned to the originator of the message 🚨
in the state table, the event 'Failure to send' means that the Diameter credit-control client can't communicate with the desired destination or, if failover is supported, with a possibly defined alternative destination (for example, the request times out and no answer message arrives). this could be because the peer is down, or because of a physical link failure on the path to or from the credit-control server 📡
Okay so bestie, first up: 💖 a Temporary error is when the Diameter credit-control client gets a protocol error notification (DIAMETER_TOO_BUSY, DIAMETER_UNABLE_TO_DELIVER, or DIAMETER_LOOP_DETECTED) inside the Result-Code AVP of a Credit-Control-Answer command. That error may ultimately come back in answer to the retransmitted request sent to a defined alternative destination, if failover is supported. 🦋
A Failed answer is when the client gets a non-transient (permanent failure) notification in the Credit-Control-Answer command. Same plot twist here: it may ultimately come back in answer to the retransmitted request sent to a defined alternative destination, if failover is supported. 💅
The action store request just means a request gets saved in the credit-control application level non-volatile storage. Very safe, very secure, very 🫶.
Not successfully processed means the credit-control server couldn't process the message. Examples: an unknown end user, an account that's empty, or any of the errors defined in [DIAMBASE]. 😭
User service terminated can get triggered for lots of reasons, like normal user termination, network failure, and ASR (Abort-Session-Request). The Termination-Cause AVP tells you the reason, as specified in [DIAMBASE]. 🌸
The Tx timer is the one that controls how long the credit-control client waits while it's in the Pending state. It gets stopped when you leave Pending. In the state machine, the stop isn't written out when the new state is Idle, because moving to Idle already means the session and all its variables get cleared. Iconic. 🧚
PendingI, PendingU, PendingT, PendingE, and PendingB are the pending states. They're waiting for an answer to an Initial, Update, Termination, Event, or Buffered credit-control request, in that order. 🎀
CCFH and DDFH are short for Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling. 🍓
Heads up: in the state machine table below, failing over to a secondary server on 'Temporary error' or 'Failure to send' isn't spelled out one by one. Moving an ongoing credit-control message stream to an alternative server is still possible, though, if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, as described in section 5.7. ✨
Re-sending a credit-control event to an alternative server is supported too, as described in section 6.5. Main character energy. 👑
Now the tables. Let's go, no cap. 🌈
CLIENT, SESSION BASED for the first interrogation with AA request
State Event Action New State
---------------------------------------------------------------
Idle Client or device requests Send PendingI
access/service AA request
with added
CC AVPs,
start Tx
PendingI Successful AA req. Grant Open
answer received service to
end user,
stop Tx
PendingI Tx expired Disconnect Idle
user/dev
PendingI Failed AA answer received Disconnect Idle
user/dev
PendingI AA answer Grant Idle
received with result code service
equal to CREDIT_CONTROL_ to end user
NOT_APPLICABLE
PendingI User service terminated Queue PendingI
termination
event
PendingI Change in rating condition Queue PendingI
changed
rating
condition
event
CLIENT, SESSION BASED for the first interrogation with CCR
State Event Action New State
----------------------------------------------------------------
Idle Client or device requests Send PendingI
access/service CC initial
req.,
start Tx
PendingI Successful CC initial Stop Tx Open
answer received
PendingI Failure to send, or Grant Idle
temporary error and service to
CCFH equal to CONTINUE end user
PendingI Failure to send, or Terminate Idle
temporary error and end user's
CCFH equal to TERMINATE service
or to RETRY_AND_TERMINATE
PendingI Tx expired and CCFH Terminate Idle
equal to TERMINATE end user's
service
PendingI Tx expired and CCFH equal Grant PendingI
to CONTINUE or to service to
RETRY_AND_TERMINATE end user
PendingI CC initial answer Terminate Idle
received with result code end user's
END_USER_SERVICE_DENIED or service
USER_UNKNOWN
PendingI CC initial answer Grant Idle
received with result code service
equal to CREDIT_CONTROL_ to end user
NOT_APPLICABLE
PendingI Failed CC initial answer Grant Idle
received and CCFH equal to service to
CONTINUE end user
PendingI Failed CC initial answer Terminate Idle
received and CCFH equal end user's
to TERMINATE or to service
RETRY_AND_TERMINATE
PendingI User service terminated Queue PendingI
termination
event
PendingI Change in rating condition Queue PendingI
changed
rating
condition
event
CLIENT, SESSION BASED for intermediate and final interrogations
State Event Action New State
----------------------------------------------------------------
Open Granted unit elapses Send PendingU
and no final unit CC update
indication received req.,
start Tx
Open Granted unit elapses Terminate PendingT
and final unit action end user's
equal to TERMINATE service, send
received CC termination
req.
Open Change in rating condition Send PendingU
in queue CC update
req.,
Start Tx
Open Service terminated in queue Send PendingT
CC termination
req.
Open Change in rating condition Send PendingU
or Validity-Time elapses CC update
req.,
Start Tx
Open User service terminated Send PendingT
CC termination
req.
Open RAR received Send RAA PendingU
followed by
CC update req.,
start Tx
PendingU Successful CC update Stop Tx Open
answer received
PendingU Failure to send, or Grant Idle
temporary error and service to
CCFH equal to CONTINUE end user
PendingU Failure to send, or Terminate Idle
temporary error and end user's
CCFH equal to TERMINATE service
or to RETRY_AND_TERMINATE
PendingU Tx expired and CCFH Terminate Idle
equal to TERMINATE end user's
service
PendingU Tx expired and CCFH equal Grant PendingU
to CONTINUE or to service to
RETRY_AND_TERMINATE end user
PendingU CC update answer Terminate Idle
received with result code end user's
END_USER_SERVICE_DENIED service
PendingU CC update answer Grant Idle
received with result code service
equal to CREDIT_CONTROL_ to end user
NOT_APPLICABLE
PendingU Failed CC update Grant Idle
answer received and service to
CCFH equal to CONTINUE end user
PendingU Failed CC update Terminate Idle
answer received and CCFH end user's
equal to TERMINATE or service
to RETRY_AND_TERMINATE
PendingU User service terminated Queue PendingU
termination
event
PendingU Change in rating Queue PendingU
condition changed
rating
condition
event
PendingU RAR received Send RAA PendingU
PendingT Successful CC Idle
termination answer received
PendingT Failure to send, temporary Idle
error, or failed answer
PendingT Change in rating condition PendingT
CLIENT, EVENT BASED
State Event Action New State
----------------------------------------------------------------
Idle Client or device requests Send PendingE
a one-time service CC event
req.,
Start Tx
Idle Request in storage Send PendingB
stored
request
PendingE Successful CC event Grant Idle
answer received service to
end user
PendingE Failure to send, temporary Indicate Idle
error, failed CC event service
answer received, or error
Tx expired; requested
action CHECK_BALANCE or
PRICE_ENQUIRYokay bestie, the state machine is still going and it's giving tables 💅🎀
PendingE CC event answer Terminate Idle
received with result code end user's
END_USER_SERVICE_DENIED or service
USER_UNKNOWN and Tx running
PendingE CC event answer Grant Idle
received with result code service
CREDIT_CONTROL_NOT_APPLICABLE; to end
requested action user
DIRECT_DEBITING
PendingE Failure to send, temporary Grant Idle
error, or failed CC event service
answer received; requested to end
action DIRECT_DEBITING; user
DDFH equal to CONTINUE
PendingE Failed CC event Terminate Idle
answer received or temporary end user's
error; requested action service
DIRECT_DEBITING;
DDFH equal to
TERMINATE_OR_BUFFER and
Tx running
PendingE Tx expired; requested Grant PendingE
action DIRECT_DEBITING service
to end
user
PendingE Failure to send; requested Store Idle
action DIRECT_DEBITING; request with
DDFH equal to T-flag
TERMINATE_OR_BUFFER
PendingE Temporary error; requested Store Idle
action DIRECT_DEBITING; request
DDFH equal to
TERMINATE_OR_BUFFER;
Tx expired
PendingE Failed answer or answer Idle
received with result code
END_USER_SERVICE DENIED or
USER_UNKNOWN; requested action
DIRECT_DEBITING; Tx expired
PendingE Failed CC event answer Indicate Idle
received; requested service
action REFUND_ACCOUNT error and
delete request
PendingE Failure to send or Store Idle
Tx expired; requested request
action REFUND_ACCOUNT with T-flag
PendingE Temporary error, Store Idle
and requested action request
REFUND_ACCOUNT
PendingB Successful CC answer Delete Idle
received request
PendingB Failed CC answer Delete Idle
received request
PendingB Failure to send or Idle
temporary error
SERVER, SESSION AND EVENT BASED
State Event Action New State
----------------------------------------------------------------
Idle CC initial request Send Open
received and successfully CC initial
processed answer,
reserve units,
start Tcc
Idle CC initial request Send Idle
received but not CC initial
successfully processed answer with
Result-Code
!= SUCCESS
Idle CC event request Send Idle
received and successfully CC event
processed answer
Idle CC event request Send Idle
received but not CC event
successfully processed answer with
Result-Code
!= SUCCESS
Open CC update request Send CC Open
received and successfully update answer,
processed debit used
units,
reserve
new units,
restart Tcc
Open CC update request Send Idle
received but not CC update
successfully processed answer with
Result-Code
!= SUCCESS,
debit used
units
Open CC termination request Send Idle
received and successfully CC termin.
processed answer,
Stop Tcc,
debit used
units
Open CC termination request Send Idle
received but not CC termin.
successfully processed answer with
Result-Code
!= SUCCESS,
debit used
units
Open Session supervision timer Tcc Release Idle
expired reserved
units8. Credit-Control AVPs 💅✨
okay bestie, this is the big AVP list 🎀 Section 8 defines the credit-control AVPs that are specific to the Diameter credit-control application, and they MAY be included in the Diameter credit-control messages 💖
The AVPs defined in this section MAY also be included in authorization commands from authorization-specific applications, like [NASREQ] and [DIAMMIP], if the first interrogation happens as part of the authorization/authentication process, as described in section 5.2 🔐
The Diameter AVP rules live in the Diameter Base [DIAMBASE], section 4 📖 and every AVP in this section follows those rules, so no surprises there 🫶
Here's the full table of credit-control AVPs. It lists each AVP's name, AVP Code, data type, flag rules, and whether the AVP MAY be encrypted 🦋 The Diameter base [DIAMBASE] has the AVP Flag rules in section 4.5 💜
+--------------------+
| AVP Flag rules |
|----+-----+----+----|----+
AVP Section | | |SHLD|MUST| |
Attribute Name Code Defined Data Type |MUST| MAY | NOT|NOT |Encr|
-----------------------------------------|----+-----+----+----|----|
CC-Correlation-Id 411 8.1 OctetString| | P,M | | V | Y |
CC-Input-Octets 412 8.24 Unsigned64 | M | P | | V | Y |
CC-Money 413 8.22 Grouped | M | P | | V | Y |
CC-Output-Octets 414 8.25 Unsigned64 | M | P | | V | Y |
CC-Request-Number 415 8.2 Unsigned32 | M | P | | V | Y |
CC-Request-Type 416 8.3 Enumerated | M | P | | V | Y |
CC-Service- 417 8.26 Unsigned64 | M | P | | V | Y |
Specific-Units | | | | | |
CC-Session- 418 8.4 Enumerated | M | P | | V | Y |
Failover | | | | | |
CC-Sub-Session-Id 419 8.5 Unsigned64 | M | P | | V | Y |
CC-Time 420 8.21 Unsigned32 | M | P | | V | Y |
CC-Total-Octets 421 8.23 Unsigned64 | M | P | | V | Y |
CC-Unit-Type 454 8.32 Enumerated | M | P | | V | Y |
Check-Balance- 422 8.6 Enumerated | M | P | | V | Y |
Result | | | | | |
Cost-Information 423 8.7 Grouped | M | P | | V | Y |
Cost-Unit 424 8.12 UTF8String | M | P | | V | Y |
Credit-Control 426 8.13 Enumerated | M | P | | V | Y |
Credit-Control- 427 8.14 Enumerated | M | P | | V | Y |
Failure-Handling | | | | | |
Currency-Code 425 8.11 Unsigned32 | M | P | | V | Y |
Direct-Debiting- 428 8.15 Enumerated | M | P | | V | Y |
Failure-Handling | | | | | |
Exponent 429 8.9 Integer32 | M | P | | V | Y |
Final-Unit-Action 449 8.35 Enumerated | M | P | | V | Y |
Final-Unit- 430 8.34 Grouped | M | P | | V | Y |
Indication | | | | | |
Granted-Service- 431 8.17 Grouped | M | P | | V | Y |
Unit | | | | | |
G-S-U-Pool- 453 8.31 Unsigned32 | M | P | | V | Y |
Identifier | | | | | |
G-S-U-Pool- 457 8.30 Grouped | M | P | | V | Y |
Reference | | | | | |
Multiple-Services 456 8.16 Grouped | M | P | | V | Y |
-Credit-Control | | | | | |
Multiple-Services 455 8.40 Enumerated | M | P | | V | Y |
-Indicator | | | | | |
Rating-Group 432 8.29 Unsigned32 | M | P | | V | Y |
Redirect-Address 433 8.38 Enumerated | M | P | | V | Y |
-Type | | | | | |
Redirect-Server 434 8.37 Grouped | M | P | | V | Y |
Redirect-Server 435 8.39 UTF8String | M | P | | V | Y |
-Address | | | | | |
Requested-Action 436 8.41 Enumerated | M | P | | V | Y |
Requested-Service 437 8.18 Grouped | M | P | | V | Y |
-Unit | | | | | |
Restriction 438 8.36 IPFiltrRule| M | P | | V | Y |
-Filter-Rule | | | | | |
Service-Context 461 8.42 UTF8String | M | P | | V | Y |
-Id | | | | | |
Service- 439 8.28 Unsigned32 | M | P | | V | Y |
Identifier | | | | | |
Service-Parameter 440 8.43 Grouped | | P,M | | V | Y |
-Info | | | | | |
Service- 441 8.44 Unsigned32 | | P,M | | V | Y |
Parameter-Type | | | | | |
Service- 442 8.45 OctetString| | P,M | | V | Y |
Parameter-Value | | | | | |
Subscription-Id 443 8.46 Grouped | M | P | | V | Y |
Subscription-Id 444 8.48 UTF8String | M | P | | V | Y |
-Data | | | | | |
Subscription-Id 450 8.47 Enumerated | M | P | | V | Y |
-Type | | | | | |
Tariff-Change 452 8.27 Enumerated | M | P | | V | Y |
-Usage | | | | | |
Tariff-Time 451 8.20 Time | M | P | | V | Y |
-Change | | | | | |
Unit-Value 445 8.8 Grouped | M | P | | V | Y |
Used-Service-Unit 446 8.19 Grouped | M | P | | V | Y |
User-Equipment 458 8.49 Grouped | | P,M | | V | Y |
-Info | | | | | |
User-Equipment 459 8.50 Enumerated | | P,M | | V | Y |
-Info-Type | | | | | |
User-Equipment 460 8.51 OctetString| | P,M | | V | Y |
-Info-Value | | | | | |
Value-Digits 447 8.10 Integer64 | M | P | | V | Y |
Validity-Time 448 8.33 Unsigned32 | M | P | | V | Y |8.1. CC-Correlation-Id AVP 🌸
The CC-Correlation-Id AVP (AVP Code 411) is an OctetString 🧚 It carries info to correlate credit-control requests generated for different components of the service, like transport and service level. The one who allocates the Service-Context-Id (the unique identifier of a service specific document) is also the one responsible for defining the content and encoding of the CC-Correlation-Id AVP 🎀
8.2. CC-Request-Number AVP 🔢
The CC-Request-Number AVP (AVP Code 415) is an Unsigned32 that identifies this request within one session 💖 Session-Id AVPs are globally unique, so the combination of Session-Id and CC-Request-Number AVPs is also globally unique, and it can be used to match credit-control messages with their confirmations 🦋
Here's an easy way to make unique numbers: use 0 for a credit-control request of type INITIAL_REQUEST and EVENT_REQUEST, use 1 for the first UPDATE_REQUEST, 2 for the second, and so on. The value for TERMINATION_REQUEST is one more than the value for the last UPDATE_REQUEST 🍓
8.3. CC-Request-Type AVP 🎯
The CC-Request-Type AVP (AVP Code 416) is an Enumerated that tells you the reason for sending the credit-control request message ✨ It MUST be present in all Credit-Control-Request messages 🔥 These are the values defined for it:
INITIAL_REQUEST (1) 🌈 Initial request is used to start a credit-control session, and it carries the credit control info that's relevant to starting things off 🚀
UPDATE_REQUEST (2) 💫 An Update request carries credit-control info for an existing credit-control session 💅 Update credit-control requests SHOULD be sent every time a credit-control re-authorization is needed at the expiry of the allocated quota or validity time 👑 On top of that, additional service-specific events MAY trigger a spontaneous Update request 🎀
TERMINATION_REQUEST (3) 🛑 A Termination request is sent to end a credit-control session, and it carries the credit-control info relevant to the existing session 🫶
EVENT_REQUEST (4) 🎟️ An Event request is used when there's no need to keep any credit-control session state in the credit-control server 🧚 This request has all the info relevant to the service, and it's the only request for that service 💖 The reason for the Event request is further detailed in the Requested-Action AVP 🙈 The Requested-Action AVP MUST be included in the Credit-Control-Request message when CC-Request-Type is set to EVENT_REQUEST 🔥
8.4. CC-Session-Failover AVP 🦋
The CC-Session-Failover AVP (AVP Code 418) is an Enumerated that says whether moving the credit-control message stream to a backup server during an ongoing credit-control session is supported 💜 When communication fails, the message streams can be moved to an alternative destination if the credit-control server supports failover to an alternative server 🌈 The secondary credit-control server name, if it was received from the home Diameter AAA server, can be used as the address of the backup server 🫶 Heads up: an implementation is not required to support moving a credit-control message stream to an alternative server, because that also means moving the credit-control session info over to the backup server ⭐
These are the values defined for the CC-Session-Failover AVP:
FAILOVER_NOT_SUPPORTED (0) 🙅♀️ When the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit-control message stream MUST NOT to be moved to an alternative destination in the case of communication failure 💀
This is the default behavior if the AVP isn't included in the reply from the authorization or credit-control server 🧃
FAILOVER_SUPPORTED (1) 💖 When the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the credit-control message stream SHOULD be moved to an alternative destination in the case of communication failure ✨ Moving the stream to a backup server MAY require that the credit-control session info also be forwarded to the alternative server 🎀
8.5. CC-Sub-Session-Id AVP 🍭
The CC-Sub-Session-Id AVP (AVP Code 419) is an Unsigned64 that carries the credit-control sub-session identifier 🔢 The combination of the Session-Id and this AVP MUST be unique per sub-session 🔐 The value of this AVP MUST be increased monotonically by one for all new sub-sessions 📈 If this AVP is absent, it implies that no sub-sessions are in use 🫧
8.6. Check-Balance-Result AVP 💰
okay so the Check-Balance-Result AVP (AVP Code 422) is an Enumerated one, and it tells you the result of a balance check 🎀 It's only relevant when the Requested-Action AVP says CHECK_BALANCE in the Credit-Control-Request command. ngl that's a very specific little lane 💅
Here are the values defined for it:
ENOUGH_CREDIT(0): there's enough credit in the account to cover the requested service ✨NO_CREDIT(1): there isn't enough credit in the account to cover the requested service 💀
8.7. Cost-Information AVP 🧾
The Cost-Information AVP (AVP Code 423) is Grouped, and it's how the cost info for a service gets returned 🦋 The credit-control client can pass it along to the end user as is, totally transparently. The Unit-Value AVP inside it holds the cost, and it's always a type of money. For a price enquiry, it's the cost estimate of the service. For a credit-control session, it's the accumulated cost estimation so far 🌸
The Currency-Code says which currency the cost is in. The Cost-Unit covers the situation where the service is charged per unit, like $1 per minute 🕰️
Now the request types, because this part is kind of the main character moment 👑
- When the Requested-Action AVP is PRICE_ENQUIRY in the Credit-Control-Request command, the Cost-Information AVP in the next Credit-Control-Answer command has the cost estimation of the requested service. There's no reservation made, so no credit gets locked up 🫶
- When the Cost-Information AVP shows up in a Credit-Control-Answer with CC-Request-Type set to UPDATE_REQUEST, it has the accumulated cost estimation for the session. It doesn't factor in any credit reservation 🔥
- When the CC-Request-Type is EVENT_REQUEST or TERMINATION_REQUEST, the Cost-Information AVP has the estimated total cost for the requested service 🌈
It's defined like this (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Cost-Information ::= < AVP Header: 423 >
{ Unit-Value }
{ Currency-Code }
[ Cost-Unit ]8.8. Unit-Value AVP 🔢
The Unit-Value AVP is Grouped (AVP Code 445), and it specifies units as a decimal value 💖 It's stored as a number with an exponent, so Unit-Value = Value-Digits AVP * 10^Exponent. This is the trick that avoids unwanted rounding off, which is so smart 🧠 For example, 2,3 becomes Value-Digits = 23 and Exponent = -1. If the exponent part is missing, it MUST be interpreted as an exponent equal to zero. That's the rule, no exceptions 🙈
It's defined like this (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Unit-Value ::= < AVP Header: 445 >
{ Value-Digits }
[ Exponent ]8.9. Exponent AVP 📈
The Exponent AVP is Integer32 (AVP Code 429), and it holds the exponent value that gets applied to the Value-Digit AVP inside the Unit-Value AVP. Simple but powerful 🌸
8.10. Value-Digits AVP 🍓
The Value-Digits AVP is Integer64 (AVP Code 447), and it holds the significant digits of the number. If you need decimal values to show the units, the scaling MUST be indicated with the related Exponent AVP. Lowkey the best example is money: for $ 0.05, the Value-Digits AVP MUST be set to 5, and the scaling MUST be indicated with the Exponent AVP set to -2. Five cents, very precise, very iconic 💅
8.11. Currency-Code AVP 🌍
The Currency-Code AVP (AVP Code 425) is Unsigned32, and it holds a currency code that says which currency the monetary values were given in. The numbers come from the ISO 4217 standard [ISO4217] 🪙
8.12. Cost-Unit AVP 🕐
The Cost-Unit AVP (AVP Code 424) is UTF8String, and it's there so a human-readable string can be shown to the end user 🫧 It names the unit that goes with the Cost-Information when the service is charged per unit, like $1 per minute. The Cost-Unit can be minutes, hours, days, kilobytes, megabytes, etc. The vibes are very "your data plan, but make it readable" 📱
8.13. Credit-Control AVP 🎟️
The Credit-Control AVP (AVP Code 426) is Enumerated, and it MUST be included in AA requests when the service element has credit-control capabilities. Non-negotiable, bestie 🔒
CREDIT_AUTHORIZATION(0): if the home Diameter AAA server decides the user has a prepaid subscription, this value means the credit-control server MUST be contacted to do the first interrogation. The value of the Credit-Control AVP MUST always be set to 0 in an AA request sent to perform the first interrogation and to start a new credit-control session 💸RE_AUTHORIZATION(1): this tells the Diameter AAA server that a credit-control session is already going for the subscriber, and the credit-control server MUST not be contacted. It's only used once the first interrogation has worked and the session is ongoing, like when re-authorization gets triggered by Authorization-Lifetime. This value MUST NOT be used in an AA request sent to perform the first interrogation 🙅♀️
8.14. Credit-Control-Failure-Handling AVP 🚦
The Credit-Control-Failure-Handling AVP (AVP Code 427) is Enumerated, and the credit-control client uses it to decide what to do when sending credit-control messages to the credit-control server has been blocked, like by a temporary network problem 🌧️ Depending on the service logic, the server can tell the client to end the service right away if there's a reason to think it can't be charged. Or it can tell the client to try failing over to an alternative server, if one exists. After that, the server can either terminate or grant the service if the alternative connection fails too. Big decision energy 😭
TERMINATE(0): when this is set, the service MUST only be granted for as long as there's a connection to the credit-control server. If the credit-control client doesn't get any Credit-Control-Answer message within the Tx timer (as defined in section 13), the credit-control request counts as failed, and the end user's service session gets terminated 🛑
This is the default behavior if the AVP isn't included in the reply from the authorization or credit-control server.
CONTINUE(1): when this is set, the credit-control client SHOULD re-send the request to an alternative server in the case of transport or temporary failures. That only happens if a failover procedure is supported in both the credit-control server and the client, and an alternative server is available. Otherwise, the service SHOULD be granted, even if the credit-control messages can't be delivered 🫶RETRY_AND_TERMINATE(2): when this is set, the credit-control client SHOULD re-send the request to an alternative server in the case of transport or temporary failures. Same conditions apply: failover has to be supported on both sides, and an alternative server has to be available. Otherwise, the service SHOULD not be granted when the credit-control messages can't be delivered 🚫
8.15. Direct-Debiting-Failure-Handling AVP 💳
The Direct-Debiting-Failure-Handling AVP (AVP Code 428) is Enumerated, and the credit-control client uses it to decide what to do when sending credit-control messages (with Requested-Action AVP set to DIRECT_DEBITING) to the credit-control server has been blocked, like by a temporary network problem 🌷
TERMINATE_OR_BUFFER(0): when this is set, the service MUST be granted for as long as there's a connection to the credit-control server. If the credit-control client doesn't get any Credit-Control-Answer message within the Tx timer (as defined in section 13), the credit-control request counts as failed. The client SHOULD terminate the service if it can tell from the failed answer that units weren't debited. Otherwise, the credit-control client SHOULD grant the service, store the request in application level non-volatile storage, and try to re-send it. These requests MUST be marked as possible duplicates by setting the T-flag in the command header, as described in [DIAMBASE] section 3 🔁
This is the default behavior if the AVP isn't included in the reply from the authorization server.
CONTINUE(1): when this is set, the service SHOULD be granted, even if the credit-control messages can't be delivered, and the request should be deleted 🧹
8.16. Multiple-Services-Credit-Control AVP ✨
Okay so the Multiple-Services-Credit-Control AVP (AVP Code 456) is a Grouped AVP, and it holds everything for the independent credit-control of multiple services feature 💖 Each instance of this AVP carries units for one or more services, or for a single rating group.
The Service-Identifier and Rating-Group AVPs are how you match granted units to a specific service or rating group 🎀 If you include both, the units always go to the service(s) named in the Service-Identifier AVP(s). If only the Rating-Group-Id AVP is there, the Multiple-Services-Credit-Control AVP applies to every service that belongs to that rating group.
The G-S-U-Pool-Reference AVP lets the server name a G-S-U-Pool-Identifier, which is a credit pool where units of that type get pooled together 🧚 If there's a G-S-U-Pool-Reference AVP, then actual service units of that type MUST also be present. For example, if the G-S-U-Pool-Reference AVP says Unit-Type TIME, then the CC-Time AVP MUST be present.
The Requested-Service-Unit AVP MAY hold the amount of requested service units or the requested monetary value 💅 It MUST be there in the initial interrogation, and in the intermediate interrogations where new quota is being requested. Now here's the tea 🫖: if the credit-control client leaves out the Requested-Service-Unit AVP in a request, say because it figured out the end-user ended the service, the server MUST debit the used amount from the user's account, but MUST NOT send back new quota in the answer. 💀 The Validity-Time, Result-Code, and Final-Unit-Indication AVPs MAY show up in an answer command, as defined in sections 5.1.2 and 5.6 for graceful service termination.
When both the Tariff-Time-Change and Tariff-Change-Usage AVPs are present, the server MUST include two separate instances of the Multiple-Services-Credit-Control AVP, each with a Granted-Service-Unit AVP tied to the same service-identifier and/or rating-group 😭 If the two quotas belong to the same pool or to different pools, the credit pooling mechanism from section 5.1.2 applies. The Tariff-Change-Usage AVP MUST NOT be included in request commands that report used units from before and after a tariff time change. For those, the Used-Service-Unit AVP MUST be used 🔥
If a server doesn't implement the independent credit-control of multiple services functionality, it MUST treat the Multiple-Services-Credit-Control AVP as an invalid AVP 🙈
The Multiple-Services-Control AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Multiple-Services-Credit-Control ::= < AVP Header: 456 >
[ Granted-Service-Unit ]
[ Requested-Service-Unit ]
*[ Used-Service-Unit ]
[ Tariff-Change-Usage ]
*[ Service-Identifier ]
[ Rating-Group ]
*[ G-S-U-Pool-Reference ]
[ Validity-Time ]
[ Result-Code ]
[ Final-Unit-Indication ]
*[ AVP ]8.17. Granted-Service-Unit AVP 🌸
The Granted-Service-Unit AVP (AVP Code 431) is a Grouped AVP, and it holds the amount of units the Diameter credit-control client can give the end user until the service has to be released or a new Credit-Control-Request has to go out 💖 A client doesn't have to implement every unit type. But if it gets an unknown or unsupported unit type in the answer message, it has to treat that as an incorrect CCA answer. When that happens, the client MUST terminate the credit-control session and put the reason DIAMETER_BAD_ANSWER in the Termination-Cause AVP 🚨
The Granted-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Granted-Service-Unit ::= < AVP Header: 431 >
[ Tariff-Time-Change ]
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]8.18. Requested-Service-Unit AVP 🍓
The Requested-Service-Unit AVP (AVP Code 437) is a Grouped AVP, and it holds the amount of requested units the Diameter credit-control client asks for 🧁 A server doesn't have to implement every unit type. If it runs into an unknown or unsupported unit type, it must treat that as an invalid AVP.
The Requested-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Requested-Service-Unit ::= < AVP Header: 437 >
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]8.19. Used-Service-Unit AVP 🦋
The Used-Service-Unit AVP is a Grouped AVP (AVP Code 446), and it holds the amount of units that got used 📊 That's counted from the moment the service became active, or, if interim interrogations are happening during the session, from the moment the previous measurement ended.
The Used-Service-Unit AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Used-Service-Unit ::= < AVP Header: 446 >
[ Tariff-Change-Usage ]
[ CC-Time ]
[ CC-Money ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]8.20. Tariff-Time-Change AVP ⏰
The Tariff-Time-Change AVP (AVP Code 451) is a Time value. The server sends it to the client, and it holds the time, in seconds since January 1, 1900, 00:00 UTC, when the service's tariff is going to change 💅
The tariff change mechanism is optional for both the client and the server, and it isn't used for the time-based services defined in section 5. If a client doesn't support the tariff time change mechanism, it MUST treat the Tariff-Time-Change AVP in the answer message as an incorrect CCA answer. In that case, the client ends the credit-control session and puts the reason DIAMETER_BAD_ANSWER in the Termination-Cause AVP 💀
If this AVP is left out, that means no tariff change is being reported 🫶
8.21. CC-Time AVP ⏳
The CC-Time AVP (AVP Code 420) is an Unsigned32 value. It shows how long the requested, granted, or used time is, in seconds 🌈
8.22. CC-Money AVP 💸
The CC-Money AVP (AVP Code 413) is a Grouped AVP, and it specifies a monetary amount in a given currency 🪙 The Currency-Code AVP SHOULD be included, so please don't skip it, bestie 🫶
The CC-Money AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
CC-Money ::= < AVP Header: 413 >
{ Unit-Value }
[ Currency-Code ]8.23. CC-Total-Octets AVP 🧮
The CC-Total-Octets AVP (AVP Code 421) is an Unsigned64 value. It holds the total number of requested, granted, or used octets, no matter which direction they went (sent or received) ✨
8.24. CC-Input-Octets AVP 📥
The CC-Input-Octets AVP (AVP Code 412) is an Unsigned64 value. It holds the number of requested, granted, or used octets that can be, or already have been, received from the end user 🫧
8.25. CC-Output-Octets AVP 📤
The CC-Output-Octets AVP (AVP Code 414) is an Unsigned64 value. It holds the number of requested, granted, or used octets that can be, or already have been, sent to the end user 🚀
8.26. CC-Service-Specific-Units AVP 🎯
The CC-Service-Specific-Units AVP (AVP Code 417) is an Unsigned64 value. It specifies the number of service-specific units (things like events or points) given for a selected service 🎮 Those service-specific units always belong to the service named in the Service-Identifier AVP, or to the Rating-Group AVP when the Multiple-Services-Credit-Control AVP is in use 💜
8.27. Tariff-Change-Usage AVP 🔄
The Tariff-Change-Usage AVP (AVP Code 452) is an Enumerated value. It shows whether units got used before a tariff change, after one, or whether they straddled a tariff change during the reporting period 🍭 If this AVP is left out, that means no tariff change has happened.
When it shows up in answer messages as part of the Multiple-Services-Credit-Control AVP, it says whether the units are allocated to be used before or after a tariff change event 🎟️
When the Tariff-Time-Change AVP is present, leaving this AVP out of answer messages means the single quota mechanism applies.
Tariff-Change-Usage can be one of the following:
UNIT_BEFORE_TARIFF_CHANGE 0
UNIT_AFTER_TARIFF_CHANGE 1
UNIT_INDETERMINATE 2- UNIT_BEFORE_TARIFF_CHANGE (0): In the Multiple-Services-Credit-Control AVP, this value means the amount of units allocated for use before a tariff change happens. In the Used-Service-Unit AVP, it means the amount of resource units used before a tariff change had already happened 🌷
- UNIT_AFTER_TARIFF_CHANGE (1): In the Multiple-Services-Credit-Control AVP, this value means the amount of units allocated for use after a tariff change happens. In the Used-Service-Unit AVP, it means the amount of resource units used after the tariff change had already happened 🌙
- UNIT_INDETERMINATE (2): The used unit holds the amount of units that straddle the tariff change. For example, the metering process reports to the credit-control client in blocks of n octets, and one block straddled the tariff change 😵💫 This value is only to be used in the Used-Service-Unit AVP.
8.28. Service-Identifier AVP 🆔
The Service-Identifier AVP is an Unsigned32 value (AVP Code 439). It holds the identifier of a service 🪪 The specific service a request relates to is uniquely identified by the combination of the Service-Context-Id and Service-Identifier AVPs, so they work as a pair, iykyk 👑
A usage example of this AVP is shown in Appendix A (Flow IX) 📖
8.29. Rating-Group AVP 🏷️
The Rating-Group AVP is an Unsigned32 value (AVP Code 432). It holds the identifier of a rating group 🌼 Every service subject to the same rating type belongs to the same rating group. The specific rating group a request relates to is uniquely identified by the combination of the Service-Context-Id and Rating-Group AVPs 💅
A usage example of this AVP is shown in Appendix A (Flow IX) 🩷
8.30. G-S-U-Pool-Reference AVP 💖
okay so the G-S-U-Pool-Reference AVP (AVP Code 457) is a Grouped AVP 🎀 It shows up in the Credit-Control-Answer message and links the Granted-Service-Unit AVP it lives inside to a credit pool for the session ✨
The G-S-U-Pool-Identifier AVP tells you which credit pool the credit gets pulled from for this unit type 🫶
The CC-Unit-Type AVP says which kind of units are getting pooled 💅
The Unit-Value AVP is the multiplier 🧮 It converts between CC-Unit-Type units and abstract service units in the pool, which also means it converts to units for any other service or rating group tied to the same pool 🌈
This is how the G-S-U-Pool-Reference AVP is defined (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
G-S-U-Pool-Reference ::= < AVP Header: 457 >
{ G-S-U-Pool-Identifier }
{ CC-Unit-Type }
{ Unit-Value }8.31. G-S-U-Pool-Identifier AVP 🦋
The G-S-U-Pool-Identifier AVP (AVP Code 453) is an Unsigned32, and it identifies a credit pool within the session 🌸
8.32. CC-Unit-Type AVP 🧚
The CC-Unit-Type AVP (AVP Code 454) is an Enumerated type. It specifies the type of units considered to be pooled into a credit pool 💜
These are the values defined for the CC-Unit-Type AVP:
TIME 0
MONEY 1
TOTAL-OCTETS 2
INPUT-OCTETS 3
OUTPUT-OCTETS 4
SERVICE-SPECIFIC-UNITS 58.33. Validity-Time AVP ⏰
The Validity-Time AVP is an Unsigned32 (AVP Code 448) 🫧 It gets sent from the credit-control server to the credit-control client, and it carries the validity time of the granted service units ✨ The timer starts as soon as the client receives the Credit-Control-Answer Message containing this AVP. If the granted service units haven't been used up within that validity time, the credit-control client MUST send a Credit-Control-Request message to the server, with CC-Request-Type set to UPDATE_REQUEST 🔥 The value is given in seconds.
The Validity-Time AVP also does a second job 🌙 It's used for graceful service termination (see section 5.6) to tell the credit-control client how long the subscriber can keep using network resources after the specified action (REDIRECT or RESTRICT_ACCESS) has started. When the Validity-Time runs out, a new intermediate interrogation is sent to the server 💖
8.34. Final-Unit-Indication AVP 🚨
The Final-Unit-Indication AVP (AVP Code 430) is a Grouped AVP 🎀 It says that the Granted-Service-Unit AVP in the Credit-Control-Answer, or in the AA answer, holds the final units for the service 🫶 Once those units expire, the Diameter credit-control client is responsible for carrying out the action named in the Final-Unit-Action AVP (see section 5.6) 💅
If more than one unit type comes back in the Credit-Control-Answer, the unit type that expires first SHOULD cause the credit-control client to run the specified action 🌈
In the first interrogation, the Final-Unit-Indication AVP can come with Final-Unit-Action set to REDIRECT or RESTRICT_ACCESS, and with no Granted-Service-Unit AVP in the Credit-Control-Answer or in the AA answer 🧚 That tells the Diameter credit-control client to run the specified action right away ⚡ If the home service provider's policy is to terminate the service, the server SHOULD return the appropriate transient failure (see section 9.1) so it can carry out the policy-defined action 💀
The Final-Unit-Action AVP defines what the service element does when the user's account can't cover the cost of the service 😭 It MUST always be present if the Final-Unit-Indication AVP is included in a command 👑
If the Final-Unit-Action AVP is set to TERMINATE, no other AVPs MUST be present 🛑
If the Final-Unit-Action AVP is set to REDIRECT, at least the Redirect-Server AVP MUST be present 🔀 The Restriction-Filter-Rule AVP or the Filter-Id AVP MAY be present in the Credit-Control-Answer message if the user is also allowed to access other services that can't be reached through the address given in the Redirect-Server AVP 🦋
If the Final-Unit-Action AVP is set to RESTRICT_ACCESS, either the Restriction-Filter-Rule AVP or the Filter-Id AVP SHOULD be present 🔒
The Filter-Id AVP is defined in [NASREQ] 📎 It can be used to reference an IP filter list installed in the access device by means other than the Diameter credit-control application, for example one that's locally configured or configured by another entity 🫶
The Final-Unit-Indication AVP is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Final-Unit-Indication ::= < AVP Header: 430 >
{ Final-Unit-Action }
*[ Restriction-Filter-Rule ]
*[ Filter-Id ]
[ Redirect-Server ]8.35. Final-Unit-Action AVP 🔥
The Final-Unit-Action AVP (AVP Code 449) is an Enumerated type 🍓 It tells the credit-control client what action to take when the user's account can't cover the service cost 😭
These are the possible values for the Final-Unit-Action:
TERMINATE(0): The credit-control client MUST terminate the service session 🛑 This is the default handling, and it applies whenever the credit-control client gets an unsupported Final-Unit-Action value. It MUST be supported by all the Diameter credit-control client implementations that conform to this specification 💪REDIRECT(1): The service element MUST redirect the user to the address given in the Redirect-Server-Address AVP 🌐 The redirect action is defined in section 5.6.2 ✨RESTRICT_ACCESS(2): The access device MUST restrict the user's access according to the IP packet filters defined in the Restriction-Filter-Rule AVP, or according to the IP packet filters identified by the Filter-Id AVP 🚧 All the packets that don't match the filters MUST be dropped (see section 5.6.3) 🗑️
8.36. Restriction-Filter-Rule AVP 🛡️
The Restriction-Filter-Rule AVP (AVP Code 438) is an IPFilterRule type 🧱 It provides filter rules for services that should stay accessible even when there are no more service units granted 🦋 The access device has to configure the specified filter rules for the subscriber, and it MUST drop all the packets that don't match these filters 🚫 Zero, one, or more of these AVPs MAY be present in a Credit-Control-Answer message or in an AA answer message 💜
8.37. Redirect-Server AVP 🔀
The Redirect-Server AVP (AVP Code 434) is a Grouped AVP 🎀 It holds the address information of the redirect server (for example an HTTP redirect server or a SIP Server) that the end user gets connected to when the account can't cover the service cost 🌸 It MUST be present when the Final-Unit-Action AVP is set to REDIRECT 🫶
It is defined as follows (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Redirect-Server ::= < AVP Header: 434 >
{ Redirect-Address-Type }
{ Redirect-Server-Address }8.38. Redirect-Address-Type AVP 🗺️
The Redirect-Address-Type AVP (AVP Code 433) is an Enumerated type 🧭 It defines the address type of the address given in the Redirect-Server-Address AVP 💖
The address type can be one of the following:
IPv4 Address(0): The address type is in the form of a "dotted-decimal" IPv4 address, as defined in [IPv4] 🔢IPv6 Address(1): The address type is in the form of an IPv6 address, as defined in [IPv6Addr] 🌌 The address is a text representation of the address in either the preferred or alternate text form [IPv6Addr]. Conformant implementations MUST support the preferred form and SHOULD support the alternate text form for IPv6 addresses 🧠URL(2): The address type is in the form of a Uniform Resource Locator, as defined in [URL] 🔗SIP URI(3): The address type is in the form of a SIP Uniform Resource Identifier, as defined in [SIP] 📞
8.39. Redirect-Server-Address AVP 🌐
The Redirect-Server-Address AVP (AVP Code 435) is a UTF8String 🔤 It defines the address of the redirect server (for example an HTTP redirect server or a SIP Server) that the end user gets connected to when the account can't cover the service cost 💫
8.40. Multiple-Services-Indicator AVP 🧩
The Multiple-Services-Indicator AVP (AVP Code 455) is an Enumerated type 🌈 It shows whether the Diameter credit-control client can handle multiple services independently within a (sub-)session 🙌 If this AVP is absent, it means independent credit-control of multiple services isn't supported 🙈
A server that doesn't implement independent credit-control of multiple services MUST treat the Multiple-Services-Indicator AVP as an invalid AVP 🚫
These are the values defined for the Multiple-Services-Indicator AVP:
MULTIPLE_SERVICES_NOT_SUPPORTED 0
MULTIPLE_SERVICES_SUPPORTED 1MULTIPLE_SERVICES_NOT_SUPPORTED(0): The client does not support independent credit-control of multiple services within a (sub-)session 🙅MULTIPLE_SERVICES_SUPPORTED(1): The client supports independent credit-control of multiple services within a (sub-)session 🙌
8.41. Requested-Action AVP 🎬
The Requested-Action AVP (AVP Code 436) is an Enumerated type 🎯 It contains the requested action sent by a Credit-Control-Request command where the CC-Request-Type is set to EVENT_REQUEST 📨 These are the values defined for the Requested-Action AVP:
DIRECT_DEBITING(0): This is a request to decrease the end user's account according to the information in the Requested-Service-Unit AVP and/or the Service-Identifier AVP 💸 Additional rating information may be included in service-specific AVPs or in the Service-Parameter-Info AVP 🧾 The Granted-Service-Unit AVP in the Credit-Control-Answer command contains the debited units 🪙REFUND_ACCOUNT(1): This is a request to increase the end user's account according to the information in the Requested-Service-Unit AVP and/or the Service-Identifier AVP 🤑 Additional rating information may be included in service-specific AVPs or in the Service-Parameter-Info AVP 🧾 The Granted-Service-Unit AVP in the Credit-Control-Answer command contains the refunded units 💖CHECK_BALANCE(2): This is a balance check request 🔍 The checking of the account balance is done without any credit reservation from the account 🙅♀️ The Check-Balance-Result AVP in the Credit-Control-Answer command contains the result of the balance check 📊PRICE_ENQUIRY(3): This is a price enquiry request 🏷️ Neither checking the account balance nor reserving from the account is done 🙈 Only the price of the service is returned, in the Cost-Information AVP in the Credit-Control-Answer Command 💅
8.42. Service-Context-Id AVP ✨
okay so the Service-Context-Id AVP is UTF8String (AVP Code 461) and it's basically the unique ID for the Diameter credit-control service-specific document that applies to the request (see section 4.1.2) 🎀 Whoever allocates it, whether that's a service provider, a service element manufacturer, or a standardization body, it MUST uniquely identify one specific document. The format is:
"service-context" "@" "domain"
service-context = TokenThe Token is an arbitrary string of characters and digits 🦋
The domain part tells you who handed out the ID 👑 It can be ietf.org, 3gpp.org, etc. if a standards body made it, or it can be the FQDN of the service provider (like provider.example.com) or the vendor (like vendor.example.com) if a private entity made it 💅
This AVP SHOULD be placed as close to the Diameter header as possible 🫶
Service-specific documents that are just for private use (like, one provider's own thing, where interop isn't useful) can make up private identifiers without coordinating with anyone 🙈 But if you do want interoperability, coordinating the identifiers is RECOMMENDED, for example by publishing an informational RFC, so the Service-Context-Id is globally available 🌍✨
8.43. Service-Parameter-Info AVP 🧚
The Service-Parameter-Info AVP (AVP Code 440) is Grouped and holds service-specific info used for price calculation or rating 💖 The Service-Parameter-Type AVP says what kind of parameter it is, and the Service-Parameter-Value AVP holds the actual value. The contents of these AVPs are not in scope for this document, and they SHOULD be defined in another Diameter application, in standards from other standardization bodies, or in service-specific documentation 📚
In the case of an unknown service request (for example, an unknown Service-Parameter-Type), the answer message MUST contain the error code DIAMETER_RATING_FAILED 💀 A Credit-Control-Answer message with this error MUST contain one or more Failed-AVP AVPs holding the Service-Parameter-Info AVPs that caused the failure 😭
It's defined like this (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Service-Parameter-Info ::= < AVP Header: 440 >
{ Service-Parameter-Type }
{ Service-Parameter-Value }8.44. Service-Parameter-Type AVP 🍓
The Service-Parameter-Type AVP is Unsigned32 (AVP Code 441) and it defines the type of the service-event-specific parameter (like, it could be the end-user location or the service name) 🌸 The different parameters and their types are service specific, and this document doesn't define what they mean. Whoever allocates the Service-Context-Id (the unique ID of a service-specific document) is also on the hook for assigning Service-Parameter-Type values for that service and making sure they're unique within it 👑 The Service-Parameter-Value AVP holds the value tied to the service parameter type ✨
8.45. Service-Parameter-Value AVP 💜
The Service-Parameter-Value AVP is OctetString (AVP Code 442) and it contains the value of the service parameter type 🎀
8.46. Subscription-Id AVP 🦋
The Subscription-Id AVP (AVP Code 443) is how you identify the end user's subscription, and it's Grouped 🫶 It includes a Subscription-Id-Data AVP that holds the identifier and a Subscription-Id-Type AVP that says what kind of identifier it is 💖
It's defined like this (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
Subscription-Id ::= < AVP Header: 443 >
{ Subscription-Id-Type }
{ Subscription-Id-Data }8.47. Subscription-Id-Type AVP 🔥
The Subscription-Id-Type AVP (AVP Code 450) is Enumerated, and it tells you which type of identifier is carried in the Subscription-Id AVP 🧚
This spec defines the following subscription identifiers. New Subscription-Id-Type values can be assigned by an IANA designated expert, as defined in section 12 📚 A server MUST implement all the Subscription-Id-Types it needs to do credit authorization for the services it supports, including possible future values 👑 Unknown or unsupported Subscription-Id-Types MUST be treated according to the 'M' flag rule, as defined in [DIAMBASE] 🙈
END_USER_E164 0
The identifier is in international E.164 format (e.g., MSISDN),
according to the ITU-T E.164 numbering plan defined in [E164] and
[CE164].
END_USER_IMSI 1
The identifier is in international IMSI format, according to the
ITU-T E.212 numbering plan as defined in [E212] and [CE212].
END_USER_SIP_URI 2
The identifier is in the form of a SIP URI, as defined in [SIP].
END_USER_NAI 3
The identifier is in the form of a Network Access Identifier, as
defined in [NAI].
END_USER_PRIVATE 4
The Identifier is a credit-control server private identifier.8.48. Subscription-Id-Data AVP 🌈
The Subscription-Id-Data AVP (AVP Code 444) is used to identify the end user and it's UTF8String 💅 The Subscription-Id-Type AVP says which type of identifier is being used 🫶
8.49. User-Equipment-Info AVP 📱
The User-Equipment-Info AVP (AVP Code 458) is Grouped, and it lets the credit-control client say who the terminal is and what it can do, for the subscriber's connection to the network 🦋 Yes, the identity and the capability, both! 🔥
It's defined like this (per the grouped-avp-def of RFC 3588 [DIAMBASE]):
User-Equipment-Info ::= < AVP Header: 458 >
{ User-Equipment-Info-Type }
{ User-Equipment-Info-Value }8.50. User-Equipment-Info-Type AVP 💖
The User-Equipment-Info-Type AVP is Enumerated (AVP Code 459) and it defines what kind of user equipment info is in the User-Equipment-Info-Value AVP 🌸
This spec defines these user equipment types. New User-Equipment-Info-Type values can be assigned by an IANA designated expert, as defined in section 12 ✨
IMEISV 0
The identifier contains the International Mobile Equipment
Identifier and Software Version in the international IMEISV format
according to 3GPP TS 23.003 [3GPPIMEI].
MAC 1
The 48-bit MAC address is formatted as described in [RAD802.1X].
EUI64 2
The 64-bit identifier used to identify hardware instance of the
product, as defined in [EUI64].
MODIFIED_EUI64 3
There are a number of types of terminals that have identifiers
other than IMEI, IEEE 802 MACs, or EUI-64. These identifiers can
be converted to modified EUI-64 format as described in [IPv6Addr]
or by using some other methods referred to in the service-specific
documentation.8.51. User-Equipment-Info-Value AVP 🧚
The User-Equipment-Info-Value AVP (AVP Code 460) is OctetString, and the User-Equipment-Info-Type AVP says which type of identifier is being used 🎀
9. Result Code AVP Values 👑
This section defines new Result-Code AVP [DIAMBASE] values that must be supported by every Diameter implementation that conforms to this spec 🔥
The Credit-Control-Answer message includes the Result-Code AVP, which may show that there was an error in the Credit-Control-Request message 🙈 A rejected Credit-Control-Request message SHOULD cause the user's session to be terminated 💀
9.1. Transient Failures 🌤️
Errors in the transient failures category tell a peer that the request couldn't be satisfied when it arrived, but that it MAY be able to be satisfied later ✨
DIAMETER_END_USER_SERVICE_DENIED 4010
The credit-control server denies the service request due to
service restrictions. If the CCR contained used-service-units,
they are deducted, if possible.
DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011
The credit-control server determines that the service can be
granted to the end user but that no further credit-control is
needed for the service (e.g., service is free of charge).
DIAMETER_CREDIT_LIMIT_REACHED 4012
The credit-control server denies the service request because the
end user's account could not cover the requested service. If the
CCR contained used-service-units they are deducted, if possible.9.2. Permanent Failures 🛑
Errors in the permanent failure category tell the peer that the request failed and should not be attempted again 💅
DIAMETER_USER_UNKNOWN 5030
The specified end user is unknown in the credit-control server.
DIAMETER_RATING_FAILED 5031
This error code is used to inform the credit-control client that
the credit-control server cannot rate the service request due to
insufficient rating input, an incorrect AVP combination, or an AVP
or an AVP value that is not recognized or supported in the rating.
The Failed-AVP AVP MUST be included and contain a copy of the
entire AVP(s) that could not be processed successfully or an
example of the missing AVP complete with the Vendor-Id if
applicable. The value field of the missing AVP should be of
correct minimum length and contain zeros.10. AVP Occurrence Table 📋
The following table presents the AVPs defined in this document and says in which Diameter messages they MAY or MAY NOT be present 🌈 AVPs that can only be present inside a Grouped AVP aren't shown in this table, so don't look for them here 🙈
The table uses these symbols:
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
message.
0-1 Zero or one instance of the AVP MAY be present in the
message. It is considered an error if there is more
than one instance of the AVP.
1 One instance of the AVP MUST be present in the message.
1+ At least one instance of the AVP MUST be present in the
message.10.1. Credit-Control AVP Table
okay so this table is basically the cheat sheet 💅 it shows which credit-control AVPs from this doc are supposed to be present in the credit-control messages, and where they show up 🦋
+-----------+
| Command |
| Code |
|-----+-----+
Attribute Name | CCR | CCA |
------------------------------|-----+-----+
Acct-Multi-Session-Id | 0-1 | 0-1 |
Auth-Application-Id | 1 | 1 |
CC-Correlation-Id | 0-1 | 0 |
CC-Session-Failover | 0 | 0-1 |
CC-Request-Number | 1 | 1 |
CC-Request-Type | 1 | 1 |
CC-Sub-Session-Id | 0-1 | 0-1 |
Check-Balance-Result | 0 | 0-1 |
Cost-Information | 0 | 0-1 |
Credit-Control-Failure- | 0 | 0-1 |
Handling | | |
Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 |
Direct-Debiting-Failure- | 0 | 0-1 |
Handling | | |
Event-Timestamp | 0-1 | 0-1 |
Failed-AVP | 0 | 0+ |
Final-Unit-Indication | 0 | 0-1 |
Granted-Service-Unit | 0 | 0-1 |
Multiple-Services-Credit- | 0+ | 0+ |
Control | | |
Multiple-Services-Indicator | 0-1 | 0 |
Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 |
Origin-State-Id | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ |
Redirect-Host | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 |
Requested-Action | 0-1 | 0 |
Requested-Service-Unit | 0-1 | 0 |
Route-Record | 0+ | 0+ |
Result-Code | 0 | 1 |
Service-Context-Id | 1 | 0 |
Service-Identifier | 0-1 | 0 |
Service-Parameter-Info | 0+ | 0 |
Session-Id | 1 | 1 |
Subscription-Id | 0+ | 0 |
Termination-Cause | 0-1 | 0 |
User-Equipment-Info | 0-1 | 0 |
Used-Service-Unit | 0+ | 0 |
User-Name | 0-1 | 0-1 |
Validity-Time | 0 | 0-1 |
------------------------------|-----+-----+10.2. Re-Auth-Request/Answer AVP Table
this section is giving RAR/RAA energy 🌸 it defines the AVPs that are specific to the Diameter credit-control application and that MAY be included in the Diameter Re-Auth-Request/Answer (RAR/RAA) message [DIAMBASE] ✨
the Re-Auth-Request/Answer command MAY include the following additional AVPs:
+---------------+
| Command Code |
|-------+-------+
Attribute Name | RAR | RAA |
------------------------------+-------+-------+
CC-Sub-Session-Id | 0-1 | 0-1 |
G-S-U-Pool-Identifier | 0-1 | 0-1 |
Service-Identifier | 0-1 | 0-1 |
Rating-Group | 0-1 | 0-1 |
------------------------------+-------+-------+11. RADIUS/Diameter Credit-Control Interworking Model 🧚
okay this section is the big picture of how a RADIUS prepaid setup and Diameter credit control can talk to each other 🦋 it lays out the basic principles for the Diameter credit-control/RADIUS prepaid inter-working model, which is basically a message translation between a RADIUS based prepaid solution and a Diameter credit-control application 💖
the full protocol translation details between RADIUS and the Diameter credit-control application are out of scope for this spec, and they SHOULD be addressed in another appropriate document, like the RADIUS prepaid specification 📚
the Diameter credit-control architecture may have a Translation Agent that can translate between RADIUS prepaid and Diameter credit-control protocols. an AAA server (usually the home AAA server) may act as a Translation Agent and as a Diameter credit-control client for service elements that use credit-control mechanisms other than Diameter credit control, for instance RADIUS prepaid. in this case, the home AAA server contacts the Diameter credit-control server as part of the authorization process 🫶 the interworking architecture is shown in Figure 7, and the interworking flow is in Figure 8. in a roaming situation the service element (e.g., the NAS) may be located in the visited network, and a visited AAA server is usually contacted. the visited AAA server then connects to the home AAA server 🌈
RADIUS Prepaid
+--------+ +---------+ protocol +------------+ +--------+
| End |<----->| Service |<---------->| Home AAA | |Business|
| User | | Element | | Server | |Support |
+--------+ +-->| | |+----------+|->|System |
| +---------+ ||CC Client || | |
| |+----------+| | |
+--------+ | +------^-----+ +----^---+
| End |<--+ Credit-Control | |
| User | Protocol | |
+--------+ +-------V--------+ |
|Credit-Control |----+
| Server |
+----------------+
Figure 7: Credit-control architecture with service element
containing translation agent, translating RADIUS
prepaid to Diameter credit-control protocolwhen the AAA server acting as a Translation Agent gets an initial RADIUS Access-Request message from a service element (e.g., NAS access), it does regular authentication and authorization 🔐 if the RADIUS Access-Request says the service element is capable of credit-control, and the home AAA server finds that the subscriber is a prepaid subscriber, then a Diameter credit-control request SHOULD be sent toward the credit-control server to do credit authorization and set up a credit-control session 💅 after the Diameter credit-control server checks the end user's account balance, rates the service, and reserves credit from the end user's account, the reserved quota is returned to the home AAA server in the Diameter Credit-Control-Answer. then the home AAA server sends the reserved quota to the service element in the RADIUS Access-Accept ✨
when the allocated quota runs out, the service element sends a new RADIUS Access-Request containing the units used so far to the home AAA server 😭 the home AAA server shall map a RADIUS Access-Request containing the reported units to the Diameter credit-control server in a Diameter Credit-Control-Request (UPDATE_REQUEST). the Diameter credit-control server debits the used units from the end user's account and allocates a new quota, which is returned to the home AAA server in the Diameter Credit-Control-Answer. the quota is then transferred to the service element in the RADIUS Access-Accept. when the end user terminates the service, or when the entire quota has been used, the service element sends a RADIUS Access-Request. to debit the used units from the end user's account and stop the credit-control session, the home AAA server sends a Diameter Credit-Control-Request (TERMINATION_REQUEST) to the credit-control server. the Diameter credit-control server acknowledges the session termination by sending a Diameter Credit-Control-Answer to the home AAA server. the RADIUS Access-Accept is sent to the NAS 🎀
here's a diagram of the RADIUS prepaid and Diameter credit-control interworking sequence 🦋
Service Element Translation Agent
(e.g., NAS) (CC Client) CC Server
| Access-Request | |
|----------------------->| |
| | CCR (initial) |
| |----------------------->|
| | CCA (Granted-Units) |
| |<-----------------------|
| Access-Accept | |
| (Granted-Units) | |
|<-----------------------| |
: : :
| Access-Request | |
| (Used-Units) | |
|----------------------->| |
| | CCR (update, |
| | Used-Units) |
| |----------------------->|
| | CCA (Granted-Units) |
| |<-----------------------|
| Access-Accept | |
| (Granted-Units) | |
|<-----------------------| |
: : :
| Access-Request | |
|----------------------->| |
| | CCR (terminate, |
| | Used-Units) |
| |----------------------->|
| | CCA |
| |<-----------------------|
| Access-Accept | |
|<-----------------------| |
| | |
Figure 8: Message flow example with RADIUS prepaid -
Diameter credit-control interworking12. IANA Considerations 📋
this section is the list of namespaces that were either created in this spec, or the values assigned to existing namespaces that IANA manages 🌷
for the subsections below, when we talk about review by a Designated Expert, note that the designated expert is assigned by the IESG. at first, those Expert discussions happen on the AAA WG mailing list 💜
12.1. Application Identifier
this spec assigns the value 4, 'Diameter Credit Control', to the Application Identifier namespace defined in [DIAMBASE]. see section 1.3 for more info 🍓
12.2. Command Codes
this spec uses the value 272 from the Command code namespace defined in [DIAMBASE] for the Credit-Control-Request (CCR) and Credit-Control-Answer (CCA) commands 💅
12.3. AVP Codes
this spec assigns the values 411 - 461 from the AVP code namespace defined in [DIAMBASE]. see section 8 for the assignment of the namespace in this spec 🫶
12.4. Result-Code AVP Values ✨
okay so this spec snags the values 4010, 4011, 4012, 5030, and 5031 from the Result-Code AVP value namespace in [DIAMBASE] 💅 the namespace itself gets explained over in section 9 if you wanna peek 🎀
12.5. CC-Request-Type AVP 💖
as defined in section 8.3, the CC-Request-Type AVP has Enumerated type values 1 - 4. IANA made and manages a namespace for it, and every other value is up for grabs from a Designated Expert [IANA] 🦋
12.6. CC-Session-Failover AVP 🌸
as defined in section 8.4, the CC-Failover-Supported AVP has Enumerated type values 0 - 1. IANA made and manages a namespace for it, and every other value is up for grabs from a Designated Expert [IANA] ✨
12.7. CC-Unit-Type AVP 🧚
as defined in section 8.32, the CC-Unit-Type AVP has Enumerated type values 0 - 5. IANA runs the namespace for this one too, and everything left over goes to a Designated Expert [IANA] 💜
12.8. Check-Balance-Result AVP 🍓
as defined in section 8.6, the Check-Balance-Result AVP has Enumerated type values 0 - 1. IANA has the namespace, and the remaining values are assigned by a Designated Expert [IANA] 🌈
12.9. Credit-Control AVP 👑
as defined in section 8.13, the Credit-Control AVP has Enumerated type values 0 - 1. IANA keeps the namespace, and a Designated Expert [IANA] handles all the leftover values 🫶
12.10. Credit-Control-Failure-Handling AVP 🔥
as defined in section 8.14, the Credit-Control-Failure-Handling AVP has Enumerated type values 0 - 2. IANA is in charge of the namespace, and all remaining values are available for assignment by a Designated Expert [IANA] 💅
12.11. Direct-Debiting-Failure-Handling AVP 💸
as defined in section 8.15, the Direct-Debiting-Failure-Handling AVP has Enumerated type values 0 - 1. IANA created and maintains the namespace, and a Designated Expert [IANA] gets the rest 🎀
12.12. Final-Unit-Action AVP 🦋
as defined in section 8.35, the Final-Unit-Action AVP has Enumerated type values 0 - 2. IANA owns the namespace, and every other value is available for assignment by a Designated Expert [IANA] 🌸
12.13. Multiple-Services-Indicator AVP ⭐
as defined in section 8.40, the Multiple-Services-Indicator AVP has Enumerated type values 0 - 1. IANA has the namespace, and all remaining values go to a Designated Expert [IANA] ✨
12.14. Redirect-Address-Type AVP 🧚♀️
as defined in section 8.38, the Redirect-Address-Type AVP has Enumerated type values 0 - 3. IANA made and maintains the namespace, and the rest are assigned by a Designated Expert [IANA] 💜
12.15. Requested-Action AVP 🍓
as defined in section 8.41, the Requested-Action AVP has Enumerated type values 0 - 3. IANA runs the namespace, and a Designated Expert [IANA] takes care of every other value 🌈
12.16. Subscription-Id-Type AVP 🫶
as defined in section 8.47, the Subscription-Id-Type AVP has Enumerated type values 0 - 4. IANA has the namespace, and all remaining values are available for assignment by a Designated Expert [IANA] 👑
12.17. Tariff-Change-Usage AVP 💖
as defined in section 8.27, the Tariff-Change-Usage AVP has Enumerated type values 0 - 2. IANA is maintaining the namespace, and everything else is up for a Designated Expert [IANA] 🔥
12.18. User-Equipment-Info-Type AVP 📱
as defined in section 8.50, the User-Equipment-Info-Type AVP has Enumerated type values 0 - 3. IANA keeps the namespace, and all remaining values are available for assignment by a Designated Expert [IANA] 💅
13. Credit-Control Application Related Parameters 🎀
Tx timer ⏱️
okay bestie, when real-time credit control is needed, the credit-control client checks in with the credit-control server before and during the service the end user is getting 🦋 because it's real-time, the communication delays SHOULD be minimized, like so the end user doesn't wait forever for their service to set up 😭 the Tx timer exists to limit how long the client can sit in the Pending state 🧚 when it runs out, the client does something to the end user based on the value of the Credit-Control-Failure-Handling AVP or the Direct-Debiting-Failure-Handling AVP 💀 the recommended value is 10 seconds ✨
Tcc timer 🌸
the Tcc timer watches over an ongoing credit-control session on the credit-control server 🫶 it is RECOMMENDED to use the Validity-Time as the input for setting the Tcc timer value ✨ if there are transient failures in the network, the Diameter credit-control server might drop into the Idle state, and to dodge that, the Tcc timer MAY be set so that Tcc equals to 2 x Validity-Time 🙈
Credit-Control-Failure-Handling and Direct-Debiting-Failure-Handling 🌈
client implementations might let you configure these AVPs locally 💅 if they do, their value and behavior are defined in section 5.7 for the Credit-Control-Failure-Handling AVP and in section 6.5 for the Direct-Debiting-Failure-Handling AVP 👑
14. Security Considerations 🔐
okay this part is SERIOUS bestie, so read it all 😭
14.1. Direct Connection with Redirects 🦋
the Diameter base protocol [DIAMBASE] says every Diameter implementation has to use underlying security, which means IPsec or TLS 🔥 these are believed to give enough protection under the normal Internet threat model, meaning the authorized nodes in the protocol haven't been compromised, but the attacker fully controls the channels between them 💀 that covers eavesdropping, message modification, insertion, man-in-the-middle attacks, and replay attacks 🙈 this application also has application-layer replay protection through the Session-Id from [DIAMBASE] and the CC-Request-Number, which this document specifies ✨ the Diameter credit-control application often gets used inside a single domain, and there might be just one hop between peers 🫶 in those setups, TLS or IPsec is enough 💅 the details about TLS and IPsec security considerations are covered in [DIAMBASE] 🎀
because this application deals with monetary transactions, directly or indirectly, it attracts more kinds of security attacks 💸 so all the parties talking to each other MUST be authenticated, including, for example, TLS client-side authentication 👑 authorization of the client SHOULD also be emphasized, meaning the client is allowed to do credit control for a certain user 🧚 the specific authorization methods are outside the scope of this specification, but they could be something like manual configuration 🌸
another threat is malicious modification, injection, or deletion of AVPs or whole credit-control messages 😱 these messages carry sensitive billing info, like the subscription Id, granted units, used units, and cost information, and tampering with them can have financial consequences 💰 sometimes just delaying the credit-control messages can cause disruptions for the credit-control client or server 🙈
even without changing any messages, an adversary can still be a threat by eavesdropping, because the transactions include private information about the user 👀 by watching the credit-control messages, someone can also learn about the credit-control server's billing models and business relationships 💼
when third-party relays or proxies are involved, hop-by-hop security doesn't necessarily give enough protection for the Diameter user session 🚨 in some cases, it may be inappropriate to send Diameter messages like CCR and CCA with sensitive AVPs through untrusted Diameter proxy agents, since there's no guarantee that third-party proxies won't modify the credit-control commands or AVP values 💅
14.1. Direct Connection with Redirects 🦋
a Diameter credit-control agent can't always know whether the agents between it and the end user's Diameter credit-control server are reliable 🫣 in that case, the agent doesn't have a routing entry in its Diameter Routing Table (defined in [DIAMBASE], section 2.7) for the realm of the credit-control server in the end user's home domain 🗺️ the agent can have a default route set up to a local Redirect agent, and it sends the CCR message to that redirect agent 🎀 the local Redirect agent then sends back a redirect notification (Result-code 3006, DIAMETER_REDIRECT_INDICATION) to the credit-control agent, along with the Diameter credit-control server information (Redirect-Host AVP) and information (Redirect-Host-Usage AVP) about how the routing entry from the Redirect-Host should be used ✨ the credit-control agent then forwards the CCR message directly to one of the hosts listed in the CCA message from the redirect agent 🚀 if the value of the Redirect-Host-Usage AVP is not equal to zero, all following messages go to the host in the Redirect-Host AVP until the time in the Redirect-Max-Cache-Time AVP runs out ⏳
there are still some authorization issues even with redirects 😬 attacks might target nodes that were properly authorized but abuse that authorization or got compromised 💀 these issues get discussed more fully in [DIAMEAP], section 8 🫶
15. References 📚
15.1. Normative References
Okay, the must-read list 📚✨ These are the docs this spec leans on, so you'd need them to build anything.
- [DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
- [3GPPCHARG] 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects, Service aspects; Charging and Billing, (release 5), 3GPP TS 22.115 v. 5.2.1, 2002-03.
- [SIP] 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.
- [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
- [E164] Recommendation E.164/I.331 (05/97): The International Public Telecommunication Numbering Plan. 1997.
- [CE164] Complement to ITU-T Recommendation E.164 (05/1997): "List of ITU-T Recommendation E.164 assigned country codes", June 2000.
- [E212] Recommendation E.212 (11/98): The international identification plan for mobile terminals and mobile users. 1998.
- [CE212] Complement to ITU-T Recommendation E.212 (11/1997): "List of mobile country or geographical area codes", February 1999.
- [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [IPv6Addr] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [ISO4217] Codes for the representation of currencies and funds, International Standard ISO 4217, 2001.
- [NASREQ] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
- [AAATRANS] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
- [URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
- [RAD802.1X] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
- [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997.
- [3GPPIMEI] 3rd Generation Partnership Project; Technical Specification Group Core Network, Numbering, addressing and identification, (release 5), 3GPP TS 23.003 v. 5.8.0, 2003-12.
15.2. Informative References
These ones are the background reading 🧠🌸 Nice to know, not strictly required.
- [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
- [DIAMMIP] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
- [DIAMEAP] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", Work in Progress.
- [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
16. Acknowledgements 🫶
The authors gave a shoutout to Bernard Aboba, Jari Arkko, Robert Ekblad, Pasi Eronen, Benny Gustafsson, Robert Karlsson, Avi Lior, Paco Marin, Jussi Maki, Jeff Meyer, Anne Narhi, John Prudhoe, Christopher Richards, Juha Vallinen, and Mark Watson for their comments and suggestions. Everyone deserves credit for helping make this spec 💖
Appendix A. Credit-Control Sequences ✨
A.1. Flow I
Time for the fun part, bestie 🎀 This is a picture of a whole prepaid credit-control conversation, step by step:
NAS
End User (CC Client) AAA Server CC Server
|(1)User Logon |(2)AA Request (CC AVPs) |
|------------------>|------------------->| |
| | |(3)CCR(initial, CC AVPs)
| | |------------------->|
| | | (4)CCA(Granted-Units)
| | |<-------------------|
| |(5)AA Answer(Granted-Units) |
|(6)Access granted |<-------------------| |
|<----------------->| | |
| | | |
: : : :
| |(7)CCR(update,Used-Units) |
| |------------------->|(8)CCR |
| | | (update,Used-Units)
| | |------------------->|
| | |(9)CCA(Granted-Units)
| |(10)CCA(Granted-Units)<------------------|
| |<-------------------| |
: : : :
| (Auth. lifetime expires) | |
| |(11) AAR (CC AVP) | |
| |------------------->| |
| | (12) AAA | |
| |<-------------------| |
: : : :
: : : :
|(13) User logoff | | |
|------------------>|(14)CCR(term.,Used-Units) |
| |------------------->|(15)CCR |
| | | (term.,Used-Units)
| | |------------------->|
| | | (16)CCA |
| | (17)CCA |<-------------------|
| |<-------------------| |
| |(18)STR | |
| |------------------->| |
| | (19)STA | |
| |<-------------------| |
Figure A.1: Flow ISo here's the tea ☕💅 This is a credit-control flow for Network Access Services prepaid. The Diameter [NASREQ] is implemented in the Network Access Server (NAS), and the whole focus of this flow is the credit authorization 👑
Step by step:
- The user logs on to the network (1). 🔑
- The Diameter NAS sends a Diameter AA-Request (AAR) to the home Diameter AAA server. The credit-control client fills the AAR with the Credit-Control AVP set to
CREDIT_AUTHORIZATION, and service-specific AVPs go in too, as usual [NASREQ]. - The home Diameter AAA server does its usual service-specific Authentication and Authorization. It figures out the user is a prepaid user, and it notices from the Credit-Control AVP that the NAS has credit-control capabilities. 🕵️♀️
- It sends a Diameter Credit-Control-Request with CC-Request-Type set to
INITIAL_REQUESTto the Diameter credit-control server, to do credit authorization (3) and set up a credit-control session. (The home Diameter AAA server may pass along service-specific AVPs it got from the NAS as input for the rating process.) - The credit-control server checks the end user's account balance, rates the service, and reserves credit from the end user's account. 💰
- The reserved quota goes back to the home Diameter AAA server in the Diameter Credit-Control-Answer (4).
- The home Diameter AAA server sends the reserved quota to the NAS in the Diameter AA-Answer (AAA). If AAA succeeds, the NAS starts the credit-control session and starts monitoring the granted units (5).
- The NAS grants the end user access (6). ✨
- When the allocated quota runs out, the NAS sends a Diameter Credit-Control-Request with CC-Request-Type set to
UPDATE_REQUESTto the home Diameter AAA server (7). This message carries the units used so far. - The home Diameter AAA server forwards the CCR to the credit-control server (8).
- The credit-control server debits the used units from the end user's account and allocates a new quota. That quota goes back to the home Diameter AAA server in the Diameter Credit-Control-Answer (9), and then gets forwarded to the NAS (10). 🔄
- Now, while the session is still going, the authorization lifetime expires. The authorization/authentication client in the NAS does a service-specific re-authorization to the home Diameter AAA server, as usual. The credit-control client fills the AAR with the Credit-Control AVP set to
RE_AUTHORIZATION, which says the credit-control server shall not be contacted, because the credit authorization is controlled by the burning rate of the granted units (11). 🔥 - The home Diameter AAA server does its service-specific re-authorization as usual and returns the AA-Answer to the NAS (12).
- The end user logs off (13). 👋 To debit the used units from the end user's account and stop the credit-control session, the NAS sends a Diameter Credit-Control-Request with CC-Request-Type set to
TERMINATION_REQUESTto the home Diameter AAA server (14). - The home Diameter AAA server forwards the CCR to the credit-control server (15).
- The credit-control server acknowledges the session termination by sending a Diameter Credit-Control-Answer to the home Diameter AAA server (16), which forwards the answer to the NAS (17).
- Last but not least, STR/STA happens between the NAS and the home Diameter AAA server, as usual (18-19). 🦋
That's the whole flow, iykyk 🧚
A.2. Flow II ✨
SIP Proxy/Registrar AAA
A (CC Client) Server B CC Server
|(i) REGISTER | | | |
|------------->|(ii) | | |
| |------------->| | |
| |authentication & | |
| |authorization | | |
| |<-------------| | |
|(iii)200 OK | | |
|<-------------| | |
: : : :
|(1) INVITE | :
|------------->|
| |(2) CCR (Initial, SIP specific AVP) |
| |------------------------------------------->|
| |(3) CCA (Granted-Units) |
| |<-------------------------------------------|
| |(4) INVITE | |
| |---------------------------->| |
: : : :
| |(5) CCR (update, Used-Units) |
| |------------------------------------------->|
| |(6) CCA (Granted-Units) |
| |<-------------------------------------------|
: : : :
|(7) BYE | | |
|------------->| | |
| |(8) BYE | |
| |---------------------------->| |
| |(9) CCR (termination, Used-Units) |
| |------------------------------------------->|
| |(10) CCA () |
| |<-------------------------------------------|
| | | |Figure A.2: Flow II
This is an example of Diameter credit-control for SIP sessions 💖. Okay, the flow mostly zooms in on the credit-control messages, and the SIP signaling here is inaccurate on purpose 🙈. This diagram is not trying to define a service provider's SIP network, so please don't take it as a blueprint. For the sake of this example, a few assumptions are made below 🎀.
Prepaid services based on time usage for SIP sessions usually need some entity in the provider's network to intercept every request in the SIP dialog 👀. That's how it catches the events that matter for credit-control, like session establishment and session release, so it can talk to the credit-control server properly. So in this example, the SIP Proxy adds a Record-Route header to the initial SIP INVITE, which makes sure all future requests in that dialog go through it 🦋. (For what Record-Route and "dialog" actually mean, check out [SIP] 📚.) And how much media the proxy measures for credit-control depends on the business model used to set up the end systems and proxies in the SIP network 💅.
Okay, here's the story. The end user (SIP User Agent A) sends a REGISTER with credentials (i) 🔐. The SIP Proxy asks the home AAA server to do Multimedia authentication and authorization, using the Diameter Multimedia application for instance (ii) 🫶. The home AAA server checks that the credentials are correct and looks at the user profile. Eventually a 200 OK (iii) goes back to the UA ✨. Note that this authentication and authorization stays valid for the registration validity period (so until re-registration happens), which means several SIP sessions can be set up without re-authorizing 🌸.
UA A sends an INVITE (1) 📞. The SIP Proxy sends a Diameter Credit-Control-Request (INITIAL_REQUEST) to the Diameter credit-control server (2). That request carries info pulled from the SIP signaling that describes the service being requested, like the calling party, the called party, and the Session Description Protocol attributes 🧾. The credit-control server checks the end user's account balance, rates the service, and reserves credit from that account 💰. The reserved quota comes back to the SIP Proxy in the Diameter Credit-Control-Answer (3). Then the SIP Proxy forwards the INVITE to UA B (4). B's phone rings, B answers, and the media flows between them while the SIP Proxy starts measuring the quota 🔥.
When the allocated quota runs out, the SIP Proxy sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the credit-control server (5) 😭. This message tells the server how many units have been used so far. The server debits those used units from the end user's account and hands out new credit in the Diameter Credit-Control-Answer (6) 💜. Then the end user ends the call by sending a BYE (7) 👋. The SIP Proxy forwards that BYE to UA B (8) and sends a Diameter Credit-Control-Request (TERMINATION_REQUEST) to the credit-control server (9) 🌈. The server confirms the session is over by sending a Diameter Credit-Control-Answer back to the SIP Proxy (10) 👑.
A.3. Flow III ✨
A credit-control flow for Multimedia Messaging Services is shown in Figure A.3 📱. The big rule here is that the sender gets charged as soon as the messaging server successfully stores the message 💅.
The end user A sends a Multimedia Message (MMS) to the MMS server (1) 💌. The MMS server stores the message and then sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action DIRECT_DEBITING) to the credit-control server (2) 🍓. That request includes info about the MMS message, like its size, the recipient address, and the image coding type 🖼️. The credit-control server checks the end user's account balance, rates the service, and debits the service from the account 💸. The granted quota goes back to the MMS server in the Diameter Credit-Control-Answer (3) ✨. The MMS server then acknowledges that it successfully received the message (4) 🫶. Next, the MMS server notifies the recipient about the new MMS (5), and end user B retrieves the message from the MMS message store (6),(7) 🎉.
A.4. Flow IV ✨
MMS Server
Content Server (CC Client) B CC Server
|(1) Send MMS | | |
|--------------->| | |
| |(2) CCR (event, CHECK_BALANCE, |
| | MMS specific AVP) |
| |-------------------------------->|
| |(3) CCA (ENOUGH_CREDIT) |
| |<--------------------------------|
|(4) Send MMS Ack| | |
|<---------------| | |
| |(5) Notify MMS | |
| |--------------->| |
: : : :
| |(6) Retrieve MMS| |
| |<---------------| |
| |(7) CCR (event, DIRECT_DEBITING,|
| | MMS specific AVP) |
| |-------------------------------->|
| |(8) CCA (Granted-Units) |
| |<--------------------------------|
| |(9) Retrieve MMS| |
| | Ack | |
| |--------------->| |
| | | |
Figure A.4: Flow IVThis is a babe of an example of Diameter credit-control for direct debiting in the Multimedia Messaging Service environment 💖. The flow is mostly here to show off how the credit-control messages work, and the MMS signaling is inaccurate on purpose. The diagram is not, by any means, an attempt to define any service provider's MMS configuration or billing model 🙈. Don't come for me with your carrier setup, bestie 💅.
Okay so, the credit-control flow for MMS is shown in Figure A.4, and the recipient is the one who gets charged at message delivery 🎀. A content server sends a Multimedia Message (MMS) to the MMS server (1), and that server stores it. The message recipient is the one who pays for it in this case. Here's the tea: there can be a substantially long time between the MMS server receiving the message and the recipient actually retrieving it, so the MMS server does not open any credit-control session with the Diameter credit-control server. Instead it does a balance check only, with no credit reservation, by sending a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action CHECK_BALANCE) to confirm that end user B can cover the cost of the MMS (2) 🦋. The Diameter credit-control server checks the account balance and sends the answer back to the MMS server in the Diameter Credit-Control-Answer (3). The MMS server then acknowledges that it successfully received the MMS (4) ✨. Next it notifies the recipient about the new MMS (5), and after some time, end user B goes and grabs the message from the MMS message store (6) 🧚.
Now the direct debit part 👑. The MMS server sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action DIRECT_DEBITING) to the Diameter credit-control server (7). This request carries info about the MMS message, like its size, recipient address, and coding type 💜. The credit-control server checks the balance, rates the service, and debits it from the end user's account. The granted quota then comes back to the MMS server in the Diameter Credit-Control-Answer (8). Finally, the MMS is transferred to end user B (9) 🌈.
Transferring the MMS can take an extended time and can fail, so a recovery action may be needed. The MMS server should return the already debited units to the user's account by using the REFUND action described in section 6.4. 💀
A.5. Flow V 🦋
SIP Controller
A (CC Client) B CC Server
|(1)INVITE B(SDP)| | |
|--------------->| | |
| |(2) CCR (event, PRICE_ENQUIRY, |
| | SIP specific AVPs) |
| |-------------------------------->|
| |(3) CCA (Cost-Information) |
| |<--------------------------------|
| (4)MESSAGE(URL)| | |
|<---------------| | |
|(5)HTTP GET | | |
|--------------->| | |
|(6)HTTP POST | | |
|--------------->|(7)INVITE(SDP) | |
| |--------------->| |
| | (8)200 OK | |
| (9)200 OK |<---------------| |
|<---------------| | |
Figure A.5: Flow VThis is an example of Diameter credit-control for SIP sessions 🎀. Like before, the flow is here to illustrate the credit-control messages, and the SIP signaling is inaccurate. The diagram is not an attempt to define a service provider's SIP network, so no wild network-design takes, please 🙈.
Figure A.5 is an example of an Advice of Charge (AoC) service for a SIP call 💅. User A can be either a postpaid or prepaid subscriber who uses the AoC service. It is assumed that the SIP controller also has HTTP capabilities and delivers an interactive AoC web page 🌸. That page could show things like the cost information, the call details taken from the SDP, and a button to accept or not accept the charges. (There may be lots of other ways to deliver AoC information, but this flow focuses on the credit-control messages, so we're keeping it focused, bestie 🫶.) The user has been authenticated and authorized before starting the call, and is subscribed to the AoC service ✨.
Here's how it plays out. UA A sends an INVITE with SDP to B (1) 💖. The SIP controller figures out that the user is subscribed to AoC and sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action PRICE_ENQUIRY) to the Diameter credit-control server (2). That request carries SIP-specific AVPs taken from the SIP signaling, which describe the requested service. Think calling party, called party, and Session Description Protocol attributes 🧚. The Diameter credit-control server works out what the service costs and returns the Credit-Control-Answer with the Cost-Information AVP (3). Then the SIP controller builds the AoC web page using the SIP info and the cost info it got from the credit-control server. It sends a SIP MESSAGE with a URL pointing to that page (4). When A's UA gets the MESSAGE, it automatically opens the web browser to fetch the AoC info (5) 🌈. The user clicks the right button and accepts the charges (6) 👑. The SIP controller then carries on with the session and sends the INVITE to the B party, which accepts the call (7, 8, 9) 🔥.
A.6. Flow VI 💜
Gaming Server
End User (CC Client) CC Server
| (1)Service Delivery | |
|<---------------------->| |
: : :
: : :
| |(2)CCR(event,REFUND,Requested-
| |Service-Unit,Service-Parameter-Info)
| |----------------------->|
| | (3)CCA(Cost-Information)
| |<-----------------------|
| (4)Notification | |
|<-----------------------| |
Figure A.6: Flow VIFigure A.6 shows a credit-control flow for the REFUND case 🍓. It is assumed that there is a trusted relationship and a secure connection between the Gaming server and the Diameter credit-control server 🔒. The end user may be either a prepaid or a postpaid subscriber.
So, while the end user is playing the game (1), she hits a new level that gives her a bonus 🎮✨. The Gaming server sends a Diameter Credit-Control-Request (EVENT_REQUEST with Requested-Action REFUND_ACCOUNT) to the Diameter credit-control server (2) 🏆. This request carries the Requested-Service-Unit AVP, with the CC-Service-Specific-Units set to the number of points the user just won. It also includes the Service-Parameter-Info AVP, which says which service event should be rated, for example a Tetris Bonus 🧩. From that info, the Diameter credit-control server works out the amount to credit, refunds the user's account, and returns the Credit-Control-Answer, including the Cost-Information AVP (3). That Cost-Information shows the credited amount 💰. At the first opportunity, the Gaming server tells the end user how much was credited (4) 🎉.
A.7. Flow VII ✨
Okay bestie, Flow VII is the graceful service termination for a SIP call, and it is SO good 💅🎀 The call is set up so the controller sits in the middle as a B2BUA (Back to Back User Agent) doing third-party call control (3PCC) 🦋 The signaling in this diagram is not 100% accurate, because the real point of the flow is the graceful service termination and the credit-control authorization 🫶 If you want the best practice for 3PCC, check out [RFC3725].
SIP Controller Top-Up
A (CC Client) Server B CC Server
| | | | |
| | (1) CCR(Update,Used-Unit) | |
| |------------------------------------------>|
| | (2) CCA(Final-Unit, Redirect)|
| |<------------------------------------------|
: : : : :
: : : : :
| | (3) CCR(Update, Used-Units)| |
| |------------------------------------------>|
| | (3a)INVITE("hold") | |
| |--------------------------->| |
| | | (4) CCA(Validity-Time)|
| |<------------------------------------------|
| (5)INVITE | (6)INVITE | | |
|<--------------|------------->| | |
| (7)RTP | | |
|..............................| | |
| | (8)BYE | | |
| |<-------------| | |
| | (9)CCR(Update) | |
| |------------------------------------------>|
| | (10)CCA(Granted-Unit) |
| |<------------------------------------------|
| (12)INVITE | (11)INVITE | |
|<--------------|--------------------------->| |
Figure A.7: Flow VIISo user A has a prepaid subscription, and the call is already going between A and B 📞🌸 When the allocated quota runs out, the SIP controller sends a Diameter Credit-Control-Request (UPDATE_REQUEST) to the Diameter credit-control server (1), and that message carries the units used so far. The server debits those units from the end user's account and hands back the final quota in the Diameter Credit-Control-Answer (2) 💅 That answer includes the Final-Unit-Indication AVP with Final-Unit-Action set to REDIRECT, Redirect-Address-Type set to SIP URI, and Redirect-Server-Address set to the Top-up server name, for example sip:sip-topup-server@domain.com ✨
When that final quota expires, the SIP controller sends another Credit-Control-Request (UPDATE_REQUEST) to the credit-control server (3) and puts the called party on "hold" by sending an INVITE with the right connection address in the SDP (3a) 🙈 This request also has the units used so far. This time the server debits the used units but does not make any credit reservation. The Credit-Control-Answer comes back to the SIP controller (4) with the Validity-Time, which supervises the graceful service termination ⏳
Next, the SIP controller sets up a SIP session between the prepaid user and the Top-up server (5, 6) 🧚 The Top-up server plays an announcement and asks the user to type in a credit card number and how much money to add to the account (7). Then it checks the card number, replenishes the account (using some means outside the scope of this specification), and lets go of the SIP session (8) 💖 The spec does not say how any of that happens, and that is totally on purpose.
Now the SIP controller can assume the prepaid user and the Top-up server actually talked. It sends a spontaneous Credit-Control-Request (UPDATE_REQUEST) to the credit-control server to check whether the account got topped up (9) 👑 If it did, the server reserves credit from the end user's account and sends the reserved quota back in the Credit-Control-Answer (10) 🔥 Only then does the SIP controller reconnect the caller and the called party (11, 12) 🦋
A.8. Flow VIII ✨
Flow VIII is the graceful service termination that kicks off at the very first interrogation, because the user's account is already empty 😭 This example assumes the credit-control server supports server-initiated credit re-authorization, and the Diameter [NASREQ] application runs on the Network Access Server (NAS) 🌈
NAS Top-up CC
End-User (CC Client) AAA Server Server Server
|(1)User Logon |(2)AA Request (CC AVPs) | |
|------------------>|------------------->| | |
| | |(3)CCR(initial, CC AVPs)
| | |------------------->|
| | |(4)CCA(Final-Unit, |
| | | Validity-Time)|
| | |<-------------------|
| |(5)AA Answer(Final-Unit,Validity-Time) |
|(6)Limited Access |<-------------------| | |
| granted | | | |
|<----------------->| | | |
| | | | |
| (7)TCP/HTTP | (8)TCP/HTTP | |
|<----------------->|<----------------------------->| |
| (9) Replenish account | |
|<------------------------------------------------->| |
| | | (10)RAR |
| |<-------------------|<-------------------|
| | (11) RAA | |
| |------------------->|------------------->|
| |(12)CCR(update) | |
| |------------------->|(13)CCR(Update) |
| | |------------------->|
| | |(14)CCA(Granted-Units)
| |(15)CCA(Granted-Units)<------------------|
| |<-------------------| |
Figure A.8: Flow VIIIHere's the play-by-play 🎀 The user logs on (1), and the Diameter NAS sends a Diameter AA-Request to the home Diameter AAA server. The credit-control client fills the AAR with the Credit-Control AVP set to CREDIT_AUTHORIZATION, and the service-specific AVPs go in as usual [NASREQ]. The home AAA server does its normal service-specific Authentication and Authorization 💅 It also works out that the user is prepaid and notices from the Credit-Control AVP that the NAS can do credit control.
So the home AAA server sends a Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST to the credit-control server (3). That gets credit authorization done and sets up a credit-control session. (The home AAA server may forward service-specific AVPs it got from the NAS as input for rating.) The credit-control server checks the balance, sees it can't cover the service, and starts the graceful service termination 😭 The Credit-Control-Answer goes back to the home AAA server (4). It carries the Final-Unit-Indication AVP plus a Validity-Time set to a reasonable window so the user can top up, say 10 minutes ⏰ The Final-Unit-Indication has Final-Unit-Action set to REDIRECT, Redirect-Address-Type set to URL, and Redirect-Server-Address set to the HTTP Top-up server name.
The home AAA server passes those credit-control AVPs to the NAS in the Diameter AA-Answer (5) ✨ Once AAA succeeds, the NAS starts the credit-control session and right away begins the graceful service termination, just as the server said. The NAS grants limited access (6) 🧚 The HTTP client on the user's device opens the transport connection that the NAS redirected to the Top-up server (7, 8).
The user gets a web page to enter a credit card number and how much money to add. It also shows a notice that they get unlimited access if the top-up succeeds within, for example, 10 minutes 🌸 The Top-up server validates the card number and replenishes the account (using some means outside the scope of this specification) (9). After a successful top-up, the credit-control server sends a Re-Auth-Request to the NAS (10). The NAS replies with a Re-Auth-Answer (11) and starts credit re-authorization by sending a Credit-Control-Request (UPDATE_REQUEST) to the credit-control server (12, 13) 🔥
Last step: the credit-control server reserves credit from the end user's account and sends the reserved quota back to the NAS through the home AAA server in the Credit-Control-Answer (14, 15). The NAS then lifts the restriction from the graceful service termination and starts monitoring the granted units 👑
A.9. Flow IX ✨
Okay so Flow IX is where things get fancy 🦋 The Diameter credit-control application defines the Multiple-Services-Credit-Control AVP, which lets you do independent credit control for several services inside one credit-control (sub-)session, for service elements that can handle that. You can also request and allocate resources as a credit pool that's shared between services or rating groups 💖
The example that follows shows a credit-control client and server doing independent credit control of multiple services, as defined in section 5.1.2 🍓 It's assumed that Service-Identifiers, Rating-Groups, and their associated parameters (for example, the IP 5-tuple) are configured locally in the service element, or provisioned by something other than the credit-control server 🫶
End User Service Element CC Server
(CC client)
|(1)User logon | |
|------------------>|(2)CCR(initial, Service-Id access, |
| | Access specific AVPs, |
| | Multiple-Service-Indicator) |
| |---------------------------------------->|
| |(3)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id access, |
| | Validity-time, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 10))) |
| |<----------------------------------------|
: : :
|(4)Service-Request (Service 1) |
|------------------>|(5)CCR(update, Multiple-Services-CC( |
| | Requested-Units(), Service-Id 1, |
| | Rating-Group 1)) |
| |---------------------------------------->|
| |(6)CCA(Multiple-Services-CC ( |
| | Granted-Units(Time), |
| | Rating-Group 1, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 1))) |
| |<----------------------------------------|
: : :
|(7)Service-Request (Service 2) |
|------------------>| |
: : :
: : :
|(8)Service-Request (Service 3&4) |
|------------------>|(9)CCR(update, Multiple-Services-CC ( |
| | Requested-Units(), Service-Id 3, |
| | Rating-Group 2), |
| | Multiple-Services-CC ( |
| | Requested-Units(), Service-Id 4, |
| | Rating-Group 3)) |
| |---------------------------------------->|
| |(10)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id 3, Rating-Group 2, |
| | Validity-time, |
| | G-S-U-Pool-Reference(Pool-Id 2, |
| | Multiplier 2)), |
| | Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id 4, Rating-Group 3 |
| | Validity-Time, |
| | Final-Unit-Ind.(Terminate), |
| | G-S-U-Pool-Reference(Pool-Id 2, |
| | Multiplier 5))) |
| |<----------------------------------------|
: : :
: : :
| +--------------+ | |
| |Validity time | |(11)CCR(update, |
| |expires for | | Multiple-Services-CC ( |
| |Service-Id | | Requested-Unit(), |
| | access | | Used-Units(In-Octets,Out-Octets),|
| +--------------+ | Service-Id access)) |
| |---------------------------------------->|
| |(12)CCA(Multiple-Services-CC ( |
| | Granted-Units(Total-Octets), |
| | Service-Id access, |
| | Validity-Time, |
| | G-S-U-Pool-Reference(Pool-Id 1, |
| | Multiplier 10))) |
| |<----------------------------------------|
: : :
: : :
| +--------------+ | |
| |Total Quota | |(13)CCR(update, |
| |elapses for | | Multiple-Services-CC ( |
| |pool 2: | | Requested-Unit(), |
| |service 4 not | | Used-Units(In-Octets,Out-Octets),|
| |allowed, | | Service-Id 3, Rating-group 2), |
| |service 3 cont| | Multiple-Services-CC ( |
| +--------------+ | Used-Units(In-Octets,Out-Octets),|
| | Service-Id 4, Rating-Group 3)) |
| |---------------------------------------->|
| |(14)CCA(Multiple-Services-CC ( |
| | Result-Code 4011, |
| | Service-Id 3)) |
| |<----------------------------------------|
: : :
: : :
|(15) User logoff | |
|------------------>|(16)CCR(term, |
| | Multiple-Services-CC ( |
| | Used-Units(In-Octets,Out-Octets),|
| | Service-Id access), |
| | Multiple-Services-CC ( |
| | Used-Units(Time), |
| | Service-Id 1, Rating-Group 1), |
| | Multiple-Services-CC ( |
| | Used-Units(Time), |
| | Service-Id 2, Rating-Group 1)) |
| |---------------------------------------->|
| |(17)CCA(term) |
| |<----------------------------------------|
Figure A.9: Flow example independent credit-control of multiple
services in a credit-control (sub-)SessionOkay bestie, so the user logs on (1) 🔐✨ and the service element fires off a Credit-Control-Request with CC-Request-Type set to INITIAL_REQUEST 💌. That's to the credit-control server, to authorize credit for the bearer service (like Internet access) and to open up a credit-control session (2) 🌸. In this message the client says "hey, I can do independent credit-control of multiple services" by including the Multiple-Service-Indicator AVP 🦋. The server checks the end user's balance, looks at the rating info it got (the Service-Id and access-specific AVPs) 👀, rates the request, and reserves credit from the account 💅. Let's say it reserves $5 and the cost is $1/MB 💸. It sends back a Credit-Control-Answer with a Multiple-Services-Credit-Control AVP holding a quota of 5MB for the Service-Id (access), a multiplier of 10, and Pool-Id 1 (3) 🎀.
Next the user uses Service 1 (4) 🎮. The service element sends a CCR with CC-Request-Type set to UPDATE_REQUEST (5) to ask for credit for Service 1 under Rating-Group 1 🚀. The server notices Service 1 pulls from the same account as access, so it's pool 1 💜. It rates the request by Service-Id/Rating-Group and updates the existing reservation by asking for more credit 📈. Okay so it reserves $5 more (now the reservation is $10) and the cost is $0.1/minute 🤑. The server authorizes the whole Rating-Group, so it sends back a CCA with a quota of 50min associated to Rating-Group 1, a multiplier of 1, and Pool-Id 1 (6) 🌈. The client adjusts the total for pool 1 based on that quota, which gives S for Pool 1 = 100 ✨.
The user uses Service 2, which is inside the authorized Rating-Group 1 (7) 🫶. Resources just get consumed from pool 1, easy 🍓.
Now the user asks for Services 3 and 4 too, and those aren't authorized yet (8) 😭. The service element sends an UPDATE_REQUEST CCR (9) with two Multiple-Services-Credit-Control AVPs, one for Service 3 in Rating-Group 2 and one for Service 4 in Rating-Group 3 🧚. The server figures out that Services 3 and 4 draw from a different account, which is pool 2 🔍. It checks the balance, rates the request using the Service-Ids and Rating-Groups, and then reserves credit from pool 2 🏦.
For example, the server reserves $5 and decides Service 3 costs $0.2/MB while Service 4 costs $0.5/MB 💰. It only authorizes Services 3 and 4 🙌. The CCA it sends back has two Multiple-Services-Credit-Control AVPs (10) 💖. One grants 12.5MB for Service-Id 3 with a multiplier of 2 and Pool-Id 2 🦋. The other grants 5 MB for Service-Id 4 with a multiplier of 5 and Pool-Id 2 💜.
The server also sees that pool 2 is running out, and Service 4 isn't allowed to keep going once those units are used up 💀. So the Final-Unit-Indication AVP with action TERMINATE gets attached to Service-Id 4 🛑. The client works out the total for pool 2 from the quotas and multipliers, which gives S for Pool 2 = 50 🧮.
Then the Validity-Time for the access service expires ⏰. The service element sends a CCR to re-authorize Service-Id (access) (11) 🔁. This one carries a single Multiple-Services-Credit-Control AVP with the units that service used. Say the total used is 4MB 🍰. The client adjusts pool 1 to match, which gives S for Pool 1 = 60 🎀.
Okay so the server deducts $4 from the user's account and bumps the reservation by asking for more credit 💸 It reserves another $5 (so the reservation is now $11) and already knows the Service-Id (access) costs $1/MB 🧮 Then it sends back a Credit-Control-Answer with a Multiple-Services-Credit-Control AVP holding a quota of 5 MB for Service-Id (access), a multiplier of 10, and Pool-Id 1 (12). 🎀 The client updates its total for pool 1 using that quota, which gives S for Pool 1 = 110 ✨
Services 3 and 4 eat up the whole pool 2 credit (that's C1*2 + C2*5 >= S) 😭 The service element immediately kicks off the TERMINATE action for Service 4 🛑 and sends a Credit-Control-Request with CC-Request-Type set to UPDATE_REQUEST to the credit-control server, so Service 3 can get re-authorized (13). This one carries two Multiple-Services-Credit-Control AVPs to report the units used by Services 3 and 4 💅 The server takes the last $5 from the user's account (pool 2) and replies with Result-Code 4011 in the Multiple-Services-Credit-Control AVP, which basically says Service 3 can keep going without credit-control 🦋 (14)
The end user logs off the network (15) 👋 To debit the used units from their account and close out the credit-control session, the service element sends a Diameter Credit-Control-Request with CC-Request-Type set to TERMINATION_REQUEST to the credit-control server (16) 🌸 This message has the units used by each service in multiple Multiple-Services-Credit-Control AVPs, each tied to its Service-Identifier and Rating-Group 💜 The Diameter credit-control server debits those units from the user's account (Pool 1) and confirms the session is over by sending a Diameter Credit-Control-Answer back to the service element (17) 🫶
Authors' Addresses ✨
Harri Hakala
Oy L M Ericsson Ab
Joukahaisenkatu 1
20520 Turku
Finland
Phone: +358 2 265 3722
EMail: Harri.Hakala@ericsson.com
Leena Mattila
Oy L M Ericsson Ab
Joukahaisenkatu 1
20520 Turku
Finland
Phone: +358 2 265 3731
EMail: Leena.Mattila@ericsson.com
Juha-Pekka Koskinen
Nokia Networks
Hatanpaanvaltatie 30
33100 Tampere
Finland
Phone: +358 7180 74027
EMail: juha-pekka.koskinen@nokia.com
Marco Stura
Nokia Networks
Hiomotie 32
00380 Helsinki
Finland
Phone: +358 7180 64308
EMail: marco.stura@nokia.com
John Loughney
Nokia Research Center
Itamerenkatu 11-13
00180 Helsinki
Finland
Phone: +358 50 483 642
EMail: John.Loughney@nokia.comThe squad behind this one: Harri Hakala and Leena Mattila from Oy L M Ericsson Ab, plus Juha-Pekka Koskinen, Marco Stura and John Loughney from Nokia 🧚 Their addresses and contact details are above, exactly as the RFC lists them 💖
Full Copyright Statement 🔥
Copyright (C) The Internet Society (2005) 🌈 This document is covered by the rights, licenses and restrictions in BCP 78, and except where BCP 78 says otherwise, the authors keep all of their rights 📜
This document and the info in it come "AS IS" 🙈 THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 💀
Intellectual Property 🦋
The IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) claimed to cover this technology are valid or how far they reach, or on whether a license for them is available 🤷♀️ It also doesn't claim to have made any independent effort to find such rights. You can read about how RFC documents handle rights in BCP 78 and BCP 79 📚
Copies of IPR disclosures sent to the IETF Secretariat, along with any assurances of licenses that will be made available, or the outcome of any attempt to get a general license or permission to use those proprietary rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔍 Implementers and users of this spec can check there.
The IETF invites anyone who knows of copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to tell them about it 🫶 Send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 🎀
Funding for the RFC Editor function is currently provided by the Internet Society 👑 Thank you, Internet Society ✨
📦 where this page comes from
- ietf: rfc4006 2005-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms