Mitel SIP Trunk Connected to LiveKit but No Audio / Call Terminates After ~25 Seconds

Hello LiveKit team,

I am currently testing SIP integration with LiveKit Agents.

Setup:

  • LiveKit Cloud SIP inbound trunk

  • AI agent configured and working correctly

  • Twilio configured as inbound SIP provider → works successfully with full audio

  • Mitel PBX configured with the same SIP trunk destination

Issue:
When calling from Mitel:

  • the SIP call connects successfully

  • the call timer starts counting

  • however, there is no audio in either direction

  • then the call terminates automatically after approximately 25 seconds

Since the same LiveKit SIP trunk works correctly with Twilio, I suspect there may be a Mitel-specific SIP/RTP configuration issue.

Could you please advise if there are any required or recommended Mitel-side configurations for interoperability with LiveKit SIP?

Any guidance would be appreciated.

Thank you.

Cc: @ahmed_elhelow

Classic no-audio bidirectional pattern on a new SIP carrier. Twilio working rules out LiveKit-side; the gap is the Mitel <> LiveKit RTP path. Two most likely causes:

  • Mitel’s SDP advertises an unreachable RTP IP. PBXes behind NAT often put the LAN IP in the SDP c= line by default. LiveKit then sends RTP to that private address and silently fails. Capture Mitel’s INVITE and check the c=IN IP4 ... line: if it’s 10.x / 192.168.x / 172.16-31.x, that’s the bug. Mitel’s far-end NAT detection or “use public IP in SDP” toggle (label varies by Mitel version) is the fix.

  • Mitel firewall blocks LiveKit’s RTP range inbound. Mitel may only permit inbound UDP from the SIP signaling IP; RTP from LiveKit’s media bridge IPs (different range) gets dropped. Permit inbound UDP from LiveKit’s RTP edge ranges.

On the ~25s drop: likely RFC 4028 Session-Expires from Mitel firing since both legs are silent. Once audio flows, the session-refresh re-INVITE keeps the call alive.

Diagnostic order:

tcpdump -i any -w mitel.pcap port 5060 or portrange <mitel-rtp-range>

Open in Wireshark, check the SDP c= and m=audio lines on both sides. If c= is private, fix Mitel’s NAT setting; if RTP is one-way, fix the firewall.

Worth posting the Mitel-side SDP from a failing call if you want a more targeted read.

I am not seeing failed calls. Can you go here Sign in | LiveKit Cloud and provide a call ID that demonstrates the issue. Or provide a PCAP.