Support

Summary

Outbound calls on domain dispatchioai.cloudonix.net that are bridged to a Retell voice agent via
… have one-way audio: the customer's audio reaches
Retell fine, but Retell/LiveKit sends zero RTP back to Cloudonix, so the caller hears dead air and hangs up
after ~20–30 seconds.

This is a regression. Identical calls worked on June 3, 2026 and have failed since on/around June 11, 2026
— coinciding with Retell moving its SIP media to LiveKit (*.sip.livekit.cloud). Nothing changed on our side
(same voice application, same agent, same call flow).

Inbound calls to the same domain/agent path are unaffected and continue to work with full two-way audio.

Environment

Tenant / Customer: DispatchioAI (tenant id 974)
Domain: dispatchioai.cloudonix.net (domain id 1455)
Voice app: call_id (Retell provider connector)
Retell/LiveKit SIP endpoint: 5t4n6j0wnrl.sip.livekit.cloud (TLS/5061)

Reproduction / example failing call

Cloudonix session token: 800e74631c164ff48e706fde237bcd4b
Date/time: 2026-07-01 15:27:51 UTC
Caller → destination: 9142765555 → 8383681402
Inbound leg SIP Call-ID: 057be260441bc6d0439edc032a02dd3b@64.129.84.18:5060
Bridged Retell target: call_ac7418e55649e61f5cd45cf9c1c@5t4n6j0wnrl.sip.livekit.cloud
Result: SIP 200 OK received, call connected, then hung up ~30 s later with no audio.

Evidence 1 — QoS proves the return leg is dead

From the session QoS (800e74631c164ff48e706fde237bcd4b):

Retell/LiveKit leg (CHANNELQOS):

ssrc=880638534; themssrc=0; rxcount=0; txcount=1643; rxmes=0; txmes=87.95; rx_mos=NaN; tx_mos=4.4

PBX/customer leg (…BRIDGED):

bridge_themssrc=165581950; bridge_rxcount=1493; bridge_txcount=0; bridge_rxmes=0(→MOS 4.4); bridge_txmes=88.09

Interpretation (audio path, hop by hop):

HopPacketsStatusCustomer (PBX) → Cloudonixrx 1493, MOS 4.4OKCloudonix → Retell/LiveKittx 1643, txmes 87.9OK (customer audio delivered to Retell)Retell/LiveKit → Cloudonixrx 0, themssrc 0FAIL — no packets received at allCloudonix → Customertx 0Nothing to relay → caller hears silence

Cloudonix never receives a single RTP packet (nor even an SSRC) from the LiveKit side.

Evidence 2 — SDP offer to LiveKit mixes SDES-SRTP and DTLS-SRTP

Cloudonix's outbound INVITE to …@5t4n6j0wnrl.sip.livekit.cloud offers both keying methods on the same
media line:

m=audio 38500 RTP/SAVP 0 8 18 9 96 97 101 ← SDES-SRTP profile
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:96 opus/48000/2
a=crypto:1 AEAD_AES_256_GCM inline:… ← SDES keys (crypto:1..12)
...
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:…
...
a=setup:actpass ← DTLS-SRTP attribute
a=fingerprint:sha-256 11:B7:BA:54:… ← DTLS-SRTP attribute
a=tls-id:04a5b722c8c8c3016b9e78035861b18c ← DTLS-SRTP attribute

LiveKit's 200 OK answers with SDES only (G.722 selected, no DTLS):

m=audio 51912 RTP/SAVP 9 101
c=IN IP4 161.115.180.96
a=rtpmap:9 G722/8000
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:KXwJ21ohn//abvEITcQCFx5G18QtzfkPNc+OP/vu

Codec (G.722) and crypto suite (AES_CM_128_HMAC_SHA1_80) match on paper, yet no SRTP flows back from LiveKit.
We believe the hybrid SDES + DTLS offer is being mishandled by Retell's new LiveKit SIP stack, resulting in an
SRTP keying mismatch on the LiveKit→Cloudonix direction.

Evidence 3 — Regression timeline (Retell call IDs)

Working (June 3, 2026): call_88690314721084ad47f974f97c6 — outbound, to 8383681402, full 1m47s conversation, two-way audio.
Broken (June 11, 2026 onward): call_48faae00ed4b4ebc4644d, and all subsequent GREEN outbound calls.
Broken (July 1, 2026): call_2535e0f5a36e2fe7fed9f0733a2 (the session traced above), call_3265d3f8441a3fdc45725e904c6, call_47c7934e997f43015e4ab0b3977, call_894a76538468a64031adfb6b0a3.

Every outbound call since ~June 11 shows the same themssrc=0 / rxcount=0 return-audio failure. Every inbound
call to the same agent path continues to work.

Evidence 4 — Fails identically with UNENCRYPTED media (rules out SRTP/codec)

We changed the voice app to (non-encrypted). New test call:

Cloudonix session token: eb6024ecf87c4cd7ae9428aab96368ee
Retell call_id: call_556e3de869a9cb6c3c8d5a9ac89
Routed to call_556e3de869a9cb6c3c8d5a9ac89@sip.retellai.com:5060;transport=udp
SDP offer/answer now plain RTP/AVP G.722, no crypto, no DTLS. SIP 200 OK.

Result is identical:

Retell leg: themssrc=0; rxcount=0; txcount=975 ← Cloudonix sends, receives nothing back
Bridge leg: themssrc=985983317; rxcount=842; txcount=0 ← customer audio arrives fine

Furthermore, Retell's own multichannel recording for this call is pure silence on BOTH
channels — including the customer channel — even though Cloudonix transmitted 975 RTP packets to the
media address in Retell's 200 OK (161.115.181.255:54542). This proves Retell is not receiving the
RTP Cloudonix sends, in addition to not sending any back.

Conclusion: this is not an SRTP, DTLS, or codec issue. The RTP media plane between Cloudonix and
Retell is not connecting in either direction, on both the encrypted LiveKit endpoint
(*.sip.livekit.cloud) and the unencrypted endpoint (sip.retellai.com). It regressed on/around
June 11, 2026, coinciding with Retell's LiveKit migration. Signaling (SIP) succeeds in all cases.

What we're asking

The RTP media plane between Cloudonix and Retell is not connecting in either direction, on both the
encrypted (retell → *.sip.livekit.cloud) and unencrypted (retell-udp → sip.retellai.com) paths, since
~June 11, 2026. SIP signaling succeeds; media does not. This needs the Cloudonix Retell connector / media
interconnect with Retell investigated:

Why does Retell receive none of the RTP Cloudonix transmits to the media address in its own 200 OK,
and send no RTP back (themssrc=0) — for both endpoints? Please check media routing / symmetric-RTP /
NAT handling and whether the Retell connector needs to be refreshed/reconfigured (e.g. via cx-vcc) for
Retell's current (post-June LiveKit migration) SIP + media infrastructure.
As part of the hybrid-keying observation in Evidence 2, please also confirm the SRTP offer Cloudonix sends on
the encrypted path is standards-compliant for LiveKit — but note the failure persists without encryption,
so this is secondary.
We can provide full SIP traces and session logs for tokens 800e74631c164ff48e706fde237bcd4b (encrypted) and
eb6024ecf87c4cd7ae9428aab96368ee (unencrypted), plus Retell call IDs and multichannel recordings.