Skip Headers
Oracle® Communications Service Broker Orchestration User's Guide
Release 6.1
Part Number E29453-01
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Feedback page
Contact Us
Go to previous page
Previous
PDF · Mobi · ePub

B Initial Filter Criteria

This appendix describes how you can set up the Initial Filter Criteria (iFC) using standard iFC elements and proprietary extensions supported by the Oracle Communications Service Broker Orchestration Engine (OE).

About the Initial Filter Criteria

The iFC is an XML-based IP Multimedia Subsystem (IMS) standard that you use to define the order in which the OE routes a session across applications. The following documents describe the standard iFC elements:

Setting Up the Initial Filter Criteria

The iFC defines the order in which the OE routes a session across applications. The routing is conditional. This means the OE routes the session to a specific application only when the session meets the criteria specified for that application. For example, you can specify that the OE routes the session to a Virtual Private Network application only when the session's Called Party Number begins with the asterisk (*).

A set of conditions that a session must meet and the application to which the OE routes the session is known as initial filter criteria. You enclose initial filter criteria in the <InitialFilterCriteria> element. You can create as many <InitialFilterCriteria> elements as you need.

In each <InitialFilterCriteria> element, you specify the following elements:

Setting Up a Trigger Point

A trigger point consists of one or more conditions that the session must meet in order to be routed to a specific application. In the iFC, each condition is called Service Point Trigger (SPT). To set up an SPT, you use the <SPT> element.

You can specify conditional statements using AND and OR conditions between SPTs. For example, you might specify that the OE routes the session to an application if the following condition is met: (SPT1 OR SPT2) AND (SPT3 OR SPT4).

To set up conditional statements, you need to group SPTs. Then you specify the relationship between groups of SPTs and members of each group.

For example, in the statement (SPT1 OR SPT2) AND (SPT3 OR SPT4), SPT1 and SPT2 belong to one group. SPT3 and SPT4 belong to another group. The relationship between group members is OR. The relationship between the groups is AND.

Grouping SPTs and Specifying Relationship Between Groups and Group Members

To group SPTs, you specify an integer which represents the group to which the SPT belongs, in the <Group> element. You place this element under the <SPT> element. The SPTs whose <Group> element is set to the same number belong to the same group.

To specify the relationship between groups of SPTs and members of each group, you use the <ConditionTypeCNF> element placed under the <TriggerPoint> element. You can set the <ConditionTypeCNF> element to one of the following values:

  • 0: the relationship between group members is AND while the relationship between groups is OR. For example, (SPT1 AND SPT2) OR (SPT3 AND SPT4).

  • 1: the relationship between group members is OR while the relationship between groups is AND. For example: (SPT1 OR SPT2) AND (SPT3 OR SPT4).

Specifying Conditions

You can use the following criteria as conditions that the session must meet:

  • <Method>, which defines a SIP method used to initiate a call. For example, you can specify that the OE triggers an application only if the method is INVITE.

  • <SIPHeader>, which consists of the following elements:

    • <Header>, which defines the name of the header that you want to check. You can specify any standard SIP header as well as any custom header.

    • <Content>, which defines the contents of the header

  • <RequestURI>, which contains the URI of the destination application server defined in the session request.

  • <Line> and <Content>, which contain the session type to be communicated between the two end parties. The OE uses these criteria when the content type of the message body is "application/sdp". The OE checks whether the text in each line of the incoming message body matches the text that you specified in <Line> tag. After the OE found the line, the OE checks whether this line contains the text specified in the <Content> tag.

You can negate the condition using the <ConditionNegated> element. Use a negated condition to sepcify that a condition is met for values other than the ones specified in the condition. For example, you can route a session to a module only if the SIP Method is other than INVITE. To negate a condition, set <ConditionNegated> to 1. Otherwise, set <ConditionNegated> to 0.

The following code shows a scenario in which the iFC defines SPTs as follows:

Table B-1 SPTs Definitions in the Sample iFC

SPT Condition to Be Checked Group

SPT 1

Method of the session is INVITE.

1

SPT 2

SessionCase of the session is 0.

1

SPT 3

