The following section describes how to manage and configure the CDR to Diameter service in Oracle Communications Services Gatekeeper.
The CdrToDiameter service forwards charging events to a Diameter server using the DIAMTER Rf interface. This allows for easy integration with charging systems that support Diameter Rf offline charging. When enabling this service, Oracle Communications Billing and Revenue Management, together with Oracle Communications Network Mediation, can be used out-of-the-box with Oracle Communications Services Gatekeeper.
Any traffic request processed through Oracle Communications Services Gatekeeper that generates a CDR also generates a corresponding Diameter Rf request. The Diameter server can the be used for any billing, charging, and reporting for these requests. See CDR to AVP mapping for information about how CDRs are mapped to Diameter attribute-value pairs (AVPs).
The service is not deployed by default. It is deployed as a regular JEE module using WebLogic Server deployment tools. See Oracle WebLogic Server Deploying Applications to WebLogic Server at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/deployment/ for information on how to deploy the service.
The service is packaged in cdr_to_diameter-single.ear
and cdr_to_diameter.ear
in $OCSG_HOME/applications
.
Use cdr_to_diameter.ear
in clustered installations, and cdr_to_diameter-single.ear
in single server domains.
The service is a cluster singleton, so it will execute only on one server at any given time, and is transferred to another server in case of server failure.
The management part is distributed to all servers in the cluster, so it can be managed from any server in the cluster.
Note: | Some Diameter requests may be dropped during patching, redeployment, or upgrade of the CDR to Diameter module. Check the database for the time period during which the transition took place. All CDRs are stored in the database. |
To configure the behavior of the CdrToDiameter service, in the managed object CdrToDiameter:
The CdrToDiameter service can be explicitly connected to the Diameter server. It does not connect to the server by default. The service has a connection status that will be preserved after service redeployment and server restart.
.Use Attribute: Enabled (r) to check the current connection status.
Use Operation: connect after any changes to the configuration attributes. Changes does not take affect until this operation is invoked.
Managed object: Container ServicesCdrToDiameter
MBean: com.bea.wlcp.wlng.cdrdiameter.management.CDRDiameterMBean
Below is a list of attributes and operations for configuration and maintenance.
Displays the status of the CdrToDiameter service.
Specifies the Origin-Host AVP in the Diameter request.
Can be specified either as an IP-address or a host name.
Specifies the local originator port to be used for the connection to the Diameter server.
If specified as 0 (zero), a random local port is used.
Specifies the Destination-Host AVP in the Diameter request.
Can be specified either as an IP-address or a host name.
Specifies the port on the Diameter server to connect to.
Specifies the Destination-Realm AVP in the Diameter request.
Specifies the time to wait before attempting to reconnect to the Diameter server if the connection is lost.
Specifies the maximum time to wait for a response to a request to the Diameter server.
Specifies the watchdog timeout Tw.
This setting corresponds to the timer Tw, see RFC 3539 at http://www.ietf.org/rfc/rfc3539.txt.
It specifies the time to wait before attempting to reconnect to the Diameter server in the case of a lost connection.
Connects to the Diameter server.
Once connected, the service will try to reconnect to the Diameter server if the server is restarted or the service is redeployed.
connect()
Disconnects from the Diameter server.
Once disconnected, the service will not try to reconnect to the DAMETER server if the server is restarted or the service is redeployed.
disconnect()
The CDRs that are generated are mapped to Diameter attribute-value pairs, AVPs, according to Table 8-3. Both standard and custom AVPs are used. When custom are used it is indicated in the table.
Configurable, see Attribute: OriginHost.
|
||
Configurable, see Attribute: DestinationRealm.
|
||