Oracle WebLogic Server SIP Container 11g (OWLSC) is a comprehensive platform designed to integrate communication services with enterprise services and applications. It includes easy to consume services to support interactions with key communication channels.
Table 1-1 shows a simplified overview of Oracle WebLogic Server SIP Container; more details will be presented in later chapters.
OWLSC extends the core WebLogic Server platform with a SIP Container compliant with JSR 289. This enables the development of J2EE applications that processes SIP in addition to HTTP for any advanced communications application. The platform enables the development of complementary communications services that integrate with SIP-based IP-PBXs as well as other SIP elements such as standard SIP clients.
Out of the box, OWLSC provides the key infrastructure applications to build a SIP-based network.
The following sections provide an overview of the configuration tasks that are common to both Oracle WebLogic SIP Container and Oracle WebLogic Server. These topics are included:
Oracle WebLogic Server SIP Container is based on the Oracle WebLogic Server 10g Release 3 application server, and many system-level configuration tasks are the same for both products. This guide addresses only those system-level configuration tasks that are unique to Oracle WebLogic Server SIP Container, such as tasks related to network and security configuration and cluster configuration for the engine and SIP data tiers.
HTTP server configuration and other basic configuration tasks such as server logging are addressed in Oracle WebLogic Server documentation. See Oracle Fusion Middleware Getting Started With Installation for Oracle WebLogic Server to get started.
The SIP Servlet container, SIP data tier replication, and Diameter protocol features of Oracle WebLogic Server SIP Container are implemented in the Oracle WebLogic Server 10g Release 3 product as custom resources. A pair of custom resources,
datatier, implement the engine tier SIP Servlet container functionality and SIP data tier replication functionality. In production deployments, both resources are generally installed. Specialized deployments may use only the
sipserver resource in conjunction with a SIP-aware load balancer.
The Oracle WebLogic SIP Container custom resource assignments are visible in the domain configuration file,
config.xml, and should not be modified. Example 1-1 shows the definitions for each resource. Note that the
datatier resources must each be targeted to the same servers or clusters; the resources are deployed to both the engine tier and SIP data tier cluster.
<custom-resource> <name>sipserver</name> <target>ORA_DATA_TIER_CLUST,ORA_ENGINE_TIER_CLUST</target> <descriptor-file-name>custom/sipserver.xml</descriptor-file-name> <resource-class>com.bea.wcp.sip.management.descriptor.resource.SipServerResource</resource-class> <descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.SipServerBean</descriptor-bean-class> </custom-resource> <custom-resource> <name>datatier</name> <target>ORA_DATA_TIER_CLUST,ORA_ENGINE_TIER_CLUST</target> <descriptor-file-name>custom/datatier.xml</descriptor-file-name> <resource-class>com.bea.wcp.sip.management.descriptor.resource.DataTierResource</resource-class> <descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.DataTierBean</descriptor-bean-class> </custom-resource> <custom-resource> <name>diameter</name> <target>ORA_ENGINE_TIER_CLUST</target> <deployment-order>200</deployment-order> <descriptor-file-name>custom/diameter.xml</descriptor-file-name> <resource-class>com.bea.wcp.diameter.DiameterResource</resource-class> <descriptor-bean-class>com.bea.wcp.diameter.management.descriptor.beans.ConfigurationBean</descriptor-bean-class> </custom-resource>
The Oracle WebLogic Server SIP Container custom resources utilize the basic domain resources defined in
config.xml, such as network channels, cluster and server configuration, and Java EE resources. However, Oracle WebLogic Server SIP Container-specific resources are configured in separate configuration files based on functionality:
sipserver.xml configures SIP container properties and general Oracle WebLogic Server SIP Container engine tier functionality.
datatier.xml identifies servers that participate as replicas in the SIP data tier, and also defines the number and layout of SIP data tier partitions.
diameter.xml configures Diameter nodes and Diameter protocol applications used in the domain.
Keep in mind that the domain configuration file,
config.xml, defines all of the Managed Servers available in the domain. The
diameter.xml configuration files included in the
sipserver application determine the role of each server instance, such as whether they behave as SIP data tier replicas, engine tier nodes, or Diameter client nodes.
Configuration changes to SIP Servlet container properties can be applied dynamically (some SIP Servlet container properties may display a Restart may be required icon meaning that restart after making the change will be required) to a running server by using the Administration Console, or from the command line using the WLST utility. Configuration for SIP data tier nodes cannot be changed dynamically, so you must reboot SIP data tier servers in order to change the number of partitions or replicas.
The Diameter protocol implementation is implemented as a custom resource separate from the SIP Servlet container functionality. The Diameter configuration file configures one or more Diameter protocol applications to provide Diameter node functionality. Oracle WebLogic Server SIP Container provides the Diameter protocol applications to support the following node types:
Diameter Sh interface client node (for querying a Home Subscriber Service)
Diameter Rf interface client node (for offline charging)
Diameter Ro interface client node (for online charging)
Diameter relay node
HSS simulator node (suitable for testing and development only, not for production deployment)
The Diameter custom resource is deployed only to domains having servers that must function as Diameter client nodes or relay agents, or to servers providing HSS simulation capabilities. The actual function of the server instance depends on the configuration defined in the
See Chapter 6, "Configuring Diameter Client Nodes and Relay Agents" for instructions to configure the Diameter Web Application in an Oracle WebLogic Server SIP Container domain. See Oracle WebLogic Server SIP Container Developer's Guide for information on developing Diameter applications.
Oracle WebLogic Server SIP Container provides several mechanisms for changing the configuration of the SIP Servlet container:
Oracle WebLogic Server SIP Container provides Administration Console extensions that allow you to modify and SIP Servlet container, SIP Servlet domain, and Diameter configuration properties using a graphical user interface. The Administration Console extensions for Oracle WebLogic Server SIP Container are similar to the core console available in Oracle WebLogic Server 10g Release 3. All Oracle WebLogic Server SIP Container configuration and monitoring is provided via these nodes in the left pane of the console:
SipServer—configures SIP Servlet container properties and other engine tier functionality. This extension also enables you to create new partitions, and view (but not modify) SIP data tier partitions and replicas. See Chapter 2, "Configuring SIP Servlet Container Properties" for more information about configuring the SIP Servlet container using the Administration Console.
Diameter—configures Diameter nodes and applications.
Note:To learn more about using Oracle WebLogic Server Administration Console, see "Getting Started with Oracle WebLogic Server Administration Console" in Oracle Fusion Middleware Administrator's Guide.
The WebLogic Scripting Tool (WLST) enables you to perform interactive or automated (batch) configuration operations using a command-line interface. WLST is a JMX tool that can view or manipulate the MBeans available in a running Oracle WebLogic Server SIP Container domain. Chapter 2, "Configuring SIP Servlet Container Properties" provides instructions for modifying SIP Servlet container properties using WLST.
Note:To learn more about using WLST, see Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Most Oracle WebLogic Server SIP Container configuration is performed using either the Administration Console or WLST. The methods described in the following sections may also be used for certain configuration tasks.
You may also edit
diameter.xml, and approuter.xml manually. If you edit configuration files manually, you must reboot all servers to apply the configuration changes.
Oracle WebLogic Server SIP Container properties are represented by JMX-compliant MBeans. You can therefore program JMX applications to configure SIP container properties using the appropriate Oracle WebLogic Server SIP Container MBeans.
The general procedure for modifying Oracle WebLogic Server SIP Container MBean properties using JMX is described in Chapter 2, "Configuring SIP Servlet Container Properties" (WLST itself is a JMX-based application). For more information about the individual MBeans used to manage SIP container properties, see the Oracle Fusion Middleware Communication Services Java API Reference.
Oracle WebLogic Server SIP Container start scripts use default values for many JVM parameters that affect performance. For example, JVM garbage collection and heap size parameters may be omitted, or may use values that are acceptable only for evaluation or development purposes. In a production system, you must rigorously profile your applications with different heap size and garbage collection settings in order to realize adequate performance.
Caution:When you configure a domain with multiple engine and SIP data tier servers, you must accurately synchronize all system clocks to a common time source (to within one or two milliseconds) in order for the SIP protocol stack to function properly.
Because a typical Oracle WebLogic Server SIP Container domain contains numerous engine and SIP data tier servers, with dependencies between the different server types, you should generally follow this sequence when starting up a domain:
Start the Administration Server for the domain. Start the Administration Server in order to provide the initial configuration to engine and SIP data tier servers in the domain. The Administration Server can also be used to monitor the startup/shutdown status of each Managed Server. You generally start the Administration Server by using either the
startWebLogic.cmd script installed with the Configuration Wizard, or a custom startup script.
Start SIP data tier servers in each partition. The engine tier cannot function until servers in the SIP data tier are available to manage call state data. Although all replicas in each partition need not be available to begin processing requests, at least one replica in each configured partition must be available in order to manage the concurrent call state. All replicas should be started and available before opening the system to production network traffic.
You generally start each SIP data tier server by using either the
startManagedWebLogic.cmd script installed with the Configuration Wizard, or a custom startup script.
startManagedWebLogic.cmd requires that you specify the name of the server to startup, as well as the URL of the Administration Server for the domain, as in:
startManagedWebLogic.cmd datanode0-0 t3://adminhost:7001
Start engine tier servers. After the SIP data tier servers have started, you can start servers in the engine tier and begin processing client requests. As with SIP data tier servers, engine tier servers are generally started using the
startManagedWebLogic.cmd script or a custom startup script.
Following the above startup sequence ensures that all Managed Servers use the latest SIP Servlet container and SIP data tier configuration. This sequence also avoids engine tier error messages that are generated when servers in the SIP data tier are unavailable.
Note:If an Administration Server fails due to a hardware, software, or network problem, only management, deployment, and monitoring operations are affected. Managed Servers do not require the Administration Server for continuing operation; Java EE applications and SIP features running on Managed Server instances continue to function even if the Administration Server fails.
Oracle recommends the following best practices for configuring Administration Server and Managed Server instances in your Oracle WebLogic Server SIP Container domain:
Run the Administration Server instance on a dedicated machine. The Administration Server machine should have a memory capacity similar to Managed Server machines, although a single CPU is generally acceptable for administration purposes.
Configure all Managed Server instances to use Managed Server Independence. This feature allows the Managed Servers to restart even if the Administration Server is unreachable due to a network, hardware, or software failure. See Oracle Fusion Middleware Managing Server Startup and Shutdown for Oracle WebLogic Server for more information.
Configure the Node Manager utility to automatically restart all Managed Servers in the Oracle WebLogic Server SIP Container domain. See Oracle Fusion Middleware Oracle WebLogic Scripting Tool for more information.
Should an Administration Server instance or machine fail, remember that only configuration, deployment, and monitoring features are affected, but Managed Servers continue to operate and process client requests. Potential losses incurred due to an Administration Server failure include:
Loss of in-progress management and deployment operations.
Loss of ongoing logging functionality.
Loss of SNMP trap generation for WebLogic Server instances (as opposed to Oracle WebLogic Server SIP Container instances). On Managed Servers, Oracle WebLogic Server SIP Container traps are generated even in the absence of the Administration Server.
To resume normal management activities, restart the failed Administration Server instance as soon as possible.
General administration and maintenance of Oracle WebLogic Server SIP Container requires that you manage both WebLogic Server configuration properties and Oracle WebLogic Server SIP Container container properties. These common configuration tasks are summarized in Table 1-1.