V20 Update 9 — one-way audio on queue answer with TLS/SRTP trunk (lifecell) — SRTP decrypt failures — workaround: disable SRTP

[itspec.pavlikovskyi]

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.

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)

This points to an issue on the inbound trunk media leg, not the agent endpoint or firewall.

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

Provider media appears to reach the PBX (UDP packets visible in tcpdump), but 3CX cannot decrypt inbound SRTP → no caller audio in bridge/recording.

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.

 

[YiannisH_3CX]

Hello,

I have sent you a DM so we can further investigate your issue.

 

[sebastian13]

Hi,

we can confirm the same issue on a SIP provider from Austria (Telematica) after upgrading to V20 Update 9. Calls connect successfully but inbound audio fails. We have TLS + SRTP enabled.

Our logs contain repeated messages similar to:

Failed to decrypt RTP packet: error = 7
Failed to decrypt RTCP packet: error = 7
inbound SRTCP transformation failed
Malformed RTCP packet received with unrecognizable tail of 44 bytes with wrong rtp version=0

Packet captures show bidirectional SRTP traffic without packet loss, but inbound media cannot be decrypted.

The same provider and configuration work correctly with V20 Update 8. The relevant difference we observed is that Update 8 negotiates: AES_CM_128_HMAC_SHA1_80 while Update 9 negotiates AEAD_AES_256_GCM.

Due to this issue we have been unable to roll out the update to production systems so far.

@YiannisH_3CX could you give us an update on this? We're happy to share any diagnostic data that may help identify the root cause and validate a bug fix.

 

[ivank]

This is fixed in update 10