Call Recording [DRAFT]
[Taken from HLA, requires revision]
Similarly to personal greeting feature, call recording is no longer supported via static provisioning (‘record’ option).
Only TLib interface is supported:
- Extensions in TRouteCall for the selective recording
- TSingleStepConference to ‘gcti::record’ for the emergency recording
- TPrivateService for the integration with 3rd party recorders (Zoom and Nice)
Selective recording is performed by URS talking directly to the Session Controller.
Emergency recording is performed by the desktop application. For those 2 modes, no changes are expected.
The last mode which targets not only desktop application but also 3rd party recorders requires some changes from the client side. As of today, 3rd party recorders do register all extension DNs in order to:
- monitor calls handled by those DNs
- issue TLib request (TPrivateService) on behalf of those DNs
Proposal is to modify recorder client to use new TLib request described in this section. Recorder client shall connect to T-Lib Controller and issue the single TRegisterAllKnownDN (?) request.
Multiple recorder instances are likely needed to support all SIP cluster agents. Each recorder shall therefore connect to a subset of the T-Lib Controller as shown on the following picture: [Figure: Recording with 3rd party recorders]
For a given DN, recorder will received events from the corresponding T-Lib Controller. Although not strictly necessary (because of the T-Lib Controller proxy feature), TPrivateService request for that DN shall be issued toward the same T-Lib Controller.
Passive recording Passive recording using voice monitoring API shall be supported by SIP cluster.
Active recording With current active recording design, a race condition exists between the moment call establishment notification (EventEstablished) and call recording start notification (EventAttachedDataChanged) are generated. This race condition occurs when recording is triggered by the routing strategy. When the call is established with the agent, recording procedure starts but TLib clients (including recorder client) are not aware of this. Recording client in particular would therefore initiate recording (using TPrivateService request) which would result into an error.
SIP cluster design shall prevent this race condition situation by adding additional information in the call establishment notification.
