Skip Headers
Oracle® Communications Service Broker System Administrator's Guide
Release 5.0

Part Number E15183-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

14 Viewing Service Broker SDRs

The following sections explain how you can monitor Oracle Communications Service Broker using Service Broker Service Description Records (SDRs):

Understanding Service Broker Service Description Records

A Service Description Record (SDR) is a set of parameter-value pairs that provide information on how service activation and delivery are performed through Service Broker.

An SDR is generated by the OE for each session. You will find SDRs on each Processing Server where an OE instance runs.

The OE stores SDRs in text files. The file name conventions is as follows:



For example:

Each file contains multiple SDRs. A files is closed when it reaches a pre-configured file size, at which time a new file is created. The default file size is 100 KB.

When the number of files reaches a pre-configured maximum, the oldest file is deleted with the addition of each new file. The default maximum number of files is 10.

If you need to store SDR files for longer periods of time, you should fetch the SDR files daily and move them to a separate system.

Configuring SDR Logging

Depending on your system capacity, you may want to modify maximum SDR file size and the maximum allowed number of SDR files. You can also disable writing SDRs to files if you do not need them.

SDR logging is controlled by Log4J. Service Broker includes pre-configured Log4J parameters with key-value pairs that define SDR logging.

The Log4J Configuration MBeans reflect the structure of the Log4J XML configuration file. See the Log4J documentation at:

The MBean Object Name is:,name=oracle.axia.logging.log4jconfig,version=,name0=log4jConfig

The default configuration MBean has an object name with name1 set to configuration[0]:,name=oracle.axia.logging.log4jconfig,version=,name0=log4jConfig,name1=configuration[0]]

Setting the Maximum File Size and Number of Files

Using the Scripting Engine or an MBean browser:

  1. Locate the Log4J Configuration MBean.

  2. Locate the configuration MBean with object name:,name=oracle.axia.logging.log4jconfig,version=,name0=log4jConfig,name1=configuration[0]]

  3. Locate the appender MBean that has the attribute name set to oe_file.

    Example Object Name:,name=oracle.axia.logging.log4jconfig,version=,name0=log4jConfig,name1=configuration[0],name2=appender[2]

  4. Locate the param MBean with the attribute name set to MaxFileSize.

    Example Object Name:,name=oracle.axia.logging.log4jconfig,version=,name0=log4jConfig,name1=configuration[0],name2=appender[2],name3=param[1]

  5. Set the attribute value for the param MBean to the maximum file size. Default value is 100KB.

  6. Locate the param MBean with the attribute name set to MaxBackupIndex.

    Example Object Name:,name=oracle.axia.logging.log4jconfig,version=,name0=log4jConfig,name1=configuration[0],name2=appender[2],name3=param[2]]

  7. Set the attribute value for the param MBean to the number of files. Default value is 10.

Disabling Logging of SDRs

To disable writing SDRs to files, change the log level of the SDR logger from trace to info or any higher log level.

Using the Scripting Engine or an MBean browser:

  1. Locate the Log4J Configuration MBean.

  2. Locate the configuration MBean with object name:,name=oracle.axia.logging.log4jconfig,version=,name0=log4jConfig,name1=configuration[0]]

  3. Locate the logger MBean that has the attribute name set to com.convergin.oe.common.datarecord.OeSpooler.

    Example Object Name:,name=oracle.axia.logging.log4jconfig,version=,name0=log4jConfig,name1=configuration[0],name2=logger[5]

  4. Locate the level MBean for the logger MBean.

  5. Set the attribute value for the level MBean to trace or info. Default value is trace, which enables SDR logging.

Service Description Record Format

Each SDR consists of parameter-value pairs that store information about service activation and delivery performed through Service Broker. Table 14-1 describes the parameters available in each SDR.

Table 14-1 Service Broker SDR Fields

Field Description


Specifies the type of Service Broker module that generated the SDR.

This value of field is always "OE".


Specifies the OE version


Specifies the type of session that triggered the OE:

Possible values:

  • CallControl: The OE was triggered by a call

  • SmsControl: The OE was triggered by a message (for example, SMS)


Specifies the module instance name


Specifies the name of the Processing Server where the OE runs.


Specifies the session direction.

Possible values:

  • Incoming

  • Outgoing


Specifies the unique session reference number.


Specifies the call p-charging-vector, as defined in IETF RFC 3455


Specifies a unique identifier generated by the first Service Broker module in the session path


Specifies the identifier of the subscriber for whom the service is triggered


Specifies the service identifier. This field is displayed only when the OE is triggered through the IM-SCF CAP or IM-SCF CS1.


Specifies the calling party number


Specifies the calling party number. Usually this number is identical to the value of the CallingPartyNumber field.


Specifies the called party number


Specifies the Orchestration Profile Receiver that the OE used to obtain the orchestration profile.

For more information about the types of OPRs, see "About Orchestration Profile Receivers" in the Oracle Communications Service Broker Concepts Guide.


Specifies the unique identifier of the orchestration profile that the OPR downloaded. When the LSS is used, this field shows the ID field given to an LSS profile.

When the orchestration logic was not found, this field is set to 'not found'.


Specifies the OLP that was used.


Specifies the time when the session started (that is when the OE was triggered)


Specifies the time when the Service Broker finished handling the session


Specifies the application that the Service Broker triggered in the following format:

<Application Name>; <Time>; <Application Response>,


  • <Application Name> specifies the application that the OE triggered

  • <Time> specifies the time when the OE triggered the application

  • <Application Response> specifies the SAL message returned from the application. Possible values: INVITE, 302, 4xx, or 5xx.

For example:; 2009-02-13T07:29:28.482-0600; 302


Information received from IMs in the session path inside Service Broker. The information is dynamic and varies, depending on the IM that provided the information.

Field format: <im-type->; <info-tag-value-string>

For example: ImInfo: IMOCF; sid=35263; requm=3; nonChargeDuration=25

The values in the info-tag-value-string are listed in IM-Generated Tags.

An example of an SDR is provided below:

ModuleType : oe
ModuleVersion : 1.0
RecordType : CallControl
ModuleInstanceName : oe_instance
Server : sb_processing01
CallDirection : Outgoing
CallReferenceNumber : 36011211571409664
ChargingVector : icid-value=360112115714096647FF001;
SBCorrelationID : null
SubscriberID : <;noa=national>
ServiceKey : 11
CallingPartyNumber : <;noa=national>
AdditionalCallingPartyNumber : "sipp"<sip:sipp@>;tag=1260965860664
CalledPartyNumber : "sut"<sip:service@>;tag=1260965860665
OLID : 101
OLP : ifc
ServiceStartTime : Wed Dec 16 14:17:41 IST 2009
ServiceTermTime : Wed Dec 16 14:17:52 IST 2009
Application : <;lr> ; Wed Dec 16 14:17:42 IST 2009 ; INVITE

IM-Generated Tags

Service Broker IMs generate session-related data describing IM activity during the session. The OE receives this data and incorporates into the SDR. The data consists of a range of tags, which vary according to the IM type.

Table 14–2 describes the tags generated by the IM-OCF.

Table 14-2 IM-Generated Tags

IM Type Tags Description


sid=35263; recum=3; nonChargeDuration=25

sid: session id

reqnum: the number of the last successful CCR request sent to an OCF

nonchargeDuration: The time that elapsed from the last successful CCR request to the end of the session. This time can be used at a later time for provisioning in the OCF (if it fails), for offline charging.