High Availability

Recording Client Function

The high availability model for the Recording Client Function is essentially the same as the high availability model for Genesys SIP Server and Genesys Media Server.

Failover of SIP Server

SIP Server can be deployed in an active/hot-standby pair; whenever the primary instance fails, the hot-standby instance will take over and will have knowledge of all established sessions. If a recording session has been established with a recording server, a failure of SIP Server will not affect the operation of the communication and the recording session.

Failover of Resource Manager

Resource Manager is a SIP Proxy that can operate in either active/hot-standby or active/active pair. When there is a failure at the Resource Manager, the remaining instance of Resource Manager will become active and continue to accept incoming requests. The remaining instance will remember the affinity of the recording sessions with Media Server as well as the recording server. The failure should be transparent to SIP Server, Media Server, and the recording server function.

Failover of Media Server

When the media is bridged through Media Server, Media Server becomes a single point of failure for the duration of the communication session. If Media Server fails, Resource Manager notifies SIP Server about the failure so that SIP Server can take alternative action on the call. SIP Server should re-establish the recording session by joining the endpoints to another available Media Server. When the endpoints are joined to the now-active Media Server, Media Server will establish a new recording session with the same parameters to the recording server function.

center|Media Server Failover

The total amount of recorded media lost is the sum of time for Resource Manager to detect MS1 failure plus the amount of time to failover the recording session to another Media Server instance.

Recording Server Function

Handling high availability of the Recording Server Function is the responsibility of the third party recorder. The following are typical ways to manage failover of a component in Recording Server Function, and Genesys does not restrict how third party manages high availability of Recording Server Function.

Failure of a call recorder:

• Separate signaling (SIP) and media recording (RTP) in the call recorder. Whenever there is a failure of signaling, a backup instance can take over without affecting the recording session. Whenever there is a failure of the media recording, another available media recorder can take over but signaling needs to reINVITE with the new address of the media recorder.
• If the T-lib client can detect a failure of a call recorder, the T-lib client can instruct recording to stop and then start recording again. This allows Media Server and resource manager to find another available recorder instance when establishing the recording session.

Failure of a T-lib client:

• Have a backup instance of the T-lib client to take over processing whenever the active instance fails. The backup instance establishes a separate T-lib connection to SIP Server and will only start to observe T-lib events from SIP Server when it becomes active.

Recording Duplication

To protect against any loss of recorded media in the case of a failure in the recording server function, the recorder has the option of duplicating the recording by establishing two independent recording sessions. The following steps outline the mechanism of duplication:

1. T-lib client requests for duplication or this can be a configuration parameter on SIP Server.
2. When SIP Server requests for recording, SIP Server will ask Media Server to create two separate recording sessions.
3. When Media Server initiates the Recording Session, Media Server must generate a different record identifier in the Request URI; this tells the Resource Manager that the duplicated of recording session is different than the first one so that Resource Manager may choose a different recording server based on the load balancing scheme.

Note: Media Server is still a single point of failure since RTP media is still pinned through a single instance of Media Server. This duplication only protects against the failure of SIP Server, failure of Resource Manager, and failure of recording server.