Jump to: navigation, search

Scalability

Scalability of Recording Client Function

The Recording Client Function is designed to be scalable, and it works the same way as a scalable SIP Server + Media Server deployment. The goal is to allow SIP Server to use the same unified Media Server instances to provide any new media services, and in this case, media stream replication to a recording server. The following image shows the basic scalable SIP Server + Media Server deployment along with the Recording Server Function.

center|Scalability of Recording Client Function

In a single deployment, there are two Resource Managers running in active/backup or active/active pair. Resource Manager is responsible to route requests to the cluster of Media Servers by managing the capacity of each Media Server in the cluster. When there are multiple instances of SIP Servers, each SIP Server will configure a VoIP Service DN (type=recorder) to use the same pair of Recording Managers for all recording functions.

Resource Manager is also responsible to handle scalability issues at the recording server function. The scalability model for each recording vendor is different and will be discussed separately for each target deployment. Note that the recording client function and recording server function can be scaled independently so the above diagram allows SIP Server + Media Server to work with any type of recording vendor.

Scalability of Recording Server Function

The third party recorder can scale the number of simultaneous recording session by deploying a cluster of call recorders. GVP Resource Manager acts as a SIP Proxy to route recording sessions coming from Media Server to a call recorder instance from a pool of recorder instances, typically through round-robin fashion. Resource Manager can monitor recorder instances through OPTIONS pinging to ensure recording sessions are only forwarded to an available recorder instance. Resource Manager can also provision the recorder instances with capacity limits to ensure that the recorder instances are not overloaded.

The T-lib clients can be scaled independently of the call recorder since recorder and T-lib clients have different connections.

This page was last edited on October 2, 2019, at 19:20.
Comments or questions about this documentation? Contact us for support!