AVP CDRs have logical content, and an on-disk format.
Logical content
Each CDR inside a CDR file has logical content. We use a BNF syntax to describe this logical content.
CDR ::=
[ Subscription-Id ]
[ IMS-Information ]
[ User-Equipment-Info ]
*[ Multiple-Services-Credit-Control ]
[ OC-Call-Type ]
[ OC-Service-Type ]
[ OC-Charging-Result ]
*[ OC-OCS-Session-Id ]
[ OC-OCS-Session-Termination-Cause ]
[ OC-Sentinel-Error ]
*[ OC-Charging-Instance ]
[ OC-Event-Id ]
[ OC-Call-Id ]
[ OC-End-Session-Cause ]
[ OC-Session-Start-Time ]
[ OC-Session-Established-Time ]
[ OC-Session-End-Time ]
[ OC-Selection-Key ]
[ OC-Plan-Id ]
[ OC-Submit-Report-Type ]
[ OC-Correlated-Id ]
[ OC-MT-PS-Delivery-Result ]
[ OC-MT-CS-Delivery-Result ]
[ OC-IMPU ]
[ SMS-Information ]
*[ AVP ]
Logically this means that an individual CDR has optional content. It may have zero or one Subscription-Id AVP, zero or one IMS-Information AVP, and so-on. It may have zero or more OC-OCS-Session-Id AVPs, and so-on.
A CDR inside the CDR file is not an AVP. It is a protobuf record, and as such may contain additional "root" AVPs. So, for example an application may use the format, but add a LCS-Information AVP, or custom AVP.
You could consider each CDR to be roughly equivalent to the Service-Information AVP, yet more flexible/extensible regarding its content. This is because the Service-Information AVP is essentially closed for extension by non-3GPP groups.
To view the population of AVPs in use, refer to Charging Content AVPs
On disk format
AVP CDRs are written using Google protocol buffers (protobuf).
An AVP CDR file has a protobuf schema. This schema allows any AVP to be written to a CDR.
package com.opencloud.cdrformat;
// AVP based CDR
message AvpCdr {
repeated AVP avps = 1;
message AVP {
required bytes avpData = 1; // The Diameter binary encoded AVP data
required string interfaceName = 2; // The interface which the AVP is being written out as, e.g "Rf", "Ro"
required string specRevision = 3; // E.g. "vcb0"
optional string avpName = 4;
}
}
