Local CDR Storage and FTP Push

Local CDR File Format

The CDRs are written as comma-delimited ASCII records to files on the SBC. The types of records are controlled by the same accounting configuration parameters used for RADIUS. The fields of the comma-delimited entries correspond to RADIUS START, INTERIM, and STOP records. Using the accounting configuration, you can configure the SBC to record STOP records only.

Because the record types do not have consistent field positioning, any server parsing them would need to read the first field to determine the type and learn how to parse the remaining fields.

Local CDR File Format Consistency

Unpopulated or unused fields in the RADIUS CDR are omitted from the locally-stored CSV file. This means that there is no fixed position for a RADIUS attribute across all CSV files. Instead, the missing values are skipped in the CSV file so that the order and appearance for attribute values can differ from record to record.

You can guarantee the placement of attributes in local CDR files with the cdr-output-inclusive parameter. With this enhancement enabled, RADIUS records sent to a RADIUS client contain even empty attributes with an integer, date and time, or IP address format; the default value is zero. In other words, when there is no value to report:

An IP address attribute will report as 0.0.0.0
A date and time attribute will report as 00:00:00.000 UTC Jan 01 1970
An integer attribute value will report as 0

To maintain RFC 2865 and 2866 compliance, the Oracle Communications Session Border Controller will not send empty attributes that are string values to a RADIUS client. And when you enable this feature, the Oracle Communications Session Border Controller adds all attributes to the local CDR file.

Masking local CDR fields

The content in local CDR files can also be controlled by using the RADIUS Attribute Selection feature. This lets you exclude call data fields from local CDR files.

Decoding Local CDR File Contents

The Local CDR File contents do not follow a standard CSV file format.

