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.