> Configuration Guide > Storing Long-Lived Call State Data in an RDBMS

Configuration Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Storing Long-Lived Call State Data in an RDBMS

The following sections describe how to configure a WebLogic SIP Server domain to use an Oracle or MySQL RDBMS with the data tier cluster, in order to conserve RAM:

 

Overview of Long-Lived Call State Storage

WebLogic SIP Server enables you to store long-lived call state data in an Oracle or MySQL RDBMS in order to conserve RAM. When you enable RDBMS persistence, by default the data tier persists a call state’s data to the RDBMS after the call dialog has been established, and at subsequent dialog boundaries, retrieving or deleting the persisted call state data as necessary to modify or remove the call state.

BEA also provides an API for application designers to provide “hints” as to when the data tier should persist call state data. These hints can be used to persist call state data to the RDBMS more frequently, or to disable persistence for certain calls. See

Note that WebLogic SIP Server only uses the RDBMS to supplement the data tier’s in-memory replication functionality. To improve latency performance when using an RDBMS, the data tier maintains SIP timers in memory, along with call states being actively modified (for example, in response to a new call being set up). Call states are automatically persisted only after a dialog has been established and a call is in progress, at subsequent dialog boundaries, or in response to persistence hints added by the application developer.

When used in conjunction with an RDBMS, the data tier selects one replica server instance to process all call state writes (or deletes) to the database. Any available replica can be used to retrieve call states from the persistent store as necessary for subsequent reads.

RDBMS call state storage can be used in combination with an engine tier cache, if your domain uses a SIP-aware load balancer to manage connections to the engine tier. See Using the Engine Tier Cache.

 

Requirements and Restrictions

Enable RDBMS call state storage only when all of the following criteria are met:

The latency requirement, in particular, must be well understood before choosing to store call state data in an RDBMS. The RDBMS call state storage option measurably increases latency for SIP message processing, as compared to using a data tier cluster. If your system must handle a large number of short-lived SIP transactions with brief response times, BEA recommends storing all call state data in the data tier.

Note: RDBMS persistence is designed only to reduce the RAM requirements in the data tier for large, long-lived call states. The persisted data cannot be used to restore a failed data tier partition or replica.

 

Steps for Enabling RDBMS Call State Storage

In order to use the RDBMS call state storage feature, your WebLogic SIP Server domain must include the necessary JDBC configuration, SIP Servlet container configuration, and a database having the schema required to store the call state. You can automate much of the required configuration by using the Configuration Wizard to set up a new domain with the RDBMS call state template. See Using the Configuration Wizard RDBMS Store Template.

If you have an existing WebLogic SIP Server domain, or you want to configure the RDBMS store on your own, see Configuring RDBMS Call State Storage by Hand for instructions to configure JDBC and WebLogic SIP Server to use an RDBMS store.

 

Using the Configuration Wizard RDBMS Store Template

The Configuration Wizard provides a simple template that helps you easily begin using and testing the RDBMS call state store. Follow these steps to create a new domain from the template:

  1. Start the Configuration Wizard application:
    2. cd ~/bea/sipserver30	/common/bin
    ./config.sh
  2. Accept the default selection, Create a new WebLogic domain, and click Next.
  3. Select Base this domain on an existing template, and click Browse to display the Select a Template dialog.
  4. Select the template named replicateddomain.jar, and click OK.
  5. Click Next.
  6. Enter the username and password for the Administrator of the new domain, and click Next.
  7. Select a JDK to use, and click Next.
  8. Select No to keep the settings defined in the source template file, and click Next.
  9. Click Create to create the domain.

    10. The template creates a new domain with two engine tier servers in a cluster, two data tier servers in a cluster, and an Administration Server (AdminServer). The engine tier cluster includes the following resources and configuration:

    • A JDBC datasource, wlss.callstate.datasource, required for storing long-lived call state data. Note that you must modify this configuration to configure the datasource for your own RDBMS server. See Modify the JDBC Datasource Connection Information.
    • A persistence configuration (shown in the SipServer node, Configuration->Persistence tab of the Administration Console) that defines default handling of persistence hints for both RDBMS and geographical redundancy.
  10. Click Done to exit the configuration wizard.
  11. Follow the steps under Modify the JDBC Datasource Connection Information to create the necessary tables in your RDBMS.
  12. Follow the steps under Create the Database Schema to create the necessary tables in your RDBMS.

Modify the JDBC Datasource Connection Information

After installing the new domain, modify the template JDBC datasource to include connection information for your RDBMS server:

  1. Use your browser to access the URL http://address:port/console where address is the Administration Server’s listen address and port is the listen port.
  2. Click Lock & Edit to obtain a configuration lock.
  3. Select the Services->JDBC->Data Sources tab in the left pane.
  4. Select the data source named wlss.callstate.datasource in the right pane.
  5. Select the Configuration->Connection Pool tab in the right pane.
  6. Modify the following connection pool properties:
    • URL: Modify the URL to specify the hostname and port number of your RDBMS server.
    • Properties: Modify the value of the user, portNumber, SID, and serverName properties to match the connection information for your RDBMS.
    • Password and Confirm Password: Enter the password of the RDBMS user you specified.
  7. Click Save to save your changes.
  8. Select the Targets tab in the right pane.
  9. On the Select Targets page, select the name of your data tier cluster (for example, BEA_DATA_TIER_CLUST), then click Save.
  10. Click Activate Changes to apply the configuration.
  11. Follow the steps under Create the Database Schema to create the necessary tables in your RDBMS.

 

