Diameter Accounting

The OCSBC supports the Diameter charging interface, Rf. This interface provides similar functionality to the RADIUS interface, but utilizes Diameter as the underlying application layer protocol. As a result, the OCSBC can integrate more thoroughly with IMS standards as well as provide a more dynamic, secure, and robust accounting interface.

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 OCSBC 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 OCSBC does not receive the ACA after the user-specified number of retries, then the OCSBC 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.
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 OCSBC 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

ACR AVP Descriptions

This section provides individual AVP descriptions.

Session-Id AVP (263)

Uniquely identifies this session. It is a string value and is delimited by semi-colons. This AVP is created according to the Session-Id AVP (AVP Code 263) specified in IETF RFC 3588. An example of a Session-Id from the OCSBC is as follows, acmesystem;0;1.

Origin-Host AVP (264)

Contains the account-server configuration element’s hostname parameter followed by the "@" character, followed by the account-server configuration element’s origin-realm parameter. For example: acmesystem@wancom.com.

Origin-Realm AVP (296)

Contains the account server configuration element’s origin-realm and domain-name-suffix parameters where the server request is sent.

Destination-Realm AVP (283)

Contains the value of the Origin-Realm AVP in the CEA received from the accounting server for this connection.

Destination-Host AVP (293)

Contains the value of the Origin-Host AVP in the CEA received from the accounting server for this connection.

Accounting-Record-Type AVP (480)

Contains the value indicating the type of accounting message being sent.

event record = 1
start record = 2
interim record = 3
stop record = 4

Accounting-Record-Number AVP (485)

A value that uniquely identifies this message in the session (i.e., a sequence number for this connection). The sequence number is assigned sequentially starting with 0 as described below. This is compliant with RFC 3588. The combination of the Accounting-Record-Number AVP and the Session-Id AVP (both of which are unique for the given session) are used to match accounting records with confirmations. This is done by assigning the noted values to the records listed below:

Event Record — the system assigns this record a value of 0 to this record.
Start Record — the system assigns this record a value of 0 to this record.
Interim Record — the system assigns this record a value of 1 to the first record of this type for the session, and increments the value by 1 for each subsequent Interim_record until the value for the Stop_record is more for the last Interim_record for the session.
Stop Record — (see description for Interim_record in the previous bullet) — If there is no Interim_record for the session, the system assigns a value to this record of 1.

The following example call flow shows a Register Event that shows that the Event record in the Accounting-Record-Number AVP is always populated with 0.

The Register Event Event Record in the Accounting-Record-Number AVP is described above.

The following example call flow shows session accounting messages with no Interim records. Note that the Start Accounting-Record-Number equals 0 and the Stop Accounting-Record-Number equals 1.

The session accounting messages with no interim records call flow is described above.

Call Flow Example Showing Session Accounting Messages with No Interim Records

The following example call flow shows session accounting messages with Interim records. Note that the Start record Accounting-Record-Number equals 0 and that the Interim Accounting-Record-Numbers start with a value of 1 and increase by 1 with the second Interim record. The Stop Accounting-Record-Number equals 3.

The Session Accounting Messages with Interim Records call flow is described above.

Call Flow Example Showing Session Accounting Messages with Interim Records

Acct-Application-Id AVP (259)

Set to value "3". This value indicates Diameter-based accounting messages.

User-Name AVP (1)

Event-Timestamp AVP (55)

Contains the number of seconds since January 1, 1900 when this accounting event took place.

Event-Type AVP (823)

A grouped AVP containing information about the signaling event. It contains the following AVPs:

SIP-Method AVP (824)—Contains the exact string payload from the SIP request line; i.e., the Method that triggered the accounting event.
Content-Type AVP (826)—Contains the exact string payload from the "Content-Type" SIP header of the message that triggered the accounting event.
Content-Length AVP (827)—Contains the exact string payload from the Content-Length" SIP header of the message that triggered the accounting event.

Role-of-Node AVP (829)

Set to the value 2 which indicates that the OCSBC is operating in a PROXY role.

User-Session-Id AVP (830)

Contains VSA 44 as used in the RADIUS interface.

Calling-Party-Address AVP (831)

The Calling-Party-Address AVP (AVP code 831) is of type UTF8String and holds the address (SIP URI or TEL URI) which identifies the party (Public User Identity or Public Service Identity) initiating a SIP transaction. . It is obtained from the P-Asserted-Identity header of any non-REGISTER SIP Request, either initiating a dialog or a standalone transaction. This AVP may appear several times when the P-Asserted-Identity header contains both a SIP URI and a TEL URI. In case no P-Asserted-Identity is known, this AVP list shall include one item with the value "unknown".

