# Communication Service Reference

# Events, Alarms, and Charging

This appendix describes the features common to the handling of events, alarms, and charging in Oracle Communications Services Gatekeeper.

- Events
- Alarms
- Charging Data Records

## Events

Events are handled differently in the Access Tier and the Network Tier.

### Event handling in the Access Tier

The Access Tier runs in the WebLogic Server’s Web Services Container, so events or alarms that are raised there can be monitored through standard JMX mechanisms or by using the WebLogic Diagnostics Framework.

See Developing Manageable Applications with JMX and Configuring and Using the WebLogic Diagnostics Framework, part of the Oracle WebLogic Server set of documents, for more information on how this works.

### Event handling in the Network Tier

In the Network Tier, much of the functionality comes from the interaction between communication services and Oracle Communications Services Gatekeeper’s Container Services. To capture this specialized level of information, and other pertinent information about the status of the tier, Oracle Communications Services Gatekeeper has developed specific mechanisms to record the data.

In standard communication services, all status information generated by the Network Tier - events, alarms, charging data, and usage statistics - begins as an event, which is fired whenever designated methods are called or exceptions are thrown. These events are then sent to the EDR Service. In the EDR Service, events are processed through XML-based filters, which provide the criteria by which the events are classified into types. The filters can also be used to transform the data in the original event, including adding other useful information. When the information has been processed by the filters, it is delivered to type-specific listeners. Out of the box, there are three types of filters that are all found in the file wlng-edr.xml. They produce three distinct types of data: Event Data Records (EDRs), Charging Data Records (CDRs), and Alarms. All three of these filters can be customized as desired, using the Administrative Console. These filters can also deliver desired event-based information to external JMS-based listeners. Such listeners are set up as standard JMS topic subscribers and can be anywhere on the network. See Orac le Communications Services Gatekeeper - System Administrator’s Guide for more information on setting up these filters.

Note: | For the purposes of backwards compatibility, events, alarms, and charging records can be published and delivered to 2.2 style, as well as standard style, listeners, but this mechanism has been deprecated since version 3.0.

Each EDR always includes the following data:

Element | Represents
ServiceName | The service type (SMS, Call Handling, etc.) that produced the event
ServerName | The name of the WLS host
Timestamp | The time at which the event was triggered (in milliseconds from midnight 1 January 1970)
ContainerTransactionID | The transaction ID from WebLogic Server, if available. This identifies the thread on which the request is executed
Class | The name of the class that logged the event
Method | The name of the method that logged the event
Source | The kind of event. There are two possible values for this field: Method: the event was fired in relation to a method call Exception: the event was fired in relation to an exception being thrown

In addition, most events include:

Element | Represents
Direction | The direction in which the request is traveling. There are two possible values for this field: South: traveling toward the network node North: traveling toward the application
Position | The position of the EDR relative to the method that logged the EDR. There are two possible values for this field: Before: the event occurred before the method After: the event occurred after the method
Interface | The interface at which the EDR is logged. There are three possible values for this field: North: the event was logged at the north plug-in interface South: the event was logged at the south plug-in interface Other: the event was logged someplace other than the north or south interfaces
Exception | The name of the exception that triggered the EDR
SessionId | The application’s session identifier
ServiceProviderId | The service provider account identifier
ApplicationId | The application account identifier
AppInstanceGroupId | The authentication user name of the Application Account. This is a string that is equivalent to the 2.2 value: Application Instance Group ID
OrigAddress | The originating address with scheme. For example: tel:12123334444
DestAddress | The destination address. If this is a send list, the first address will be listed here. Additional addresses are stored in the AdditionalInfo field.
AdditionalInfo | Variable information depending on the communication service. Stored as “key=value\n” pairs.
PluginID | The unique ID of the plug-in instance.

## Alarms

Network Tier alarms are those events that are of immediate interest to the operator. They are EDRs that are defined via filters created in the internal configuration file. While each alarm begins as an EDR, not all the information available in the EDR is stored when the alarm is written to the database (although that information can be retrieved using an external listener). Each alarm entry in the database includes the following information:

Element | Represents
alarm_id | A unique sequential identifier
source | The name of the software module that raised the alarm and the IP address of the server in which the module runs. This is not the same as the Source field in the event
timestamp | The time at which the event was triggered (in milliseconds from midnight 1 January 1970)
severity | The importance of the alarm. There are four possible values for this field: 4 for warning 3 for minor 2 for major 1 for critical
identifier | The alarm type
alarm_info | Information provided by the module that raised the alarm
additional_info | This field includes: Service Provider ID Application ID Application Instance ID Plug-in instance ID Other information depending on context

### Management integration

Oracle Communications Services Gatekeeper supports integration of its alarm and event mechanisms with external management tools.

#### OSS

An Operation Support System (OSS) can integrate with Oracle Communications Services Gatekeeper alarm and event services through the creation of external JMS listeners. As well, integration can be managed by OAM scripts through the use of JMX-based tools.

#### SNMP

Oracle Communications Services Gatekeeper also supports the sending of alarms as SNMP traps to SNMP managers. The alarms sent to the SNMP managers can be filtered on alarm severity.

## Charging Data Records

CDRs originate as filtered EDRs. While each CDR begins as an EDR, not all the information available in the EDR is stored when the CDR is written to the database (although that information can be retrieved using an external listener). Each CDR entry in the database includes the following information:

Element | Represents
transaction_id | The Oracle Communications Services Gatekeeper transaction sequence number
service_name | The communication service whose use is being tracked
service_provider | The Service Provider ID
application_id | The Application ID
application_instance_id | The user name of the Application Account. This is a string that is equivalent to the 2.2 value: Application Instance Group ID
container_transaction_id | The transaction ID from WebLogic Server, if available. This identifies the thread on which the request is executed
server_name | The name of the server in which the CDR was generated
timestamp | The time at which the event was triggered (in milliseconds from midnight 1 January 1970)
service_correlation_ID | An identifier that allows the usage of multiple service types to be correlated into a single charging unit
charging_session_id | An ID correlating related transactions within a service capability module that belong to one charging session. For example, a call containing three call legs will produce three separate transactions within the same session
Note: | In installations where sessions are not used, this field contains only a placeholder value.
start_of_usage | The date and time the request began to use the services of the underlying network
connect_time | The date and time the destination party responded. Used for Call Control traffic only
end_of_usage | The date and time the request stopped using the services of the underlying network
duration_of_usage | The total time the request used the services of the underlying network
amount_of_usage | The used amount. Used when charging is not time dependent, as in, for example, flat rate services
originating_party | The originating party’s address
destination_party | The destination party's address. This is the first address in the case of send lists, with all additional addresses placed in the additional_info field.
charging_info | A service code added by the application or by policy service
additional_info | If the communication service supports send lists, all destination addresses other than the first, under the key `destinationParty`. In addition any other information provided by the communication service