Configuring RDBMS Call State Storage by Hand

To change an existing WebLogic SIP Server domain to store call state data in an Oracle or MySQL RDBMS, you must configure the required JDBC datasource, edit the WebLogic SIP Server configuration, and add the required schema to your database. Follow the instructions in the sections below to configure an Oracle Database.

Configure JDBC Resources

Follow these steps to create the required JDBC resources in your domain:

  1. Boot the Administration Server for the domain if it is not already running.
  2. Access the Administration Console for the domain.
  3. Click Lock & Edit to obtain a configuration lock.
  4. Select the Services->JDBC->Data Sources tab in the left pane.
  5. Click New to create a new data source.
  6. Fill in the fields of the Create a New JDBC Data Source page as follows:
    • Name: Enter wlss.callstate.datasource
    • JNDI Name: Enter wlss.callstate.datasource.
    • Database Type: Select “Oracle.”
    • Database Driver: Select an appropriate JDBC driver from the Database Driver list. Note that some of the drivers listed in this field may not be installed by default on your system. Install third-party drivers as necessary using the instructions from your RDBMS vendor.
  7. Click Next:
  8. Fill in the fields of the Connection Properties tab using connection information for the database you wan to use. Click Next to continue.
  9. Click Test Driver Configuration to test your connection to the RDBMS, or click Next to continue.
  10. On the Select Targets page, select the name of your data tier cluster (for example, BEA_DATA_TIER_CLUST), then click Finish.
  11. Click Save to save your changes.
  12. Click Activate Changes to apply the configuration.

Configure WebLogic SIP Server Persistence Options

Follow these steps to configure the WebLogic SIP Server persistence options to use an RDBMS call state store:

  1. Boot the Administration Server for the domain if it is not already running.
  2. Access the Administration Console for the domain.
  3. Click Lock & Edit to obtain a configuration lock.
  4. Select the SipServer node in the left pane.
  5. Select the Configuration->Persistence tab in the right pane.
  6. In the Default Handling drop-down menu, select either “db” or “all.” It is acceptable to select “all” because geographically-redundant replication is only performed if the Geo Site ID and Geo Remote T3 URL fields have been configured.
  7. Click Save to save your changes.
  8. Click Activate Changes to apply the configuration.

Create the Database Schema

WebLogic SIP Server includes a SQL script, callstate.sql, that you can use to create the tables necessary for storing call state information. The script is installed to the user_staged_config subdirectory of the domain directory when you configure a replicated domain using the Configuration Wizard. The script is also available in the WLSS_HOME/common/templates/scripts/db/oracle directory.

The contents of the callstate.sql SQL script are shown in Listing 4-1.

Listing 4-1 callstate.sql Script for Call State Storage Schema 
drop table callstate;
create table callstate (
  key1 int,
  key2 int,
  bytes blob default empty_blob(),
  constraint pk_callstate primary key (key1, key2)
);

Follow these steps to execute the script commands using SQL*Plus:

  1. Move to the WebLogic SIP Server utils directory, in which the SQL Script is stored:
    2. cd ~/bea/sipserver30/common/templates/scripts/db/oracle
  2. Start the SQL*Plus application, connecting to the Oracle database in which you will create the required tables. Use the same username, password, and connect to the same database that you specified when configuring the JDBC driver in Configure JDBC Resources. For example:
    3. sqlplus username/password@connect_identifier

    where connect_identifier connects to the database identified in the JDBC connection pool.

  3. Execute the WebLogic SIP Server SQL script, callstate.sql:
    4. START callstate.sql
  4. Exit SQL*Plus:
    5. EXIT

 

Using Persistence Hints in SIP Applications

WebLogic SIP Server provides a simple API to provide “hints” as to when the data tier should persist call state data. You can use the API to disable persistence for specific calls or SIP requests, or to persist data more frequently than the default setting (at SIP dialog boundaries).

To use the API, simply obtain a WlssSipApplicationSession instance and use the setPersist method to enable or disable persistence. Note that you can enable or disable persistence either to an RDBMS store, or to as geographically-redundant WebLogic SIP Server installation (see Configuring Geographically- Redundant Installations).

For example, some SIP-aware load balancing products use the SIP OPTIONS message to determine if a SIP Server is active. To avoid persisting these messages to an RDBMS and to a geographically-redundant site, a Servlet might implement a doOptions method to echo the request and turn off persistence for the message, as shown in Listing 4-2.

Listing 4-2 Disabling RDBMS Persistence for Option Methods 
protected void doOptions(SipServletRequest req) throws IOException {
    WlssSipApplicationSession session =
      (WlssSipApplicationSession) req.getApplicationSession();
    session.setPersist(WlssSipApplicationSession.PersistenceType.DATABASE,
      false);
    session.setPersist(WlssSipApplicationSession.PersistenceType.GEO_REDUNDANCY, false);
    req.createResponse(200).send();
}

  Back to Top       Previous  Next