Method of the session is INVITE.

2

SPT 4

From header of the session does not contain "joe".

2

SPT 5

RequestURI header of the session contains "sip:destination_server1@oracle.com".

3

SPT 6

SessionCase of the session is 2.

3

The OE routes the session to the application if the following condition is met: (INVITE OR SESSIONCASE=0) AND (INVITE OR FROM != "Joe") AND (requestURI="sip:destination_server1@oracle.com" OR SessionCase=2)

<iFCs>
  <InitialFilterCriteria>
    <Priority>0</Priority>
    <TriggerPoint>
      <ConditionTypeCNF>0</ConditionTypeCNF>

      <SPT>
        <ConditionNegated>0</ConditionNegated>
        <Group>1</Group>
        <Method>INVITE</Method>
      </SPT>

      <SPT>
        <ConditionNegated>0</ConditionNegated>
        <Group>1</Group>
        <SessionCase>0</SessionCase>
      </SPT>

      <SPT>
        <ConditionNegated>0</ConditionNegated>
        <Group>2</Group>
        <Method>INVITE</Method>
      </SPT>

      <SPT>
        <ConditionNegated>1</ConditionNegated>
        <Group>2</Group>
        <SIPHeader>
          <Header>From</Header>
          <Content>"joe"</Content>
        </SIPHeader>
      </SPT>

      <SPT>
        <ConditionNegated>0</ConditionNegated>
        <Group>3</Group>
        <RequestURI>sip:destination_server1@oracle.com</RequestURI>
      </SPT>

      <SPT>
        <ConditionNegated>0</ConditionNegated>
        <Group>3</Group>
        <SessionCase>0</SessionCase>
      </SPT>

    </TriggerPoint>

  <ApplicationServer>
    <ServerName>sip:app1@oracle.com</ServerName>
    <DefaultHandling>0</DefaultHandling>
  </ApplicationServer>
</InitialFilterCriteria>

Specifying an Application

When the conditions set in the <TriggerPoint> element are met, the OE routes the session to the application that you specify in the <ApplicationServer> element.

In this element, you define the following mandatory elements:

  • <ServerName>, which defines the SIP URL of an IM to which the OE routes the session

  • <Default Handling>, which defines whether or not the OE releases a session if an application cannot be reached. You can set <Default Handling> to one of the following values:

    • 0: to continue the session

    • 1: to terminate the session

The following code shows a scenario in which the OE routes the session to the IM whose SIP URI is sip:as2@192.168.1.140:5060. In this example, the OE continues the session if the application cannot be reached.

<ApplicationServer>
    <ServerName>sip:app1@oracle.com</ServerName>
    <DefaultHandling>0</DefaultHandling>
  </ApplicationServer>

See "Continuing or Releasing a Session" for more information about configuring of the default handling.

Specifying a Priority

In some cases, conditions defined in several different filter criteria can be met. To enable the OE to choose a specific filter criteria, you can define a filter criteria's priority.

The higher the rule's priority number, the lower priority the filter criterion has. This means that a filter criterion with a higher value of priority number is assessed after the filter criteria with a smaller priority number has been assessed. 0 (zero) means the highest priority. 100 means the lowest priority.

The same priority cannot be assigned to more than one initial filter criterion.

Specifying the Order of Message Routing

The iFC defines how the OE routes messages generated by the calling party. For example, you can set an initial INVITE to be routed from Application 1 to Application 2 to Application 3. Figure B-1 shows the order in which the OE routes an INVITE message from a calling party to a called party.

Figure B-1 Routing an INVITE Message from a Calling Party

Surrounding text describes Figure B-1 .

The iFC does not specify how the OE routes messages received from a called party. By default, when a called party generates a message (for example, an OK response to an INVITE message), the OE routes this message in the reverse order, from Application 3 to Application 2 to Application 1. Figure B-2 shows the order in which the OE routes an OK response from a called party to a calling party.

Figure B-2 Routing an OK Message from a Called Party

Surrounding text describes Figure B-2 .

