Inconsistent Call Recording Behavior with RCP, LCP and physical phones

[dongzhao2024]

We're working with customers on Cisco Network Based Recording (NBR) deployments, and facing challenges with inconsistent recording behavior. Their setups involve multiple Cisco clusters, numerous PGs, and thousands of agents, including mobile agents using both Remote CTI Port (RCP) and Local CTI Port (LCP) connections, as well as agents using physical phones.

Our goal is to reliably capture all calls. We've enabled call recording for physical phone extensions, RCP, and LCP. However, we observe inconsistent recording sources: sometimes recordings originate from RCP, sometimes LCP, sometimes both, and sometimes from the physical phone itself, sometimes no recordings at all. This unpredictable behavior makes it difficult to ensure complete call capture, especially with the mix of mobile agent connection types.

I've reviewed the documentation at https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/configExamples/cucm_b_recording-use-cases.html but am still unclear on the underlying reasons for this inconsistency.

Could anyone in the Cisco community provide insights into why we might be seeing this behavior? Specifically, we're trying to understand the factors that determine which recording source (RCP, LCP, or physical phone) is used for a given call, especially in a complex multi-cluster, multi-PG environment with diverse agent types, including those using RCP and LCP for their mobile agent connections. Any guidance on troubleshooting and ensuring consistent call recording, particularly with mobile agents, would be greatly appreciated. Thanks!

[bill.king1]

Even if you are able to consistently record, you're likely going to have an issue recording the entire call when people need to consult/transfer calls. There's no real way to address that aside from having 2 devices/phones for the agent.

[dongzhao2024]

Thanks @bill.king1 for the quick response! Yes, we are aware that call recording will be split into different legs in consult/transfer calls and we can successfully handle that right now. The challenging part is for some call legs; there is no SIP INVITE being triggered at all on both participants, and a bit difficult for us to figure out where might go wrong. For context, we are using Extended Media Forking where CUCM send SIP INVITE to recording server and audio comes from either Gateway (CUBE) or phone based.

[bill.king1]

I'm not even referring to consult/transfer with seperate recordings, I'm saying without a 2nd device you'll always miss part of the call.

[dongzhao2024]

Thanks @bill.king1 again for the quick clarification! 

> I'm saying without a 2nd device you'll always miss part of the call.

Can you explain a bit more on this part? I am not clear why a second device for the same agent can solve this issue.

[bill.king1]

Sure, so for instance, here's one of the scenarios:

Caller calls in and speaks to a nurse type call center. Customer requires entire call to be recorded. Nurse agent conferences in another nurse or doctor. They then need a specialist or ambulance transport.
If original agent puts call on hold, the discussion that happens while they are away is lost/not recorded. Agent would have to put the call on mute, and call from a separate device so that the original discussion continues and is recorded while they're speaking with specialist/ambulance transport.

[dongzhao2024]

Thanks @bill.king1 for the detailed example! 

From our observation, for the provided scenario, let's mark the first call leg between the caller and nurse agent with the name "call_1". With our current Extended Media Forking (XMF), the call_1 audio stream will end when the nurse agent puts the caller on hold (two SIP BYEs will be sent to the recording server to end the two NBR audio streams). When the nurse agent calls the doctor on another consult call (let's name this as "call_2"), the call_2 will be recorded under a new Cisco call ID (can be recorded either on the nurse extension, or doctor extension, or both, or neither, which we are trying to find out why). When the nurse completes the consult call_2 and unholds the original call_1, the Cisco system will re-trigger the SIP INVITE and continue to send the audio for call_2 between the caller and the nurse.

We see that 90% of the time, we can capture this consult call, but we are still investigating why the remaining 10% is missing.

It is not straightforward to aggregate all those different call legs into one logical master call. We currently use a combination of RouterCallKey and RouterCallKeyDay, which seems to work well.

The major confusion still comes from why sometimes we could not capture any call recording on both participants during this consult / transfer call between two internal agents (or sometimes between one visitor and one transferred agent).