We have an org-wide policy to record all calls, but we’ve discovered that agent-to-agent direct calls are bypassing the recording system.
I noticed this when monitoring the WebSocket events on v2.users.{id}.conversations. For external inbound calls, the recordingState changes to ACTIVE almost immediately. But for internal extension dialing, the event ordering is completely different and the recordingState never fires. Is this a known performance limitation or a bug in how WebRTC handles peer-to-peer media?
From an HR perspective, this is a massive loophole.
Some of our agents figured out that direct internal calls aren’t recorded, and they’ve been using it to bypass our QA processes and waste time chatting without it hitting their KPIs or the leaderboards. We run our gamification contests based on productive handle time, and these ghost calls are completely skewing the motivation programs. We need a way to track these!
This is a fundamental quirk of how Architect and the platform handle direct dials.
If agent A dials agent B directly, the call does not pass through an Architect flow. Since line recording is often triggered by queue settings or flow actions, direct dials skip that logic entirely.
A common architecture pattern to fix this is to disable direct dialing permissions and instead force all internal transfers to hit an internal Architect flow first. Inside that flow, you explicitly use the Enable Participant Recording action before routing the call to the target agent.
Hello everyone! I’ve been around these forums for a few years and this actually comes up quite frequently.
As the Architect designer mentioned above, direct internal calls (WebRTC to WebRTC) do not traverse the Edge servers in the same way an external SIP call does; they often establish a direct peer-to-peer media path to save bandwidth. Because the media doesn’t flow through the central recording service, the platform cannot capture the audio natively.
I wrote a detailed guide on this workaround back in 2023. You can find the historical discussions by searching the forum archives for ‘Internal Recording Workarounds’.
We absolutely cannot have unrecorded calls in our environment due to our business continuity and disaster recovery mandates.
If an emergency routing scenario occurs and supervisors need to coordinate via internal calls, those communications must be auditable for the post-mortem review. The workaround of forcing everything through a designated Architect flow is exactly what we implemented. It adds a slight delay to internal routing, but guarantees compliance.