The following table identifies the relationship between the signaling elements and the RADIUS attributes included in Accounting Request messages to the RADIUS server.

Sessions are terminated for reasons that include normal termination, signaling failure, timeout, or network problems. The following table maps RADIUS accounting termination cause codes to network events.

When the SBC routes calls, it performs local policy look-ups that can return several next hops, ordered by preference. This can also happen as a results of an LRT lookup, an ENUM query response, or SIP redirect. To set up sessions, the SBC uses—in ordered preference—and recurses through the list if it encounters failures.

You can configure SIP accounting to send RADIUS Interim records when the SBC encounters these failures. The interim message contains: the destination IP address, the disconnect reason, a timestamp for the failure, and the number that was called. This feature is enabled by setting the generate-interim parameter to unsuccessful-attempt. Please refer to Appendix B to view the format of an unsuccessful-attempt interim record.

You can set up your global SIP configuration so the disconnect time reflected in a RADIUS CDR is the time when the SBC receives a BYE. Enabling this parameter also means the disconnect time is defined when the SBC sends a BYE to the UAS and UAC. Otherwise, the the CDR’s value is based on when the 200 OK confirms the BYE.

The applicable RADIUS CDR in this case is the standard RADIUS attribute Acct-Session-Time, number 46.

An accurate portrayal of a call’s media stop time is important for billing accuracy. Calls are often terminated well after the media has stopped flowing for such reasons as network or equipment peculiarities.

Some accounting features require greater precision. The attribute acct-session-time can be configured to be in milliseconds.

The RADIUS attribute acct-session-time uses seconds as its default. You can set this to a millisecond granularity in the account-config configuration element using the option millisecond-duration. This option setting is required for the RADIUS CDR display, Diameter RF accounting and locally-generated CDR comma separated value (CSV) files behaviors.

When a SIP call is torn down by the SBC due to media timers expiring, the following standard and VSA attributes and their corresponding values will appear in the CDR stop message together:

1. Access the account-config configuration element.

   ORACLE# configure terminal
   ORACLE(configure)# session-router
   ORACLE(session-router)# account-config
   ORACLE(account-config)#
   

2. generate-start—Retain the default value ok if you want the RADIUS Start message to be generated once the SBC receives an OK message in response to an INVITE.

   Other options include:

   • Invite—RADIUS Start message should be generated once the SBC receives a SIP session INVITE.

   • None—RADIUS Start message is not generated.

   • ""—When two quotation marks are entered next to each other (empty), behavior is identical to none value.

3. generate-interim—Retain the default value reinvite response to cause the SBC to transmit a RADIUS Interim message. (A RADIUS Interim message indicates to the accounting server that the SIP session parameters have changed.)
   You can select none, one, or more than one of the following values:

   • ok—RADIUS Start message is generated when the SBC receives an OK message in response to an INVITE.
   • reinvite—RADIUS Interim message is generated when the SBC receives a SIP session reINVITE message.
   • reinvite response (default)—RADIUS Interim message is generated when the SBC receives a SIP session reINVITE and responds to it (for example, session connection or failure).
   • reinvite cancel—RADIUS Interim message is generated when the SBC receives a SIP session reINVITE, and the Reinvite is cancelled before the SBC responds to it.
   • unsuccessful-attempt—RADIUS Interim message is generated when a SIP session set-up attempt from a preference-ordered list of next-hop destinations is unsuccessful. This can happen when a local policy lookup, LRT lookup, ENUM query response, or SIP redirect returns a preference-ordered list of next-hop destinations. The interim message contains: the destination IP address, the disconnect reason, a timestamp for the failure, and the number that was called.
4. intermediate-period—Set the time in seconds between generating periodic interim records. This parameter defaults to zero, which is not a valid value.

   Interim record generation for each call type is as follows:

   • H.323—The periodic timer (set to the value you specify in the accounting configuration) is dynamically created when the SBC receives a Connect message and an H.323 call answer method is invoked. The SBC deletes the timer when the H.323 session is terminated.
   • SIP—The periodic timer (set to the value you specify in the accounting configuration) is dynamically created when the SBC receives an initial INVITE message. The SBC deletes the timer when the session is terminated.