When an application in the orchestration chain depends on the information generated by a previous application, you might need to route all messages, including those generated by a calling party and those generated by a called party, in the same order. For example, you might need a message to be first routed to an online charging application and then to a bill shock application. In this case, a bill shock application can perform certain actions based on the information generated by the online charging application.

To allow the OE to route all messages across applications in the same order, you need to group these applications in a unidirectional group. Figure B-3 shows how the OE routes a message generated by a called party through applications in a unidirectional group.

Figure B-3 Routing an OK Message from a Called Party in a Unidirectional Group

Surrounding text describes Figure B-3 .

When grouping applications into unidirectional groups, you must observe the following limitations:

You use the <UnidirectionalGroup> element to assign an application to a unidirectional group. Because this element is an extension to the standard iFC, you need to put it under the <Extension> element.

You set <UnidirectionalGroup> to the identifier of a group. This identifier must be an integer. You can have as many unidirectional groups as you need.

The following code shows an example of how you can assign two applications to the same unidirectional group (the <UnidirectionalGroup> is bolded).

<iFCs>
  <InitialFilterCriteria>
    <Priority>2</Priority>
    <TriggerPoint>
      <ConditionTypeCNF>0</ConditionTypeCNF>
      <SPT>
        <ConditionNegated>0</ConditionNegated>
        <Group>0</Group>
        <Method>INVITE</Method>
      </SPT>
    </TriggerPoint>
  <ApplicationServer>
    <ServerName>sip:as2@192.168.1.140:5060</ServerName>
    <DefaultHandling>0</DefaultHandling>
    <ServiceInfo></ServiceInfo>
    <Extension>
      <UnidirectionalGroup>1</UnidirectionalGroup>
      <ForceB2B/>
    </Extension>
  </ApplicationServer>
</InitialFilterCriteria>

<InitialFilterCriteria>
  <Priority>3</Priority>
  <TriggerPoint>
    <ConditionTypeCNF>0</ConditionTypeCNF>
    <SPT>
      <ConditionNegated>0</ConditionNegated>
      <Group>0</Group>
      <Method>INVITE</Method>
    </SPT>
  </TriggerPoint>
  <ApplicationServer>
    <ServerName>sip:as3@192.168.1.141:5060</ServerName>
    <DefaultHandling>0</DefaultHandling>
    <ServiceInfo></ServiceInfo>
      <Extension>
        <UnidirectionalGroup>1</UnidirectionalGroup>
        <ForceB2B/>
      </Extension>
    </ApplicationServer>
  </InitialFilterCriteria>
</IFCs>

Note:

Service Broker does not support unidirectional groups when the Diameter-based orchestration mode is enabled. For more information on the Diameter-based orchestration mode, see the discussion on improving performance in Diameter-only environments in Oracle Communications Service Broker Online Mediation Controller Implementation Guide.

Providing Additional Information to an Application

You can configure the OE to send additional information to an application by using the <ServiceInfo> element. You need to place this element under the <ApplicationServer>.

The OE adds the text specified in <ServiceInfo> to the body of the message that the OE forwards to the application.

The following code shows an example of how you can specify additional information to be sent to the application (the <ServiceInfo> element is bolded).

<ApplicationServer>
  <ServerName>sip:as@192.168.0.1:5060</ServerName>
  <DefaultHandling>0</DefaultHandling>
  <ServiceInfo>application-specific information</ServiceInfo>
</ApplicationServer>

Continuing or Releasing a Session

When the OE receives a final response from an application (that is a 3xx, 4xx, or 5xx response), the OE can either release or continue the session. You specify the action that the OE performs using the following elements:

For a more fine-grained configuration, you can use <ForceB2B> in conjunction with <DefaultHandling>. The following example shows a scenario in which the OE releases a session if an application sends an error message (<DefaultHandling> is set to 1). However, if the error is 408 Request Timed Out, the OE continues the session (the <response> element is bolded):

<DefaultHandling>1</DefaultHandling>
<Extension>
  <ForceB2B>
    <response>408</response>
  <ForceB2B>
</Extension>

By default, the OE continues the session if the 302 Moved Temporarily response is received. Otherwise, the OE releases the session.

Note:

