This chapter describes how to configure SIP container features in the engine of an Oracle Communications WebRTC Session Controller deployment.
Loading SIP applications to the WebRTC Session Controller in the Administration Console is similar to loading any application to WebLogic server. You use the Deployments page in the Administration Console to load, update, or remove an application or module.
The WebRTC Session Controller defines general settings that apply to all SIP applications. Before deploying applications to the WebRTC Session Controller, you should verify and modify the default values for the general settings. You can configure the general settings in the SIP Server page of the Administration Console.
To configure general SIP application server properties:
Open the Administration Console for your domain.
Click the SipServer link in the Domain Structure pane.
The right pane of the console provides two levels of tabbed pages that are used for configuring and monitoring WebRTC Session Controller. By default, the General configuration page appears.
Use the fields in the General subtab of the Configuration tab 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 in the Administration Console.
Click Save to save your configuration changes.
Click Activate Changes to apply your changes to the engine servers.
WebRTC Session Controller instances configured as replicated domains include the default BEA_ENGINE_TIER_CLUST cluster for the signaling engine servers. You can assign additional managed servers to each cluster as needed when performance requirements in your environment require them.
See WebLogic Server Administration Console Online Help for information on how to "Assign servers to clusters".
For more information on clustering, see "Understanding WebLogic Server Clustering" in Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.
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 server poll 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.
With the default timer processing mechanism, a given engine server 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. WebRTC Session Controller 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:
Access the Administration Console for your domain.
Select the SipServer node in the left pane. The right pane of the console provides two levels of tabbed pages that are used for configuring and monitoring WebRTC Session Controller.
Select the Configuration, then General tab in the right pane.
Select the box for Enable Timer Affinity.
Click Save to save your configuration changes.
Click Activate 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.
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 WebRTC Session Controller 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.