5. Type done to save your configuration.

The SIP enhanced-cdr option enables consistent generation of RADIUS Stop records on both ingress and egress paths. With enhanced-cdr enabled, RADIUS Stop records are generated in response to any ingress path rejection of a dialog creating SIP INVITE request. The contents of RADIUS Stop records are also written to the local CDR files (if enabled).

Use the following command syntax to enable consistent generation of RADIUS Stop records.

ORACLE(sip-config)# options +enhanced-cdr
ORACLE(sip-config)#

In legacy releases there was an inconsistency in the generation of RADIUS Stop records when calls are rejected for exceeding configured session ingress or egress constraints. On the egress path, legacy releases rejected such calls with a 503 (Service Unavailable) response and the generation of a RADIUS STOP record. On the ingress path, however, while calls were rejected with a 503 response, RADIUS Stop records were not generated.

You can configure the SBC to add fully compliant P-Visited Network Identifier (PVNI) and History-Info (HI) headers in CDRs. You configure this by adding the pcscf-cdr-compliance option to the account-config, specifying whether you want to include PVNI (PVNI-pref), HI (HI-pref), or both. The behavior is dependent on the type of call, including Mobile Terminating (MT) and Mobile Originating (MO), information provided by SIP, and whether you are also using an S8HR profile.

The PVNI and HI fields in CDRs may or may not contain data. When configured, the SBC performs processes to determine whether or not to add:

• P-Visited-Network-ID to the applicable CDR field
• History-Info to the applicable CDR field

You configure the pcscf-cdr-compliance in the applicable account-config to use these processes within your environment.

ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# account-config
ORACLE(account-config)# select
ORACLE(account-config)# options +pcscf-cdr-compliance=PVNI-pref

If you save and activate this configuration, the SBC enables PVNI CDR population for MT calls. To configure for both PVNI and HI headers, configure the option with both values separated by a comma and enclosed in quotes.

ORACLE(account-config)# options +pcscf-cdr-compliance="PVNI-pref,HI-pref"

<sip:bob@example.com>;index=1, <sip:office@example.com>;index=1.2;mp=1, <sip:office@192.0.2.5>;index= 1.2.1;rc=1.2

You can configure the SBC to include reason header AVPs in diameter STOP and EVENT CDRs within the context of a configured account-config. When configured, the SBC does this for both cause information it receives from another device and for cause information the system generates itself. To do this, you enable the add-reason-header parameter in the sip-config. When enabled, the SBC includes the Reason-Header AVP in Diameter Accounting Request (ACRs) for Accounting-Record-Type [STOP/EVENT] CDRs per spec 3GPP TS 32.299 V13.5.0 for both in-dialog and out-of-dialog messages. This is in addition to the parameter's other functions, including adding the SIP reason header to BYE, CANCEL, and SIP Error Responses (4xx, 5xx, 6xx). You can customize the text used in reason headers using the local-error parameters in the local-response-map that you apply to your target traffic.

The system checks incoming BYE, CANCEL, and SIP Error Responses (4xx, 5xx, 6xx) for reason headers to propagate using either default or customized messaging you have specified in your local response map. These headers would be presented as Q.850 cause and text information. If the incoming message does not include reason headers, the SBC does not insert a reason header AVP in the ACR or a reason header in the ensuing signaling. If it receives multiple reason-headers, the system adds them all in both AVP and the signaling. If the SBC does not have a customized or default mapping for a SIP error code, it maps that code to the q850CauseTypeInternalError (47).

In addition to reason header propagation, the SBC generates reason headers based on issues it identifies itself. These would usually be 6xx responses. For these situations, the SBC also includes the reason-header AVP for CDRs and SIP error messages for egress. The system uses the default or customized messaging configured in the local-response-map for its own reason headers.

To create reason headers, the SBC concatenates the q.850-cause and q.850-reason. A formatted example of a SIP reason-header follows.

Q.850;cause=16;text="Call Terminated"

See Configure Reason and Cause Mapping for SIP-SIP Calls for instructions on configuring a local-response-map, including the local-error parameters and the add-reason-header parameter.

