Hello,
We are experiencing a reproducible one-way audio issue after upgrading to Version 20.0 Update 9 (Build 995). The problem does not occur on direct extension calls in all cases we tested, but it does occur reliably on inbound calls answered from a call queue.
SrtpTransformer.cpp(145): Failed to decrypt RTP packet: error = 7
Timeline correlation:
At queue answer, Media Server also shows media leg changes (MOH/queue leg removed, agent leg joined), but the SRTP decrypt failure is present from the start of the trunk session, not only at answer.
We prefer to keep SRTP enabled for production, so this is only a temporary workaround.
Additional context:
We have been using this SIP trunk provider (lifecell) for a long time with the same configuration (TLS + SRTP Enabled). SRTP worked without issues before the Update 9 upgrade — there were no one-way audio problems, queue issues, or missing caller audio in recordings.
Nothing was changed on the provider side or on our firewall/NAT setup as part of this troubleshooting. The issue appeared only after upgrading to V20.0 Update 9 (Build 995).
Disabling SRTP on the trunk immediately resolves the problem, which strongly suggests a regression in 3CX Update 9 SRTP handling for this trunk, not a new provider or network misconfiguration.
Thank you.
We are experiencing a reproducible one-way audio issue after upgrading to Version 20.0 Update 9 (Build 995). The problem does not occur on direct extension calls in all cases we tested, but it does occur reliably on inbound calls answered from a call queue.
Symptoms
- Inbound call → queue → agent answers
- Agent → caller: OK (caller hears the agent)
- Caller → agent: NOT OK (agent hears nothing)
- Call recording on PBX also has no caller audio (only agent side)
- Outbound callback from agent works fine (both directions OK)
Environment
- 3CX V20.0 Update 9 (Build 995) on-prem (Linux)
- PBX behind NAT (public IP configured in 3CX network settings)
- Firewall Checker: passes
- SIP trunk: lifecell(Ukrainian provider)
- Transport: TLS
- SRTP Mode: Enabled
- Remote agents via 3CX Tunnel (Windows client)
- Issue started after Update 9 (worked before the update)
What we tried (did NOT fix it)
- Enable PBX Delivers Audio on agent extension
- Firewall Checker / RTP port range verification
- Various queue scenarios
Root cause found in logs
With Activity Log / Media Server logging enabled, we captured ~1400+ errors during a single test call:SrtpTransformer.cpp(145): Failed to decrypt RTP packet: error = 7
Timeline correlation:
- Errors start immediately when the inbound trunk SRTP session is established (within ~20 ms of SDP negotiation)
- Errors continue after the agent answers from the queue
- Trunk SDP uses RTP/SAVP with AEAD_AES_256_GCM
At queue answer, Media Server also shows media leg changes (MOH/queue leg removed, agent leg joined), but the SRTP decrypt failure is present from the start of the trunk session, not only at answer.
Workaround (confirmed)
Setting trunk SRTP Mode = Disabled fixes the issue completely (queue answer, recording, both directions).We prefer to keep SRTP enabled for production, so this is only a temporary workaround.
Additional context:
We have been using this SIP trunk provider (lifecell) for a long time with the same configuration (TLS + SRTP Enabled). SRTP worked without issues before the Update 9 upgrade — there were no one-way audio problems, queue issues, or missing caller audio in recordings.
Nothing was changed on the provider side or on our firewall/NAT setup as part of this troubleshooting. The issue appeared only after upgrading to V20.0 Update 9 (Build 995).
Disabling SRTP on the trunk immediately resolves the problem, which strongly suggests a regression in 3CX Update 9 SRTP handling for this trunk, not a new provider or network misconfiguration.
Request
Could the 3CX team investigate SRTP inbound decryption (auth_fail / error 7) with TLS + SRTP Enabled trunks on V20 Update 9, especially on queue inbound scenarios?Thank you.