Called-Party-Address AVP (832)

The Called-Party-Address AVP (AVP code 832) is of type UTF8String. In IMS charging (except for SIP Register and SIP Subscription transactions), it holds the address (SIP URI, TEL URI or URN) of the party (Public User ID or Public Service ID) to whom the SIP transaction is posted. The Called Party Address shall be populated with the SIP URI or TEL URI contained in the Request-URI of the outgoing request.

For a registration procedure, this field holds the party (Public User ID) to be registered. In this case, the Called Party Address field is obtained from the To SIP header of the SIP Request. For a subscription procedure this field holds the address of the resource for which the originator wants to receive notifications of change of states. In this case, the Called Party Address field is obtained from the outgoing Request-URI of the SIP Request.

Time-Stamps AVP (833)

A grouped AVP that contains timestamps for the related SIP signaling. It contains the following AVPs.

SIP-Request-Timestamp AVP (834)—A UTC formatted timestamp that corresponds to when the SIP INVITE that started the session was received.
SIP-Response-Timestamp AVP (835)—A UTC formatted timestamp that corresponds to when the SIP 200 OK response to the INVITE that started the session was received.

Inter-Operator-Identifier AVP (838)

A grouped AVP that indicates the ingress and egress networks from the OCSBC’s perspective. It contains the following AVPs.

Originating-IOI AVP (839)—The realm where the OCSBC received the SIP signaling messages.
Terminated-IOI AVP (840)—The realm where the SIP signaling message exit the OCSBC.

SDP-Session-Description AVP (842)

This AVP may occur multiple times in an ACR message. It is populated with SDP attribute-lines from the SIP messages to which this ACR Stop message refers. Thus, all "i=", "c=", "b=", "k=", "a=", etc.., lines comprise multiple instances of this AVP.

If the OCSBC is configured to generate Start events on the INVITE, the calling SDP will be used; if the OCSBC is configured to generate Start events on the OK, the called SDP will be used. ONLY IN ACR Start.

Session-Media-Component AVP (845)

A grouped AVP that contains information about the media session. It contains the following AVPs. ONLY IN ACR Start.

SDP-Media-Name AVP (844)—populated with the "m=" line from the SDP being used.
SDP-Media-Description AVP (845)—this AVP may occur multiple times in this grouped AVP. It is populated with SDP attribute-lines from the media component as specified by the media described in the SDP-Media-Name AVP. Thus, all "i=", "c=", "b=", "k=", "a=", etc..., lines related to the above specified "m=" line comprise multiple instances of this AVP.

Cause AVP (860)

A grouped AVP that contains the reason for the termination event and the role/function of the node where the call was terminated. It contains the following AVPs.

Cause-Code AVP (861)—See Values for Cause Code AVP (861) below.
Node-Functionality AVP (862)—Set to value 0.

Values for Cause Code AVP (861)

As described in 3GPP TS32.229, the Cause-Code AVP 861 includes the cause code value sent by the IMS node. It is used in stop and/or event messages.

If the session terminated as a result of a specific known SIP error code, the SIP error code is used as the cause code value. Otherwise, cause code values less than or equal to 0 are used for successful causes while values greater than or equal to 1 are used for failure causes.

Cause code value set to 0 — indicates "Normal end of session" and is used in Accounting-request[stop] message to indicate that an ongoing SIP session has been normally released either by the user or by the network (SIP BYE message initiated by the user or initiated by the network has been received by the IMS node after the reception of the SIP ACK message).
Cause code value set to "2xx Final Response" (except 200) — used when the SIP transaction is terminated due to an IMS node receiving/initiating a 2xx Final response.
Cause code value set to "2xx Final Redirection"— used when the SIP transaction is terminated due to an IMS node receiving/initiating a 3xx response.
Cause code value set to "1"— indicates "Unspecified error" and is used when the SIP transaction is terminated due to an unknown error.
Cause code value set to "4xx Request failure"— used when the SIP transaction is terminated due to an IMS node receiving/initiating a 4xx error response.
Cause code value set to "5xx Server failure"— used when the SIP transaction is terminated due to an IMS node receiving/initiating a 5xx error response.
Cause code value set to "6xx Global failure"— used when the SIP transaction is terminated due to an IMS node receiving/initiating a 6xx error response.
Cause code value set to "Unsuccessful session setup"— used in the Accounting-request[stop] when the SIP session has not been successfully established (i.e. Timer H expires and SIP ACK is not received or SIP BYE is received after reception of the 200OK final response and SIP ACK is not received).
Cause code value set to "Internal error"— used when the SIP transaction is terminated due to an IMS node internal error (e.g. error in processing a request/response).