Service Broker does not support the default handling and force B2B features when the Diameter-based orchestration mode is enabled. For more information on the Diameter-based orchestration mode, see the discussion on improving performance in Diameter-only environments in Oracle Communications Service Broker Online Mediation Controller Implementation Guide.

Triggering Applications Based on the Status of the Previous Application

The status of an application is determined by a request or response that the application returns to the OE. You can set up any application in the orchestration chain to run only if the previous application in the orchestration chain has a specific status that the application returns a specific request or response.

For example, you can specify that the OE triggers an application only if the previous application returns INVITE to the OE. Alternatively, you can define that the OE triggers an application only if the previous application returns the response code 302 Moved Temporarily.

The information about a response or request which the previous application returns is stored in the x-wcs-history header of the message. This header has the following format:

x-wcs-history: id=application_identifier; status=status_code

The parameters are defined as follows:

Figure B-4 shows a scenario in which the OE routes the session as follows:

  1. The OE routes the session to Application 1. The <Priority> element of the iFC that triggers this application is 1. Application 1 returns to the OE the response code 200 OK. Application 1 sets the x-wcs-history header as follows:

    • id=1

    • status=200

  2. Then the OE routes the session to Application 2. The <Priority> element of the iFC that triggers this application is 2. Application 2 returns to the OE the INVITE request. This request is mapped to 10 using OeHistoryMBean. Application 2 updates the x-wcs-history header as follows:

    • id=2

    • status=10

  3. Finally, the OE routes the session to Application 3. The <Priority> element of the iFC that triggers this application is 3. Application 3 returns to the OE the response code 302 Moved Temporarily. Application 3 updates the x-wcs-history header as follows:

    • id=3

    • status=302

Figure B-4 Returning Information about Response from the Previous Application

Returning Information on Response from Previous Application

Mapping Request Names to Status

The status parameter of the x-wcs-history header is the integer that describes the message that an application returns to the OE. If an application returns a request (for example, an INVITE), you need to map this response to an integer using the OeHistoryMBean. For example, you can map an INVITE message to 10.

To map a response:

  1. Create an instance of RequestStatusCodesMBean by invoking the following operation of OeHistoryMBean:

    ObjectName createRequestStatusCodes()

  2. Create an instance of RequestStatusCodeMBean by invoking the following operation of RequestStatusCodesMBean:

    ObjectName createRequestStatusCode()

  3. Set the attributes of RequestStatusCodeMBean as follows:

    • Set the Request attribute of RequestStatusCodeMBean to the message that you want to map.

    • Set the StatusCode attribute of RequestStatusCodeMBean to the integer to which you want to map the message that the session contains.

    See "Java MBeans Reference" for more information about these MBeans.

Triggering an Application

You can set up an application to run depending on the contents of the x-wcs-history header.

To evaluate the x-wcs-history header, you use the <Header> and <Content> elements. For example, the following code shows a scenario in which application sip:as1@192.168.1.140:5060 is triggered by the iFC whose <Priority> element is set to 1. The application returns an INVITE to the OE. (The example assumes that INVITE messages are mapped to 10 using OeHistoryMBean.)

Application sip:as2@192.168.1.141:5060 runs only if the x-wcs-history header of the message returned from the previous application is set as follows:

  • id=1

  • status=10

<iFCs>
  <InitialFilterCriteria>
    <Priority>1</Priority>
    <TriggerPoint>
      <ConditionTypeCNF>0</ConditionTypeCNF>
      <SPT>
        <ConditionNegated>0</ConditionNegated>
        <Group>0</Group>
        <Method>INVITE</Method>
      </SPT>
    </TriggerPoint>
  <ApplicationServer>
    <ServerName>sip:as1@192.168.1.140:5060</ServerName>
    <DefaultHandling>0</DefaultHandling>
  </ApplicationServer>
</InitialFilterCriteria>

