Configuring SIP Data Tier Partitions and Replicas 4-11
4.5.1 Situations Best Suited to Use Geo-Redundancy
The following situations are best suited to take advantage of Geo-Redundancy:
■
Your application uses SIP dialog states that are long-lived dialog states that typically last 30 seconds or longer, such as SUBSCRIBE dialogs or conferences
■
Your application would reasonably be able to reconstruct the session re-INVITE, expire SUBSCRIBE dialogs to trigger re-subscriptions, and so on from the state
that has been replicated
■
The link between two OCCAS clusters or sites is low-bandwidth 1Gbs each direction or high or variable latency 5ms 95
4.5.2 Situations Not Suited to Use Geo-Redundancy
Geo-Redundancy should not be used in these situations:
■
A high-capacity link between sites is available
■
Your application does not reach SIP dialog steady-states that are likely to last longer than the time it would take to re-route all traffic to the secondary site in the
event of catastrophic failure 15-30 seconds
■
If the application session is likely to be terminated by the user before the application could re-construct the session most users will disconnect their calls
before the session can be re-established from the secondary site
■
The volume of session state objects created by the application is greater than the site interconnect can support
4.5.3 Geo-Redundancy Considerations: Before Your Begin
Keep in mind the following considerations when planning your Geo-Redundancy:
■
Dimension the system for the site link
■
Each dialog state is ~25KB on the wire 25600 bits
■
A typical B2BUA is two 2 dialogs
■
Aim for 25 utilization or less, depending on the specific equipment and topology of the site to accommodate “jitter” and sustained latency on the link
For example, a 100 Mbs link can handle approximately1000 call states per second, and a typical B2BUA in the default configuration generates 4 states during the
call two for each dialog. So, a 100 Mbs link will support a single OWLSC cluster dimensioned for a peak arrival rate call rate of 250 CPS.
Upon receiving a message, an engine on the secondary site persists the call state data and assigns it the site ID value of the primary site.
By default, call states are activated only for individual calls, and only after those calls are
requested on the backup site. The site ID distinguishes replicated call state data on the secondary site from
any other call state data actively managed by the secondary site. Servlets can use the
WlssSipApplicationSession.getGeoSiteId method to examine the site ID associated with a
call.
Timers in replicated call state data remain dormant on the secondary site, so that timer processing does not become a bottleneck to performance.
Any non-zero value for the site ID indicates that the Servlet is working with call state data that
was replicated from another site.
Table 4–1 Cont. Geographic Redundancy flow
Normal Operation failover
4-12 Oracle WebLogic SIP Server Container Administrators Guide
■
Geo-Redundancy is not transparent to the application; in most cases the application must be designed to use SetPersist appropriately, and the developer must
consider the volume of state that the application will queue for replication between sites
■
SetPersist should be used within the application code to selectively identify dialog states that will be long-lived
■
Given the time it generally takes to route traffic to a secondary site, any application that replicates state more frequently will unnecessarily saturate the
JMS queue and site interconnect
■
Tuning of JMS to the specific application environment is required: Serialization options, message batching, reliable delivery options and queue size are all
variable, depending on the specific application and site characteristics
■
Geo-Redundancy default behavior is to replicate all dialog state changes when Geo-Redundancy is enabled for the container this is not recommended for
production deployments
■
Given the time it generally takes to route traffic to a secondary site, any application that replicates state more frequently will unnecessarily saturate the site
interconnect
■
SetPersist should be used within the application code to selectively identify dialog states that will be long-lived longer than ~20-30 seconds would be a
reasonable threshold
4.6 Using Geographically-Redundant SIP Data Tiers
