SIP Data Tier with Two Partitions

Configuring SIP Data Tier Partitions and Replicas 6-5 partition namePartition0name server-nameDataNode0-0server-name server-nameDataNode0-1server-name partition partition namePartition1name server-nameDataNode1-0server-name server-nameDataNode1-1server-name partition data-tier

6.4 Storing Long-Lived Call State Data In A RDBMS

Oracle WebLogic Communication Services enables you to store long-lived call state data in an Oracle or MySQL RDBMS in order to conserve RAM. When you enable RDBMS persistence, by default the SIP data 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 data 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. Note that Oracle WebLogic Communication Services only uses the RDBMS to supplement the SIP data tiers in-memory replication functionality. To improve latency performance when using an RDBMS, the SIP data 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 data tier 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. See Section 6.7, Caching SIP Data in the Engine Tier .

6.4.1 Requirements and Restrictions

Enable RDBMS call state storage only when all of the following criteria are met: ■ The call states managed by your system are typically long-lived. ■ The size of the call state to be stored is large. Very large call states may require a significant amount of RAM in order to store the call state. ■ Latency performance is not critical to your deployed applications. The latency requirement, in particular, must be well understood before choosing to store call state data in an RDBMS. The RDBMS call state storage option measurably increases latency for SIP message processing, as compared to using a SIP data tier cluster. If your system must handle a large number of short-lived SIP transactions with brief response times, Oracle recommends storing all call state data in the SIP data tier.