<InitialFilterCriteria>
  <Priority>2</Priority>
  <TriggerPoint>
    <ConditionTypeCNF>0</ConditionTypeCNF>
    <SPT>
      <SIPHeader>
        <Header>x-wcs-history</Header>
        <Content>id=1;status=10</Content>
      </SIPHeader>
      <ConditionNegated>0</ConditionNegated>
      <Group>0</Group>
    </SPT>
  </TriggerPoint>
  <ApplicationServer>
    <ServerName>sip:as2@192.168.1.141:5060</ServerName>
    <DefaultHandling>0</DefaultHandling>
    </ApplicationServer>
  </InitialFilterCriteria>
</IFCs>

Merging Conditional Routes

If you build an orchestration logic in which the OE routes the session to different applications based on certain conditions, you can merge different conditional routes after they passed the respective applications.

For example, you can build an orchestration logic that routes the session to an IM-ASF if the condition is met or to an IM-OCF if the condition is not met. After the session passed the IM-ASF or IM-ASF, the OE routes the session to IM-WS.

You specify the applications from which you want to merge conditional routes by defining the value of the <Priority> element of the iFC that triggered the application. The OE stores the value of <Priority> in the id parameter of the x-wcs-history header. Therefore, for each application from which you want to merge the route, you need to create an SPT that checks whether the x-wcs-history contains a specific id.

The following example contains the definitions for the following applications:

<InitialFilterCriteria>
   <Priority>1</Priority>
   <TriggerPoint>      <ConditionTypeCNF>0</ConditionTypeCNF>
      <SPT>         <ConditionNegated>0</ConditionNegated>         <Group>0</Group> 
         <Method>INVITE</Method> 
      </SPT>
   </TriggerPoint>
   <ApplicationServer>
      <ServerName>sip:IM-ASF.IMASF@ocsb.com</ServerName>
      <DefaultHandling>0</DefaultHandling>
   </ApplicationServer></InitialFilterCriteria>

<InitialFilterCriteria>
   <Priority>2</Priority>
   <TriggerPoint>
      <ConditionTypeCNF>1</ConditionTypeCNF>
      <SPT>
         <ConditionNegated>1</ConditionNegated>
         <Group>0</Group>
         <Method>INVITE</Method>
      </SPT>
   </TriggerPoint>
   <ApplicationServer>
      <ServerName>sip:IM-OCF.IMOCF@ocsb.com</ServerName>
      <DefaultHandling>0</DefaultHandling>
   </ApplicationServer>
</InitialFilterCriteria>

<InitialFilterCriteria>
  <Priority>3</Priority>
   <TriggerPoint>
      <ConditionTypeCNF>1</ConditionTypeCNF>
      <SPT>
         <ConditionNegated>0</ConditionNegated>
         <Group>0</Group>
         <SIPHeader>
            <Header>x-wcs-history</Header>
            <Content>id=1;.*</Content>
         </SIPHeader>
      </SPT>
      <SPT>
         <ConditionNegated>0</ConditionNegated>
         <Group>0</Group>
         <SIPHeader>
            <Header>x-wcs-history</Header>
            <Content>id=2;.*</Content>
         </SIPHeader>
      </SPT>
   </TriggerPoint>
   <ApplicationServer>
      <ServerName>sip:IMWS.IMWS@ocsb.com</ServerName>
      <DefaultHandling>0</DefaultHandling>
   </ApplicationServer>
</InitialFilterCriteria>

Triggering Applications Based on the Previous Session Route

You can set up an application to run based on the previous route of the session. For example, you can set up a bill shock prevention application to run only if the session was previously routed to an online charging application based on the From header.

To enable applications in the orchestration chain to get the information about applications through which the session is routed, you need to tag the session when it passes through an application. For example, if the OE routes the session to an online billing application, you can tag the session with the tag OnlineBillingTriggered. This allows next applications in the orchestration chain to be aware of the online billing application was triggered.

Then you can set up one of the next applications in the chain (such as a bill shock prevention application) to run only if the session contains the OnlineBillingTriggered tag.

As the session passes through applications in the orchestration chain, all tags are accumulated. Therefore, any subsequent application in the orchestration chain can be aware of those tagged applications which were previously triggered.

The following sections explain how to tag a session and trigger an application only if the session contains the specified tags.

Note:

