To clarify, the specific scenario represented by the CEL export is that of a call to a queue, where the queue member is intercepted.
Recording activation is based on the configuration of the intercepted user, as the identity of the interceptor is hidden to the agi queue handler which takes care of activating the recording.

To verify the fix:
1. create a queue
2. create a user as member of the queue, with recording enabled
3. create a user as interceptor
4. create a user as original caller
5. Create call pickup between interceptor and queue member
6. enable callpickup extension feature (Global Settings → Extension Features → callpickup _*8.)
7. call queue with caller user
8. letting queue member user ring, intercept call with interceptor user(*8<extension of member user ringing>)
9. caller is connected to interceptor, recording should have been initiated
10. complete call(hang up on either side)
11. verify that recording has been saved
12. verify that call log has been generated for the call, including an associated recording(`call_logd_recording` table)
13. given that recording is properly registered in database, initiating a purge of recordings(e.g. wazo-purge-db -d0) should delete the previously generated recording file

• reliably detect a sequence of CELs as initiating a call interception

  • solved based on appname and appdata from answer CEL event

• reliably detect a sequence of CELs as an intercepted call

  • not solved independently(no direct indicator in CEL sequence), but solved by correlation with channels from interception call

• interpret CELs of call interception and intercepted call together

  • solved at DAO level through correlation on CEL entries based on shared uniqueid(channels)

• two call logs may be created:

  • one for the intercepted call(source will be original caller and destination original callee, etc)

  • one for the interception call(source will be interception initiator, …)

  • after discussion, only one call log will be generated for intercepted call for now

Solution design notes

• reliably detect a sequence of CELs as initiating a call interception

• reliably detect a sequence of CELs as an intercepted call

• interpret CELs of call interception and intercepted call together

• two call logs may be created:

  • one for the intercepted call(source will be original caller and destination original callee, etc)

  • one for the interception call(source will be interception initiator, …)

Complexity of this case unravels some assumptions underlying call log processing and recordings

• call interception and beginning of recording events appear in a separate call from the original call to the queue which is targeted for interception.

• Once the interceptor connects to the existing call, the “interception call” ends(a LINKEDID_END CEL is registered), but the interceptor's channel is bridged in the existing call to the queue, and the recording continues on that call, so there is no CHAN_END event in the intercepting call.

• when call-logd processes the asterisk CEL entries, the recording start is detected in the interception call, but dismissed since there is no event in that call to mark the end of recording. one cannot assume that the recording ends when the LINKEDID_END event is seen, as the channel continues existing in a separate call. the call to the queue has no indicator of a recording.

• call-logd processing assumes linkedid values separates independent calls, while call interception distributes CEL entries between two “linkedid” calls which are meaningfully linked. This means understanding what’s happening in a call cannot always rely on a single linkedid sequence of CEL

Solution to this issue must involve establishing and detecting correlation between separate CEL sequences with different linkedid, and accounting for recording started in a call but stopped(through CHAN_END) in another.