Client Connections Introduction to OWLCS Enterprise Deployment Topology

Deployment Topologies for Communication Services 16-11 shows the datatier.xml configuration file used to define a system having two partitions with two servers replicas in each partition. Example 16–3 SIP State Tier Configuration for Small Deployment ?xml version=1.0 encoding=UTF-8? data-tier xmlns=http:.... partition namePartition0name server-nameDataNode0-0server-name server-nameDataNode0-1server-name partition partition namePartition1name server-nameDataNode1-0server-name server-nameDataNode1-1server-name partition data-tier

16.3.1.8 Storing Long-Lived Call State Data in an RDBMS

Oracle WebLogic Communication Services enables you to store long-lived call state data in an Oracle RDBMS in order to conserve RAM. When you enable RDBMS persistence, by default the SIP state tier persists a call states 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. Oracle also provides an API for application designers to provide hints as to when the SIP state 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. Oracle WebLogic Communication Services can use the RDBMS to supplement the SIP state tiers in-memory replication functionality. To improve latency performance when using an RDBMS, the SIP state 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 SIP state tier the term state tier is used interchangeably with data tier in this document 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.

16.3.2 Geographic Redundancy

Geographic Redundancy ensures uninterrupted transactions and communications for providers, using geographically-separated SIP server deployments. A primary site can process various SIP transactions and communications and upon determining a transaction boundary, replicate the state data associated with the transaction being processed, to a secondary site. Upon failure of the primary site, calls are routed from the failed primary site to a secondary site for processing. Similarly, upon recovery, the calls are re-routed back to the primary site. See Oracle WebLogic Communication Services Administrator’s Guide for more information 16-12 Oracle WebLogic Communications Server Administration Guide Figure 16–6 Geo-Redundancy In the preceding figure, Geo-Redundancy is portrayed. The process proceeds in this manner:

1. Call is initiated on a primary Cluster site, call setup and processing occurs

normally.

2. Call is replicated as usual to the sites SIP State Tier, and becomes eligible for

replication to a secondary site.

3. A single replica in the SIP State Tier then places the call state data to be replicated

on a JMS queue configured on a replica site.

4. Call is transmitted to one of the available engines using JMS over WAN.

5. Engines at the secondary site monitor their local queue for new messages. Upon

receiving a message, an Engine in the secondary site persists the call state data and assigns it the site ID value of the primary site.

16.3.3 Failover

Oracle’s High Availability solutions include failover support for all levels of your system. During failover, the functions of a component that is malfunctioning or non-operational are addressed by a standby or replacement component. This is done without manual intervention, and in most cases end users will not be able to detect that the system is taking failover actions. There are two main types of failover: Session Failover and Service Failover. Session Failover occurs when the session, connection, or power are interrupted. During Session Failover, ongoing calls or requests are handled by backup nodes, and users do not detect that the condition arose. The SIP Container provides services to upper-levels to help recover from session failure. The SIP protocol rebuilds state at certain pre-defined times for example, every hour. This is designed to protect unreliable networks. When Service Failover occurs such as when a node in a cluster of nodes goes down, the load is handled by other nodes in the cluster. If an individual request is being processed at the time, it will fail, but subsequent requests will be picked up by the functioning nodes.