Service Broker does not support this feature when the Diameter-based orchestration mode is enabled. For more information on the Diameter-based orchestration mode, see the discussion on improving performance in Diameter-only environments in Oracle Communications Service Broker Online Mediation Controller Implementation Guide.

Tagging a Session

To tag a session, you use the <Tags> element. This element is an extension to the standard iFC. You need to place the <Tags> element under the <Extension> element.

You can add into <Tags> as many tags as you need. The tags must be separated by comma.

The following code shows a scenario in which the OE routes the session to an online billing application and tags the session with the OnlineBillingTriggered tag (the <Tags> element is bolded).

<iFCs>
  <InitialFilterCriteria>
    <Priority>1</Priority>
    <TriggerPoint>
      <ConditionTypeCNF>0</ConditionTypeCNF>
      <SPT>
        <ConditionNegated>0</ConditionNegated>
        <Group>0</Group>
        <SIPHeader>
          <Header>From</Header>
          <Content>"joe"</Content>
        </SIPHeader>
      </SPT>
    </TriggerPoint>
  <ApplicationServer>
    <ServerName>sip:as2@192.168.1.140:5060</ServerName>
    <DefaultHandling>0</DefaultHandling>
    <Extension>
      <Tags>OnlineBillingTriggered</Tags>
    </Extension>
  </ApplicationServer>
</InitialFilterCriteria>

The OE adds the contents of the <Tags> element to the x-wcs-tags header of the message that the OE routes to the next application in the orchestration chain. This header has the following format:

x-wcs-tags: comma_separated_tags_accumulated_from_all_previous_applications

The application returns the message to the OE with the x-wcs-tags header intact. As the message passes through applications in the orchestration chain, the x-wcs-tags header accumulates the contents of all <Tags> elements defined for applications in the chain.

Figure B-5 shows a scenario in which the OE routes a session from Application 1 to Application 2 to Application 3. The session is tagged as follows:

  • When the OE routes the to Application 1, the tag OnlineBillingTriggered is added.

  • When the OE routes the session to Application 2, the tag BillShockTriggered is added.

  • When the OE routes the session to Application 3, the tag RequiresAnchoring is added.

Because the x-wcs-tags header accumulates added tags, after triggering Application 3, the header contains "OnlineBillingTriggered, BillShockTriggered, RequiresAnchoring".

Figure B-5 Accumulating Session Tags

Accumulating Session Tags

Triggering an Application

You can set up an application to run depending on whether the x-wcs-tags header of the session contains specific tags.

To evaluate the x-wcs-tags header, you use the <Header> and <Content> elements. For example, the following code shows a scenario in which the session is tagged as follows:

  • When the OE routes the session to sip:as1@192.168.1.140:5060, the tag OnlineBillingTriggered is added.

  • When the OE routes the session to sip:as2@192.168.1.141:5060, the tag BillShockTriggered is added.

  • When the OE routes the session to sip:as2@192.168.1.141:5060, no tag is added.

The OE triggers sip:as3@192.168.1.143:5060 only if the x-wcs-tags header of the session contains both OnlineBillingTriggered and BillShockTriggered.

<iFCs>
  <InitialFilterCriteria>
    <Priority>1</Priority>
    <TriggerPoint>
      <ConditionTypeCNF>0</ConditionTypeCNF>
      <SPT>
        <ConditionNegated>0</ConditionNegated>
        <Group>0</Group>
        <Method>INVITE</Method>
      </SPT>
    </TriggerPoint>
  <ApplicationServer>
    <ServerName>sip:as1@192.168.1.140:5060</ServerName>
    <DefaultHandling>0</DefaultHandling>
    <Extension>
      <Tags>OnlineBillingTriggered</Tags>
    </Extension>
  </ApplicationServer>
</InitialFilterCriteria>

<InitialFilterCriteria>
  <Priority>2</Priority>
  <TriggerPoint>
    <ConditionTypeCNF>0</ConditionTypeCNF>
    <SPT>
      <ConditionNegated>0</ConditionNegated>
      <Group>0</Group>
      <SIPHeader>
        <Header>From</Header>
        <Content>"joe"</Content>
    </SPT>
  </TriggerPoint>