Fields in that are strings are enclosed in double quotes ("). Each string may contain commas, double quotes, and other similar characters that are not escaped.
If a comma is part of a string already within double quotes, it will be replaced with a space character to avoid parsing failure.
When you parse a CDR entry, the end will be indicated by a comma character after an even number of double quotes.

1,"<sip:0322911111@10.200.200.30:5066>;reason="unconditional",<sip:0322917676@10.200.200.30:5066>;reason="alias"",0,0,112

Double Quote handling within Strings

If a double quote is part of a string already within double quotes, a second double quote can be added to avoid parsing failure. This is accomplished by adding the escape-double-quotes option in the account-config .

With double quotes enabled


ORACLE(account-config)# options +escape-double-quotes

For example, with the escape-double-quotes options enabled:

/AfX8503412290""bcGhEfJeKqB0e@example.com

For example, without the escape-double-quotes options enabled:

/AfX8503412290"bcGhEfJeKqB0e@example.com

Generate Local CDR Layout Files

Numerous factors determine the layout of local CDR files. In order to obtain an accurate local CDR layout, the SBC can write a special CDR layout file that only includes the data layout for your local CDRs based on your configuration. You can then use this file to interpret local CDR files with the proper data field order, source and identification label.

You can configure the system to produce CDR layout files with the dump_csv_format command at the superuser prompt.

ORACLE# dump_csv_format

This function uses the same process, input and output mechanisms the system uses to produce local CDRs. While this command is activated, the system produces layout files instead of actual CDRs. After the layout files have been created, turn the generation feature off with the no_dump_csv_format command.

Format files are written to the same directory as local CDR files, and they use the same naming convention as local CDR files. Refer to local CDR generation instructions to identify the files you intend to retrieve, based on your configuration for rotation, naming, file size, and so forth.

Preform this procedure in a maintenance window. Limit your sample calls to a single successful, and depending on your configuration, single unsuccessful call. The following is the general procedure used to capture local CDR layout files.

Turn on dump_csv_format from the system's enable prompt. The system stops generating local CDR files, generating local CDR format files instead.
Place a successful call.
Complete the call.
If you are configured for INTERIM generation upon an unsuccessful call, place an unsuccessful call.
Depending on your configuration, identify the file that has the format. For example, if using rotation you may decide to wait for the data to rotate from the temp file to be sure the file is closed.
Retrieve the layout file from the local CDR directory.
Turn off the feature using no_dump_csv_format. The system begins to generate local CDR files again.
Use the files to identify your CDR format and establish your collection and collation process.

Local CDR Layout File Reference and Example

The first line of every record contains the following comma-delimited information:

"1", "Accounting Status", ,"40",["## START ##" | "## INTERIM ##" | "##STOP##"]

Each line after the initial line of each record contains the following comma-delimited information:

<CDR Attribute position>,<CDR Attribute Name>,<VSA Vendor>,<VSA Number>

The CDR Attribute name only presents the shorthand of the attribute. Cross-reference the VSA number with the RADIUS dictionary to obtain the full VSA name.

The following is an example of the first 10 rows of a CDR Layout file, start record.

1,"Accounting Status",,40,## START ##
2,"NAS IP Address",,4
3,"NAS Port",,5
4,"Accounting Session ID",,44
5,"Ingress Session ID",ACME,3
6,"Egress Session ID",ACME,4
7,"Session Protocol Type",ACME,43
8,"Session-Forked-Call-Id",ACME,171
9,"Generic ID",ACME,40
10,"Calling Station ID",,31

Requirements

If you want to guarantee the CSV placement for RADIUS attribute values, you must use the entire RADIUS dictionary. You cannot use the RADIUS CDR abbreviation feature. Using an abbreviated form of the RADIUS dictionary results in adverse effects for the CSV file.

In your configuration, then, you must set the vsa-id-range parameter to use the entire range of attributes. Leaving this parameter blank disables abbreviation and all attributes are included. Alternatively, you can specify all of the parameters (by attribute number) that are used in the OS release loaded on your system.

See the RADIUS CDR Content Control section for more information.

Local CDR File Naming Convention

The SBC creates filenames from the timestamp that the CDR file is opened for writing. The format is cdrYYYYMMDDHHMM[a-j], where:

YYYY=the year
MM=the month
DD=the day
HH=the hour
MM=the minute
[a-j]=a suffix that provides additional discrimination in case of changing system time, setting the rotation time for this feature to one minute, or in case of another occurrence that might compromise the date and time

Your file name will resemble the following sample: cdr200511151200.

Temporary File Naming for an Open CDR File

Before this release was introduced, the SBC used the same naming format for all CDR files: cdrYYYYMMDDHHMM[a-j]. If this is the naming convention you still want to use, you can do so simply by This mode offers no means of differentiating a file to which the SBC is writing information from any other closed file(s).

Open local CDR files have a temp- prefix added to the file name. The prefix helps you differentiate the file that is currently open from the other CDR files. As soon as the file is closed during rotation, the temp- prefix is removed.

You can revert to legacy behavior that omits the temp- prefix on open files by adding the disable-temp-file option to your accounting configuration.

ORACLE(account-config)# options +disable-temp-file

Operational Details

This section offers details of SBC operations that effect temporary CDR file naming.

Reboot—A system reboot can happen unexpectedly, or might be caused by your intentionally rebooting the system using the ACLI reboot command. When a reboot occurs, SBC closes the CDR file that was most recently opened (before the reboot) and names it according to the cdrYYYYMMDDHHMM[a-j] convention. It also opens a new file, which bears the temp- differentiation.
Activating a configuration—If temporary CDR naming is enabled before and after you use the activate-config command, then the last opened file will be closed and have the cdrYYYYMMDDHHMM[a-j] name format. The SBC also opens a new file with the temp- prefix to which it will write data.
In the case where temporary CDR naming is enabled before you activate a configuration and disabled after it, the last open file is named according to the cdrYYYYMMDDHHMM[a-j] name format. The new file to which the SBC will write data is also in the cdrYYYYMMDDHHMM[a-j] name format. In other words, the SBC does not use the temp- prefix designation at all.

In the case where temporary CDR naming is disabled before you activate a configuration and enabled after it, the SBC closes the most recently opened file—which must have been in the cdrYYYYMMDDHHMM[a-j] name format. The SBC also opens a new file with the temp- prefix to which it will write data.
Changing the accounting configuration’s administrative state—When you disable the accounting configuration, the SBC renames the most recently opened file with the temp- prefix to the cdrYYYYMMDDHHMM[a-j] name format.

HA Considerations for CDR Output Redundancy

The considerations in this section describes the Oracle Communications Session Border Controller’s behavior when CDR output redundancy is enabled or disabled. You set CDR output redundancy in the accounting configurations cdr-output-redundancy parameter.

Enabled—When you enable CDR output redundancy, both the Active and Standby systems rotate files. During CDR file rotation, if either the Active or the Standby rotates a file with the temp- prefix, the prefix disappears and the file name appears in the cdrYYYYMMDDHHMM[a-j] name format.
The Active and the Standby systems always have the same files, including the CDR file with the temp- prefix. So the file exists on both systems.
Disabled—When you have disables CDR output redundancy and switchover happens for any reason, it is key that there are no residual files with the temp- prefix. For this reason, the SBC handles the situation as follows:
Becoming Active—When it transitions from Standby to Active, a SBC checks for any files with the temp- prefix, closes the file if it is open, and renames it according to the cdrYYYYMMDDHHMM[a-j] name format. These actions means that the file is not only renamed, but that it is also rotated. Rotation triggers the creation of a new CDR file with the temp- prefix to use for new CDR data.

Becoming Standby—When it transitions from Active to Standby, a SBC closes the open temp- prefix file and renames it according to the cdrYYYYMMDDHHMM[a-j] name format. Rotation creates a new temp- prefix file on the Standby, which remains empty until it transitions back to the Active state.
Standby push—provides the user with a mechanism to manage CDRs in a High Availability (HR) environment that prevents CDR loss during HA events.
When the user configures this setting, the standby can SFTP files to the CDR server. When the decision is made to become standby the system looks for any un-pushed CDRs that are still present and pushes those to the CDR server.

This process addresses two potential data loss issues:
- When an active node fails over, there may be temporary CDRs that have not yet been pushed to the CDR server. If the standby cannot send the record to the CDR server itself, the data is lost, resulting in the call not being charged.
- Temporary CDRs files often contain incomplete data and can be present on both the active and standby SBCs. After a failover, and when the original active becomes the active again, it would send this temporary file to the CDR server and overwrite the file that had been sent from the previously active system.
The user sets this value using the syntax below.
```
ORACLE(account-config)# cdr-output-redundancy standby-push
```
Setting this value can also enhance the clarity of CDR file names. This would also require that the applicable account-config have its file-seq-number parameter enabled. The system then includes information within the filename to distinguish whether the file came from the active or standby node. This prevents the standby from overwriting CDRs already on the server. This naming convention adds two prefixes to the CDR filename.
```
XXXX-YYYY-CDR201610171015-000000050
```
- XXXX - The filename-prefix defined in your push-reciever setting
- YYYY - The host name of the SBC
The standby-push value requires that the applicable account-config operate over a management (wancom) interface. Configuration verification fails if the user sets this value to an account-config operating over a media interface.

All parameters are RTC supported.

Note:

Before you upgrade from a release prior to S-CZ7.2.0 to S-CZ7.2.0 or later, you must set the cdr-output-redundancy parameter to enabled for the Standby to upgrade and sync properly. You can then change the parameter to disabled afterwards, if needed.

Caveats

As described above, when the system reboots for any reason or when you issue an activate-config, the SBC checks for CDR files with the temp- prefix and renames to the usual cdrYYYYMMDDHHMM[a-j] format.

However, if you change the accounting configuration’s file-path value and subsequently the system either reboots or you activate your configuration, the SBC will be unable to check for files with the temp- prefix in the old file path. And so it will also be unable to rename them. The SBC checks the new path only.

Call Detail Record Sequence Number in Filename

To assist in the identification of lost Call Detail Record (CDR) files, the customer can enable the file-seq-number attribute to assign a sequence number to append to the file. A separate configuration element, temp-remote-file, allows for the prepending of the characters "tmp-" to CDR files during transfer.

Sometimes local CDR transmission failures occur due to underlying network or infrastructure issues. Customers can identify missing files through the combination of a timestamp (YYYYMMDDMM) and 9-digit unique sequence numbers (SNs) appended to the file. This behavior is enabled through the file-seq-number attribute. The SN will start from one at boot time. This attribute replaces the use of alpha characters (a-z) appended to the CDR file name when more than one file is created in the same minute.

Local CDR File Storage Directories

The SBC only allows local storage of CDRs to the /opt directory. If you try to save to another directory (such as /code or /boot), you will receive an error message.

Setting the location to /opt/logs may cause the package-logfiles command and the package-crashfiles command to fail. Instead, use /opt/accounting.

If you are using the ACLI and enter an inappropriate directory, the ACLI will issue an error message.

Local CDR File Size and Rotation

You can configure maximum file size, maximum number of local CSV files to store, and the interval at which the files rotate.

The SBC saves up to the file size limit (max file size) and maintains only number of files that you configure (max files). When the maximum file size is reached, the SBC closes that file and begins writing VSA attributes and values to a new local CDR file. When it is time for the SBC to write the max files + 1 file, the oldest file is deleted so that the newest one can be stored.

You can set the period of time at which the SBC ends writing a local CDR file and begins writing data to a new file. This is the file rotate time and is configured in the file-rotate-time parameter.

Local CDR File Compression

You can configure the SBC to compress local CDRs in zip format to save disk space by setting the file-compression parameter to enabled.

Local CDR File Redundancy

The SBC can create a redundant copy of the local CDR files, and store them on the standby system in the HA node.

This enhancement to the CDR storage feature ensures against data loss if, for example, an active SBC fails immediately before sending the files off-box to a push reciever. The standby has a duplicate set of records that it sends. This feature is enabled with the CDR output redundancy parameter found in the account config configuration element.

Caveats for H.323

H.323 calls proceed without interruption over an HA node in the event of a failover from one SBC to another, and RADIUS records are generated and duplicated across the active and standby systems in an HA node. However if a switchover occurs during an H.323 call (that has been initiated, but not completed), the newly active (formerly standby) system will not generate RADIUS Stop records when the call completes.

Configuring Local CDR Files

This procedure explains how to enable and customize creation of local CDR files.

Access the account-config configuration element.

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

file-output—Enable this parameter for the SBC to create comma-delimited CDRs (generated from RADIUS records). By default, this parameter is disabled.
file-path—You must configure this path for the CDR push feature to work. Set the path to use on the SBC for file storage:
- /opt
- /opt/logs
  
  To use FTP push, you must configure a usable path.
  
  Note:
  When a Hard Disk Drive is available, you may opt to store CDRs in the data-disk.
max-file-size—Set the maximum CDR file size in bytes. The default and minimum value is 1000000. Oracle recommends you limit local CDR storage on your system to 30M. For example, if you retain the max-file-size default, set max-files to 30. However, if you are using a Storage Expansion Module the maximum value is 108.
max-files—Set the maximum number of files to be stored on the SBC at one time. The parameter's value range is from 0 to unlimited. The user should consider the max-file-size setting, the 30M recommendation, and their preferences to specify this value. The default is 5.
file-sequence-number—set this to enabled for the system to assign a 9 digit file sequence number to append to a CDR file. The default is disabled.
- enabled | disabled
file-compression—set this to enabled for the system to compress closed local CDR files in .zip format.
file-rotate-time—Set how often in minutes you want to rotate the stored files; the SBC overwrites the oldest file first. The minimum rotation time is 0 minutes, the default. Leaving this value set to the default means that the SBC does not rotate the files.
cdr-output-redundancy—Set this parameter to enabled for the SBC to store a redundant copy of the local CSV file to the standby HA node. Set this parameter to standby-push to enable the function and enable local storage and implement push capabilities on an HA deployment's standby to protect against CDR data loss.
vsa-id-range—Either leave this parameter blank (default), or enter the complete range of VSAs loaded on your system. The following example shows what you mightenter to use all of the VSAs for for a system that is not running QoS.
```
ORACLE(account-config)# vsa-id-range 1-4,10-14,20-24,28,29,32-71,74-136
```
cdr-output-inclusive—When disabled (default), the system excludes fields that have no data from the CSV file. Set to enabled to make the system include all fields in every CSV file. This ensures that there are always the same number of fields in all equivalent records. Start records would always have the same number of fields. The same would be true of interim and stop records.
Type done to save your configuration.

Local CDR File Delete Warning

You can configure the SBC to initiate an alarm and send an SNMP trap when the oldest local CDR file was deleted under fault conditions. This feature is enabled with the file delete alarm parameter.

The SBC deletes a local CDR file in the following three cases:

After the local CDR file has been successfully transferred to a push receiver
The number of local CDR files exceed the limit configured in the account-config, max-files parameter
No free disk space remains on the partition where the local CDR files are written: account-config, file-path

If a local CDR file is deleted after it was successfully uploaded to a push receiver, no fault is triggered because this is standard, expected operation. But if a local CDR file is deleted for case 2 or 3 above, it is considered a fault condition initiating an alarm and SNMP trap.

Local CDR File Delete Alarm

The CDR file delete alarm is configured in account config configuration element by enabling the file-delete-alarm parameter. This is a minor severity alarm and is non-health affecting. This alarm has no clearing condition and must be manually cleared.

Local CDR File Delete SNMP Trap

Under the same circumstances that cause a CDR file delete alarm, an SNMP trap will be sent to all configured trap-receivers. The apSysMgmtCdrFileDeleteTrap trap contains the following information:

File Name—name of the file that was deleted

Local CDR Push Receivers

Local CDR push recievers are used to transfer local CDR files to a remote server on a periodic basis. You configure this feature by defining push receivers with a remote IP address and port and login credentials for FTP and SFTP servers. At the configured time interval (file rotate time), the SBC closes the current file, and transfers the files that are complete and have not yet been pushed; including the just-closed-file. These files are uploaded to the remote servers at a specified remote-path. You can choose either ftp or sftp protocols to access the remote servers.

In the case that all push receivers are unreachable, then local CDR files continue to be written to local file system until the push receivers return to service. Once a push receiver becomes reachable, the SBC transfers all local CDR files to the remote server automatically. After all local CDR files have been successfully transferred to server, they are deleted from the local volume.

You can optionally set the temp-remote-file attribute so the characters "tmp-" are prepended to the CDR file during transfer. Once delivered, the file will be renamed on the remote host to remove "tmp-".

Secure FTP Push Configuration

You can configure the Oracle Communications Session Border Controller (SBC) to securely log on to a push receiver using one of the following methods that creates a secure connection.

Password authentication—

Set the protocol parameter on the push receiver to SFTP.
Configure a username and password.
Leave the public-key parameter blank.
Import the host key from the SFTP server to the SBC as a known-host key.
See "SSH Key Management" in the Configuration Guide.

Public key authentication—

Set the protocol parameter on the push receiver to SFTP.
Configure the username.
Leave the public-key parameter blank, regardless of authentication type.
Export the SBC's public key with the show security public-host-key rsa command.
Append the SBC's public-key to the SFTP server's authorized_keys file.
Import the host key from the SFTP server to the SBC as a known-host key.
See "SSH Key Management" in the Configuration Guide.

It is often difficult to determine whether the SFTP server uses its RSA key or its DSA key for its server application. For this reason, Oracle recommends that you import both the RSA key and the DSA key to the SBC to ensure a successful FTP Push.

It is also common for the SFTP server to run the Linux operating system. For Linux, the command ssh-keygen -e creates the public key that you need to import to the SBC. The ssh-keygen-e command sequence requires you to specify the file export type, as follows.

[linux-vpn-1 ~]# ssh-keygen -e
Enter file in which the key is (/root/.ssh/id_rsa/): /etc/ssh/ssh_host_rsa_key.pub

If you cannot access the SFTP server directly, but you can access it from another Linux host, use the ssh-keyscan command to get the key. An example command line follows.

root@server:~$ ssh-keyscan -t rsa sftp.example.com

Multiple Push Receivers

SBC (SBC) supports up to five CDR push receivers for use with the local file storage and FTP push feature. For each receiver you configure, you can set the file transfer protocol that you want to use. (FTP or SFTP). The system uses the push receivers according to the priorities you assign by setting a 0 through 4 priority number to the server. 0 is the highest priority, and 4 (default) is the lowest.

Based on the priority level you set, the SBC uses the strategy that you set to select a CDR push receiver. If the highest priority push receiver selected using the strategy becomes unavailable, the SBC uses the strategy (hunt, round robin) to select another.

This feature is dynamically configurable. When you change the configuration, the SBC updates the list of push receivers if it has changed.

Deprecated ACLI Configuration

The following parameters in the account-config configuration element are deprecated:

ftp-address
ftp-port
ftp-user
ftp-password
ftp-remote-path

These parameters will only be used if no account-config, push-receiver configuration elements have been defined. All new push receivers must be defined in the account-config, push-receiver configuration element.

Configuring Local CDR Push Receivers

This procedure explains how to enable and customize a push receiver configuration that will transfer closed local CDR files to remote servers.

Access the account-config configuration element.

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

ftp-push—Set the state of FTP push feature to enabled. It is disabled by default.
Type push-receiver and press Enter.
```
ORACLE(account-config)# push-receiver
```
You can now begin to configure a push reciever.
server—Enter the IP address of this push receiver.
port—Enter the port number of this push receiver.
remote-path—Enter the remote pathname where local CDR files should be written on the push receiver.
filename-prefix—Enter the filename prefix (as a string) to prepend to the Local CDR files. The SBC does not rename local files. There is no default for this parameter.
priority—Enter a number 0 through 4 to set the priority of this push receiver in relation to the others you configure on the system. The highest priority, and the push receiver the system uses first, is 0. The lowest priority, and the push receiver the system uses last, is 4 (the default).
temp-remote-file—set the state of this element to enabled for the system to prepend the characters "tmp-" to a CDR file during transfer. When the transfer ends successfully, the system removes the characters "tmp-". The default is disabled
- enabled | disabled
protocol—Enter SFTP or FTP. Consider the port value you configured earlier.
username—Enter the username the SBC uses when connecting to this push receiver. There is no default for this parameter. This parameter is always required.
password—Enter the password corresponding to the username the SBC uses when connecting to this push receiver. There is no default for this parameter. You can leave this field blank if you are using public key authentication. Profile configuration is required for both password and public key authentication.
public-key—Do not configure this field. Public key operations are performed outside of this configuration element. See "SSH Key Management" in the Configuration Guide.
ftp-strategy—Set the strategy you want the SBC to use when selecting from multiple push receivers. The default is hunt.
- Hunt—The SBC selects the push receiver from the available list according the priority level. The system uses this strategy as its default.
- Failover—The SBC selects the push receiver based on priority level and will continue to use that same push receiver until it fails over.
- RoundRobin—The SBC selects push receivers systematically one after another, balancing the load among all responsive push receivers.
- FastestRTT—The SBC selects the push receiver based on best average throughput. For this situation, throughput is the number of bytes transferred divided by the response time. The system uses a running average of the five most recent throughput values to accommodate for network load fluctuations.
ftp-max-wait-failover—Enter the amount of time in seconds to wait before the SBC declares a push receiver to have failed over. This default value for this parameter is 60.
Type done to save your configuration.

Monitoring CDR Push Receivers

The SBC provides several mechanisms to monitor push recievers

ACLI Show Command

You can use the ACLI show radius cdr command to view information about CDR push receivers. The existing display for this command has been extended to include information that looks like the following:

******************* CDR Push Receiver Display Start*******************
strategy = FastestRTT, maxwaitfailover = 10, number of receivers = 1
--------------------- 172.30.0.70:21 ---------------------
cdrpush-receiver = 172.30.0.70:21, state = READY, priority = 4
remote path = /home/acme, remote prefix = vik, protocol = ftp
username = acme, password = ********, publickey =
FTP rtt = 0, FTP successes = 0, FTP failures = 0
FTP timeouts = 0, FTP Delays = 0, FTP Put failures = 0
FTP conn failures = 0, FTP terminates = 0, FTP triggered terminates = 0

SNMP Traps and Alarms

The SBC sends traps when a single push receiver or all push receivers become unavailable.

When one CDR push receiver becomes unavailable, the CDR_PUSH_RECEIVER_FAIL_TRAP trap is sent and a minor alarm is generated.
When all of the configured CDR push receivers become unavailable, the CDR_ALL_PUSH_RECEIVERS_FAIL_TRAP is sent and a major alarm is generated.

When one or more of the push receivers comes back, the CDR_ALL_PUSH_RECEIVERS_FAIL_CLEAR_TRAP is sent and the alarm is cleared.

The SBC sends out traps and triggers corresponding alarms when it encounters failure when attempting to transfer local CDR files. One set of traps is used for single-instance push receiver failures; another set is used when all receivers fail. They are part of the apSysMgmtCDRPushReceiverNotificationsGroup.

All of the traps contain information about the type of push receiver, the address of the push receiver, and the failure reason code.

The trap and corresponding clearing trap for single push receiver failure are:

apSysMgmtCDRPushReceiverFailureTrap
apSysMgmtCDRPushReceiverFailureClearTrap

A minor alarm is generated when the apSysMgmtCDRPushReceiverFailureTrap is sent.

The trap and corresponding clearing trap for global push receiver failure are:

apSysMgmtCDRAllPushReceiversFailureTrap
apSysMgmtCDRAllPushReceiverFailuresClearTrap

A major alarm is generated when the apSysMgmtCDRAllPushReceiversFailureTrap is sent.