Built-in AVPs and extension AVPs
The binary CDR format contains Diameter AVPs encoded in binary form, and the List CDRs tool decodes these binary AVPs before printing them in a human readable format.
The tool has built-in knowledge of AVPs which are defined in Diameter protocols such as Rf and Ro.
It can also be customized with knowledge of user defined extension AVPs, by providing definitions of those AVPs in YAML files.
The List CDRs tool looks in the list-cdrs/extension-avps
directory for YAML based files
which define these extension AVPs.
A default installation of the List CDRs tool contains a DiameterExtension-AVP.yaml
file inside
this directory, which defines OpenCloud’s extension AVPs.
This means that by default, the List CDRs tool recognizes all the AVPs in the CDR files produced by Sentinel.
Known AVPs vs Undefined AVPs
When encountering an AVP which it does not recognize, the List CDRs tool treats it as an Undefined AVP.
Because the tool can’t see which type of AVP it is (e.g. UTF8String
or Integer32
), it
prints the raw binary content of the AVP in hexadecimal format.
This is how the List CDRs tool will print an extension AVP that it doesn’t recognize:
Undefined-AVP[code=1029,vendor=19808,hex=64 61 4a 76 69 5f 64 4e 69 65 5f 57 5f 76 2d 66 7a 44 4f 66 6c 67,ascii=daJvi_dNie_W_v-fzDOflg],
This is how the List CDRs tool prints that same extension AVP, when that AVP is configured as an extension AVP (see below):
OC-Call-Id[daJvi_dNie_W_v-fzDOflg],
Built-in extension AVPs
This is an excerpt from the default extension AVP configuration file at
list-cdrs/extension-avps/DiameterExtension-AVP.yaml
, showing the first two extension AVPs:
$ cat extension-avps/DiameterExtension-AVP.yaml !profiles DiameterExtension-AVP: id: name: 'Diameter Extension AVP' vendor: 'OpenCloud' version: '2.7' imports: null profiles: ? '' : AvpCode: 0 AvpName: null AvpType: null MandatoryRule: 1 ProtectedRule: 1 VendorId: 0 OC-Sentinel-Selection-Key: AvpCode: 1001 AvpName: OC-Sentinel-Selection-Key AvpType: UTF8String MandatoryRule: 0 ProtectedRule: 0 VendorId: 19808 OC-Play-Announcement-Id: AvpCode: 1002 AvpName: OC-Play-Announcement-Id AvpType: Integer32 MandatoryRule: 0 ProtectedRule: 0 VendorId: 19808 [...]
Customisation of extension AVPs
To configure your own custom AVP, add a new file with the same opening structure as
extension-avps/DiameterExtension-AVP.yaml
, but with your own extensions.
Be sure to use your own Vendor ID, which we’ll assume to be 19404 below for the sake of example.
|
An example configuration file:
$ cat extension-avps/ACME-DiameterExtension-AVP.yaml !profiles DiameterExtension-AVP: id: name: 'Diameter Extension AVP' vendor: 'OpenCloud' version: '2.7' imports: null profiles: ? '' : AvpCode: 0 AvpName: null AvpType: null MandatoryRule: 1 ProtectedRule: 1 VendorId: 0 ACME-My-First-Custom-Code: AvpCode: 1000 AvpName: ACME-My-First-Custom-Code AvpType: UTF8String MandatoryRule: 0 ProtectedRule: 0 VendorId: 19404 ACME-My-Second-Custom-Code: AvpCode: 1000 AvpName: ACME-My-Second-Custom-Code AvpType: UTF8String MandatoryRule: 0 ProtectedRule: 0 VendorId: 19404 [...]
After you have created such a file you will also have to add the AVP names to
the Charging
profile in the DiameterExtensions
profile table, which lives
in the file extension-avps/DiameterExtensions.yaml
.
The profile consists of an array that lists all of the desired AVPs in the
format <profile table name>/<profile name>
.
So for the two AVPs from the example above you would have to add these two
lines to the Charging
profile:
- DiameterExtension-AVP/ACME-My-First-Custom-Code - DiameterExtension-AVP/ACME-My-Second-Custom-Code
Note that the profile to use for the supported extension AVP list is
configured with the ExtensionAvpSet
property of the Diameter RA.
See
Configuring Extension AVPs for the full documentation of these profile tables.
The required fields for each AVP:
- AvpCode
-
The code of the AVP. If using your own vendor code, then this AVP code is within your own namespace.
- AvpName
-
The name of the AVP.
- AvpType
-
The type of the AVP. See the available AVP types below.
- MandatoryRule
-
The "M" bit or Mandatory bit.
1
if set,0
if not set. Indicates whether support of the AVP is mandatory on the receiving end. - ProtectedRule
-
The "P" bit, indicating the need for encryption.
1
if set,0
if not set. - VendorId
-
The Vendor ID of the company which has defined this AVP.
- The available AVP types
-
-
OctetString
-
Integer32
-
Integer64
-
Unsigned32
-
Unsigned64
-
Float32
-
Float64
-
Grouped
-
Address
-
Time
-
UTF8String
-
DiameterIdentity
-
DiameterURI
-
Enumerated
-
IPFilterRule
-
QoSFilterRule
-
Undefined
-