Request Flow 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