Transfers
This section describes the types of transfer that the Active Recording Ecosystem supports.
Recording from the Origination Device
When a call that is being recorded is transferred to another party, the recording can be affected differently depending on where the recording is initiated. The reason for differentiating the side of the recording is that call recording is "sticky" to the side of the connection that is chosen for recording. When the connection needs to transfer the call to another device, the call recording stays with the device. For example, if the connection is transferred from D2 to D3, the call recording is maintained if recording is initiated from the origination device, while the recording is terminated if the recording is initiated from the terminating device.
Recording from the Termination Device
When the call is transferred to D3, the Recording Session is maintained and should expect a reINVITE to re-negotiate the media between D1 and D3. The media control dialog between SIP Server and Media Server is also maintained by only sending reINVITEs to the media control dialog.
Multi-site Transfers
There are a few models for transfers across SIP Server instances, depending on where the recording is started and how transfer is performed. SIP Server may stay on the signaling path when transferring a call to the remote SIP Server using reINVITE, or SIP Server may put itself out of the signaling path using REFER (set the SIP Server oosp-transfer-enabled option). When a call is transferred from one T-Server (SIP Server) to another T-Server instance, their local call identifiers, connection id, will be different on the different T-Servers. The customer interaction is identified by a common identifier CallUUID and this identifier is maintained after the call is transferred from one site to another.
Customer recording, transfer with reINVITE
The agent on SIP Server (blue) transfers the call to the agent on SIP Server (purple) using reINVITE. Since the recording is enabled on the customer side, the recording remains in the call path, and the media pinned up in the blue site. Call recording is serviced by the recording server in the blue site as well.
Customer recording, transfer with REFER
When the call is transferred from the blue site to the purple site with REFER transfer, the existing call recording will terminate. The transferred call coming into SIP Server (purple) is treated as an incoming call, and recording is not automatically enabled. Recording may be started again through the usual means in the purple site, but this is not automatic. As a future extension, the transferred call coming into SIP Server (purple) may contain a SIP extension to note that the call should be recorded, without the need to rely on a business rule to trigger recording again on the transferred site. This allows consistency of selection when selective recording is used – meaning when the call on the blue site is being recorded, the call should be recorded after the call is transferred as well. As a workaround, it is possible that a T-lib client can attach some user data into the call to indicate that the call is being recorded, and when the call is transferred to the purple site, another T-lib client can look for this user attached data for the recording indication.
Agent Recording
When agent recording is enabled and the call is transferred to another SIP Server, the agent recording is automatically terminated. This is basically the same as depicted in the Recording from the Termination Device figure, for a transfer to another agent within the same SIP Server. The type of transfer is irrelevant in this case since both will yield the same result. For both cases illustrated below, if the recording is to be started on the transferred agent, the media will pinned up on the purple site and the recording server in the purple site will be recording the media.