Configuring Converged Application Server Container Properties

This section describes how to configure SIP container features in the engine of an Oracle Communications Converged Application Server deployment.

Configure General SIP Application Server Properties

Loading SIP applications to the Converged Application Server in the Remote Console is similar to loading any application to WebLogic server. You use the Deployments node in the Edit Tree to load, update, or remove an application or module.

The Converged Application Server defines general settings that apply to all SIP applications. Before deploying applications to the Converged Application Server, you should verify and if necessary modify the default values for the general settings.

  1. In the Edit Tree, click Custom Resources, and then sipserver, and then SIP Server.
  2. Use the fields in the General subtab to configure the general settings applicable to serving SIP applications.

    Among the settings that determine common application handling are:

    • The default servlet invoked if a specific servlet is not identified for a request based on the servlet mapping rules.
    • Timer values. See "Configuring Timer Processing" for more information.
    • Header handling settings.
    • Application session settings.

    For details, see the on-screen field descriptions.

  3. Click Save to save your configuration changes.
  4. Click the shopping cart and then Commit Changes.
  5. Restart the server.

Adding Servers to the Cluster

If you have configured a replicated domain using the domain configuration wizard, Converged Application Server instances include the default BEA_ENGINE_TIER_CLUST cluster. You can assign additional managed servers to each cluster as needed when performance requirements in your environment require them.

For more information on clustering, see Understanding WebLogic Server Clustering in Administering Clusters for Oracle WebLogic Server.

Configuring Timer Processing

As engine servers add new call state data to the SIP call-state store, they maintain data structures to track the SIP protocol timers and application timers associated with each call. Engine servers periodically poll the SIP Coherence call-state store to determine which timers have expired, given the current time. By default, multiple engine polls to the call-state store are staggered to avoid contention on the timer tables. Engine servers then process all expired timers using threads allocated in the wlss.timer work manager.

Configuring Timer Affinity (Optional)

With the default timer processing mechanism, a given engine processes all timers that are currently due to fire, regardless of whether that engine was involved in processing the calls associated with those timers. However, some deployment scenarios require that a timer is processed on the same engine server that last modified the call associated with that timer. One example of this scenario is a hot standby system that maintains a secondary engine that should not process any call data until another engine fails. Converged Application Server enables you to configure timer affinity in such scenarios.

When you enable timer affinity, each engine server periodically polls the SIP call-state store for processed timers. When polling the SIP call-state store, an engine processes only those timers associated with calls that were last modified by that engine, or timers for calls that have no owner.

Note:

When an engine server fails, any call states that were last modified by that engine no longer have an owner. Expired timers that have no owner are processed by the next engine server that polls the SIP call-state store.

To enable timer affinity:

  1. From the Edit Tree of the Remote Console, select Custom Resources, and then sipserver, and then SIP Server
  2. Toggle the slider for Enable Timer Affinity.
  3. Click Save to save your configuration changes.
  4. Click the shopping cart and then Commit Changes to apply your changes to the engine servers.

The Enable Timer Affinity setting is persisted in sipserver.xml in the enable-timer-affinity element.

Configuring NTP for Accurate SIP Timers

In order for the SIP protocol stack to function properly, all engine servers must accurately synchronize their system clocks to a common time source, to within one or two milliseconds. Large differences in system clocks cause severe problems such as:

  • SIP timers firing prematurely on servers with fast clock settings.

  • Poor distribution of timer processing among engine servers. For example, one engine server might process all expired timers, whereas other engine servers process no timers.

Oracle recommends using a Network Time Protocol (NTP) client or daemon on each Converged Application Server instance and synchronizing to a common NTP server.

Caution:

You must accurately synchronize server system clocks to a common time source (to within one or two milliseconds) in order for the SIP protocol stack to function properly. Because the initial T1 timer value of 500 milliseconds controls the retransmission interval for INVITE request and responses, and also sets the initial values of other timers, even small differences in system clock settings can cause improper SIP protocol behavior. For example, an engine server with a system clock 250 milliseconds faster than other servers will process more expired timers than other engine servers, will cause retransmits to begin in half the allotted time, and may force messages to time out prematurely.