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.

Note 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

Previous page Next page
Sentinel VoLTE Version 2.7.0