ORACLE# sh running-config local-response-map
local-response-map
entries
local-error       not-acceptable-here-488
sip-status        488
q850-cause        65
sip-reason
q850-reason       Not Acceptable Here

Reason: Q.850;cause=65;text="Not Acceptable Here"

ORACLE# sh running-config local-response-map
local-response-map
entries
local-error       sip-locally-generated-bye
sip-status        
q850-cause        16
sip-reason
q850-reason       Bye Call Terminated

Reason: Q.850;cause=16;text="Bye Call Terminated"

Reason: Q.850;cause=16;text="Call Terminated"

1. Access the realm-config configuration element.

   ORACLE# configure terminal
   ORACLE(configure)# media-manager
   ORACLE(media-manager)# realm-config
   ORACLE(realm-config)# 

2. Select the realm-config object to edit.

   ORACLE(realm-config)# select
   identifier:
   1: realm01 left-left:0 0.0.0.0
   
   selection: 1
   ORACLE(realm-config)#

3. accounting-enable—Either leave this parameter set to enabled (default) to generate CDRs for this realm, or change it to disabled.
4. Type done to save your configuration.

1. Access the account-config configuration element.

   ORACLE# configure terminal
   ORACLE(configure)# session-router
   ORACLE(session-router)# account-config
   ORACLE(account-config)#
   

2. Type select to begin configuring this object.
3. prevent-duplicate-attrs—Enable this parameter to prevent the SBC from duplicating attributes in the accounting records it generates. This duplication can be caused, for example, by multiple media sessions within the context of a call. Retaining the default (disabled) allows the SBC to include duplicate attributes in RADIUS, Diameter and Local accounting records. This can result in attribute placement and counts that are less consistent.
4. Save and activate your configuration.

1. Access the account-config configuration element.

   ORACLE# configure terminal
   ORACLE(configure)# session-router
   ORACLE(session-router)# account-config
   ORACLE(account-config)#
   

2. Type select to begin configuring this object.
3. vsa-id-range—Enter a comma-delimited list that represents the VSA you want to appear in the RADIUS CDR. There is no default for this parameter.

   Do not use <Spaces> when typing in your comma-delimited list.

   ORACLE(account-config)# vsa-id-range -5,7,10-

   This entry specifies that CDRs contain VSA with identifiers equal to and less than 5, VSA 7, and VSAs with identifiers equal to and greater than 10.

   Limit this list to accounting VSAs. For example, VSA 254 is an authentication VSA, so it should not be included in the range. The system generates validate-config errors if your range includes VSAs that are not accounting VSAs.

4. Save and activate your configuration.

The SBC reserves VSAs 200-229 for you to define for use with SIP calls. These VSAs should never be used for other purposes, and their use should never conflict with the need to add new VSAs in the future. Because this leaves a significant number of VSAs unused, there is still ample space for any new VSAs that might be required.

Since RADIUS START records are created on session initiation, their content cannot be updated. However, the content for INTERIM and STOP records can be.

To configure user-defined VSAs for a SIP call, you use HMR. For example, when you set up HMR correctly, the SBC reports originating or terminating country codes in CDRs in whatever format they appear in the SIP username field. The HMR rules you configure uses the SIP header name P-Acme-VSA, adding it to the SIP header from any part of the SIP message. Then the SBC searches for the P-Acme-VSA header, generates a VSA for it, and then includes that VSA in the CDR for the call.

You can include multiple custom VSAs per CDR by adding the corresponding number of rules; in essence, you add in the header as many times as required.

You can force the SBC to generate VSAs related to trunk groups even when you are not using the trunk group feature. With the force-report-trunk-info parameter turned on in the session router configuration:

• The SBC reports terminating trunk group and trunk-context information even though it has not perform trunk-group routing.

  The appropriate VSAs report the terminating trunk-group (VSA 65) and trunk context (VSA 67) with the information of the matching ingress session agent and realm of the originator.

• The SBC reports the terminating trunk-group (VSA 66) and trunk context (VSA 68) as the received trunk group and context from the call’s SIP REQUEST message. If the SIP message has none, then the SBC uses the information from the matching egress session agent (or egress realm, when available) and next-hop realm.

  Note that information is reported after HMR processing—meaning that header manipulation has been performed on the message information reported.