The following sections provide an overview of the configuration tasks that are common to both Oracle WebLogic Communication Services and Oracle WebLogic Server. These topics are included:
Section 2.2, "Oracle WebLogic Communication Services Configuration Overview"
Section 2.3, "Methods and Tools for Performing Configuration Tasks"
Oracle WebLogic Communication Services 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 Communication Services, 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 Communication Services are implemented in the Oracle WebLogic Server 10g Release 3 product as custom resources. A pair of custom resources, sipserver and 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, as described in Section 15.7, "Alternate Configurations".
Another custom resource, diameter, provides Diameter base protocol functionality, and is required only for deployments that utilize one or more Diameter protocol applications.
The Oracle WebLogic Communication Services custom resource assignments are visible in the domain configuration file, config.xml, and should not be modified. Example 2-1 shows the definitions for each resource. Note that the sipserver and datatier resources must each be targeted to the same servers or clusters; in Example 2-1, the resources are deployed to both the engine tier and SIP data tier cluster.
Example 2-1 Oracle WebLogic Communication Services Custom Resources
<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 Communication Services 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 Communication Services-specific resources are configured in separate configuration files based on functionality:
sipserver.xml configures SIP container properties and general Oracle WebLogic Communication Services 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.
approuter.xml configures Default Application Router. For more information on configuring DAR, see Oracle WebLogic Communication Services Installation Guide.
Keep in mind that the domain configuration file, config.xml, defines all of the Managed Servers available in the domain. The sipserver.xml, datatier.xml, and 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 Communication Services 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 diameter.xml file.
See Section 10.2, "Steps for Configuring Diameter Client Nodes and Relay Agents" in Configuring Network Resources for instructions to configure the Diameter Web Application in an Oracle WebLogic Communication Services domain. See Oracle WebLogic Communication Services Developer's Guide for information on developing Diameter applications.
Oracle WebLogic Communication Services provides several mechanisms for changing the configuration of the SIP Servlet container:
Oracle WebLogic Communication Services 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 Communication Services are similar to the core console available in Oracle WebLogic Server 10g Release 3. All Oracle WebLogic Communication Services 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 Section 3.1, "Overview of SIP Container Configuration" 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 Communication Services domain. Section 3.1, "Overview of SIP Container Configuration" 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 Communication Services 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 sipserver.xml, datatier.xml, diameter.xml, and approuter.xml manually. If you edit configuration files manually, you must reboot all servers to apply the configuration changes.
Oracle WebLogic Communication Services properties are represented by JMX-compliant MBeans. You can therefore program JMX applications to configure SIP container properties using the appropriate Oracle WebLogic Communication Services MBeans.
The general procedure for modifying Oracle WebLogic Communication Services MBean properties using JMX is described in Section 3.3, "Configuring Container Properties Using WLST (JMX)" (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.
You can set log levels by manually editing the logging.xml file, by setting the setLoggerLevel(String loggerName, String logLevel) MBean, or through Oracle Enterprise Manager. For more information, see Section 12.2.1, "Configuring Logging". See also Oracle Fusion Middleware 2 Day Administration Guide.
Oracle WebLogic Communication Services 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. See Section 8.8, "Tuning JVM Garbage Collection for Production Deployments" for suggestions about maximizing JVM performance in a production domain.
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. See Section 3.5.2, "Configuring NTP for Accurate SIP Timers" for more information.Because a typical Oracle WebLogic Communication Services 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.
The Administration Server in a Oracle WebLogic Communication Services installation is required for configuring, deploying, and monitoring services and applications.
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 Communication Services 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 Communication Services 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 Communication Services instances). On Managed Servers, Oracle WebLogic Communication Services 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 Communication Services requires that you manage both WebLogic Server configuration properties and Oracle WebLogic Communication Services container properties. These common configuration tasks are summarized in Table 2-1.
Table 2-1 Common Oracle WebLogic Communication Services Configuration Tasks
| Task | Description |
|---|---|
|
|
|
Chapter 6, "Configuring SIP Data Tier Partitions and Replicas" |
|
|
|
|
|
|