<ApplicationServer>
  <ServerName>sip:as2@192.168.1.141:5060</ServerName>
  <DefaultHandling>0</DefaultHandling>
    <Extension>
      <Tags>BillShockTriggered</Tags>
    </Extension>
</ApplicationServer>
</InitialFilterCriteria>

<InitialFilterCriteria>
  <Priority>3</Priority>
  <TriggerPoint>
    <ConditionTypeCNF>0</ConditionTypeCNF>
    <SPT>
      <ConditionNegated>0</ConditionNegated>
      <Group>0</Group>
      <Method>INVITE</Method>
    </SPT>
  </TriggerPoint>
<ApplicationServer>
  <ServerName>sip:as2@192.168.1.141:5060</ServerName>
  <DefaultHandling>0</DefaultHandling>
</ApplicationServer>
</InitialFilterCriteria>

<InitialFilterCriteria>
  <Priority>4</Priority>
  <TriggerPoint>
    <ConditionTypeCNF>0</ConditionTypeCNF>
    <SPT>
      <SIPHeader>
        <Header>x-wcs-tags</Header>
        <Content>OnlineBillingTriggered, BillShockTriggered</Content>
      </SIPHeader>
      <ConditionNegated>0</ConditionNegated>
      <Group>0</Group>
    </SPT>
  </TriggerPoint>
  <ApplicationServer>
    <ServerName>sip:as3@192.168.1.143:5060</ServerName>
    <DefaultHandling>0</DefaultHandling>
  </ApplicationServer>
  </InitialFilterCriteria>
</IFCs>

Java MBeans Reference

You can use OeHistoryMBean and its child MBeans to map a response message to an integer. For example, you can map an INVITE message to 10.

Figure B-6 shows the hierarchy of the OeHistoryMBean.

Figure B-6 OeHistoryMBean Hierarchy

OeHistoryMBean Hierarchy

OeHistoryMBean

OeHistoryMBean enables you to map a response message to an integer. For example, you can map an INVITE message to 10. This value is stored in the x-wcs-history header and enables you to check the status of a previous application in the orchestration chain. See "Triggering Applications Based on the Status of the Previous Application" for more information.

Object Name

com.convergin:Type=OEHistory,Version=MBean_Version,Location=AdminServer,Name=oe_instance.OE_oe_instance_MBean_Version

Factory Method

Created automatically.

Attributes

int DefaultRequestStatusCode

Specifies the default value of the status_code parameter that the OE receives in the x-wcs-history header.

Operations

ObjectName createRequestStatusCodes()

Creates an instance of RequestStatusCodesMBean.

void destroyRequestStatusCodes()

Destroys an instance of RequestStatusCodesMBean.

ObjectName[] lookupRequestStatusCodes()

Gets an array of references to the instances of RequestStatusCodesMBean.

RequestStatusCodesMBean

RequestStatusCodesMBean is the root MBean for instances of RequestStatusCodeMBean. Each instance of RequestStatusCodeMBean enables you to map a single response to an integer.

Object Name

com.convergin:Type=RequestStatusCodes,Version=MBean_Version,Location=AdminServer,Name=oe_instance.OE_oe_instance_MBean_Version

Factory Method

OeHistory.createRequestStatusCodes()

Attributes

None

Operations

ObjectName createRequestStatusCode()

Creates an instance of RequestStatusCodeMBean.

void destroyRequestStatusCode()

Destroys an instance of RequestStatusCodeMBean.

ObjectName[] lookupRequestStatusCode()

Gets an array of references to the instances of RequestStatusCodeMBean.

RequestStatusCodeMBean

RequestStatusCodeMBean enables you to map a single response to an integer. You need to create a separate instance of RequestStatusCodeMBean for each response.

Object Name

com.convergin:Type=RequestStatusCode,Version=MBean_Version,Location=AdminServer,Name=oe_instance.String

Factory Method

RequestStatusCodes.createRequestStatusCode()

Attributes

string Request

Specifies the message that the session contains.

int StatusCode

Specifies the integer to which you want to map the message that the session contains.

Operations

None

Go to previous page
Previous
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Feedback page
Contact Us