1. Accounting Guide
  2. Diameter Accounting
  3. Diameter Accounting Messages

Diameter Accounting Messages

The Rf interface can send messages based on the signaling application’s actions. These messages are Accounting Charging Request (ACR) Start messages, ACR Stop messages, Event messages and Interim messages.

Resending ACRs

  • If an ACA is not received to acknowledge the reception of an ACR, the SBC attempts to resend an ACR and buffers all subsequent ACRs for the same session until the acknowledgement is received. Once the acknowledgement is received from the CCF, all buffered ACRs for that same session may be sent to the CCF in the appropriate order. If the SBC does not receive the ACA after the user-specified number of retries, then the SBC sends all of the buffered ACR records for a session to the secondary CCF. (The number of ACR retries as well as the wait time in between retries is configurable by using the max-acr-retries account configuration parameters and acr-retry-interval, respectively.)

Postponement Feature

  • Any number of ACRs can be sent during a session, including Start, Stop, Interim and ACR messages. The ACR postponement feature (non-configurable) ensures that the next ACR is not sent until the previous ACR is acknowledged with an ACA.

Call Flow Examples

  • The following call flow example shows success in receiving an ACA for a session after resending the ACR message three times.
  • The ACA receipt call flow shows the CCF successfully send the ACA to the SBC after three retries, resulting in a connection.

    Successful ACA Acknowledgement After Three Retries

The following call flow example shows the failure to receive an ACA for a session after sending the ACR message three times.

The ACR Failure Message call flow shows the CCF failing to send the ACA to the SBC after three retries, resulting in a disconnect.

Unsuccessful ACA Acknowledgement After Three Retries

The following call flow example shows how the delay of the ACA acknowledgement for a session results in a postponement until the ACA is finally received. During the postponement, the ACRs are buffered until the correponding ACA is received. If an ACR for one session is postponed, it does not delay the other session’s ACRs.

The ACA Acknowledgement Delay call flow is described in the paragraph above.

Call Flow Showing Delivery Postponement

  • Additional ACR Interim messages are sent when service changes; this roughly maps to a RADIUS Interim-Update message. See Accounting-Record-Type AVP (480).
  • ACR Stop messages are sent at the end of service delivery.

The SBC sends a set of AVPs in each ACR start and stop message that make up the charging data. The following table lists which AVPs are included in ACR Start and ACR Stop messages. Individual AVP descriptions are located in the following section.

AVP ACR Start ACR Stop
Session-Id AVP (263) X X
Origin-Host AVP (264) X X
Origin-Realm AVP (296) X X
Destination-Realm AVP (283) X X
Destination-Host AVP (293) X X
Accounting-Record-Type AVP (480) X X
Accounting-Record-Number AVP (485) X X
Acct-Application-Id AVP (259) X X
User-Name AVP (1) X X
Event-Timestamp AVP (55) X X
Event-Type AVP (823)

SIP-Method AVP (824)

Content-Type AVP (826)

Content-Length AVP (827)

X X
Role-of-Node AVP (829) X X
User-Session-Id AVP (830) X X
Calling-Party-Address AVP (831) X N/A
Called-Party-Address AVP (832) X N/A
Time-Stamps AVP (833)

SIP-Request-Timestamp AVP (834)

SIP-Response-Timestamp AVP (835)

X X
Inter-Operator-Identifier AVP (838)

Originating-IOI AVP (839)

Terminated-IOI AVP (840)

X X
SDP-Session-Description AVP (842) X N/A
Session-Media-Component AVP (845)

SDP-Media-Name AVP (844)

SDP-Media-Description AVP (845)

X N/A
Cause AVP (860)

Cause-Code AVP (861)

Node-Functionality AVP (862)

N/A X