https://livekit.io logo
Join Slack
Powered by
Livkit self hosted has an issue, post dtmf, audio ...
# ask-ai
b
Livkit self hosted has an issue, post dtmf, audio calls are not relayed to customer via sip. Whats the fix?
✅ 1
t
Thanks for reaching out, Prathamesh. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I hear you: audio stops being relayed to the SIP customer after DTMF is sent in your self‑hosted LiveKit setup. Let’s walk through the most likely causes and targeted checks you can run so we can narrow this down quickly. First, quick checklist to confirm environment basics • Is your SIP service deployed as part of your self‑hosted stack? The SIP service must be present for DTMF and media handling. • Are you using secure SIP/trunking (SRTP/TLS)? If so, note that LiveKit temporarily decrypts audio for processing and then re‑encrypts it. Diagnostic steps (run these in the order shown) 1. Confirm DTMF was received by LiveKit ◦ Verify you see the 
dtmf_received
event in the room logs when you send tones. If you don’t see this event, the DTMF transport (RFC2833 / SIP INFO / in‑band) is not reaching LiveKit. 1. Check if any state change happens on DTMF ◦ Review your DTMF handler / call flow code to ensure you are not unintentionally disabling agent output or muting the track after DTMF is processed. Look for calls like 
session.output.set_audio_enabled(false)
or equivalent. 1. Look at audio processing components (Krisp / transcoding) ◦ If 
krisp_enabled
or any transcoding is enabled in your self‑hosted stack, ensure that service is healthy. Misconfigured or failing audio processing can prevent audio from being re‑encapsulated and relayed after DTMF. 1. Confirm media path/ICE & TURN after DTMF ◦ Check ICE/DTLS handshakes and TURN allocation logs right after DTMF. Firewalls or ICE failures can break the media path; use TURN over TLS (443) if UDP is blocked. 1. Inspect SIP provider compatibility and SDP changes ◦ Some SIP providers behave differently when DTMF is signaled (change codecs, refresh SDP, or renegotiate). Inspect SIP/SDP logs to see if an unexpected re‑INVITE or codec change occurs after DTMF and isn't handled by your SFU. 1. Validate there’s no duplicate/echo DTMF causing debounce logic ◦ Rapid or duplicated DTMF signals can trip debouncing logic that might suspend audio. Check for repeated events and your debounce/guard logic. If you want the quick likely fixes to try now • Ensure your self‑hosted SIP service is running and reachable. • Disable Krisp/noise suppression temporarily to see if audio resumes — this isolates audio processing as the cause. • Ensure your DTMF method is RFC2833 if possible (most reliable). • Look for and remove any code paths that mute or reconfigure outputs during DTMF handling. • If you see a post‑DTMF re‑INVITE/SDP change, make your SFU/SIP handler accept the change or keep codecs consistent. What I need from you to continue troubleshooting • Which DTMF transport are you using (RFC2833, SIP INFO, in‑band)? • Are you using secure SIP (SRTP/TLS) and is Krisp/noise suppression enabled? • Any relevant logs: 
dtmf_received
events, SIP/SDP traces around the DTMF time, and SFU/media logs showing ICE/DTLS/TURN activity right before and after the DTMF. • Confirmation whether the SIP provider is one of Twilio/Telnyx/Exotel/Plivo/Wavix or another provider. I can take the next steps once you share the answers/logs above: I’ll point to the exact log lines to check, and give precise config changes or code snippets to apply. Sources: examples/dtmf | livekit/livekit_composite | DeepWiki | SIP Telephony and Encryption | Agents telephony integration | LiveKit Documentation | How to detect when an agent has finished speaking | LiveKit | sip | livekit/livekit_composite | DeepWiki, with interactive elements
b
Dtmf is being handled well, i use self hosted livekit sip. After dtmf when transfer is made to a normal call, there audio is generated but receiver cannot listen to it on phone
t
Thanks — that helps. I hear you: DTMF works and the call is transferring to a normal (PSTN/SIP) phone, audio is produced on the LiveKit side, but the phone recipient cannot hear it. Let’s focus on the transfer path and media negotiation so we can isolate the break. Quick checklist to confirm while we dig deeper • Confirm the SIP service in your self‑hosted stack is running and handling the transfer. • Note whether the transferred call is a direct SIP->PSTN bridge (your SIP provider does the PSTN leg) or an internal SIP endpoint. • Confirm whether you see any SIP re‑INVITEs or re‑INVITE/UPDATE during or immediately after the transfer. Targeted troubleshooting steps 1. Inspect SIP/SDP exchange during transfer ◦ Capture the SIP trace for the transfer (INVITE/200 OK/ACK and any re‑INVITE/UPDATE). Look for missing audio codecs, mismatched payload types, or a missing a=sendrecv / a=recvonly change that would prevent RTP flow to the phone. 1. Verify RTP is being sent to the phone endpoint ◦ On the machine that handles the SIP leg, check whether outgoing RTP packets are sent to the phone's IP/port after transfer. If RTP is being generated locally but not leaving the host, it’s a routing/firewall/NAT issue. 1. Confirm codec compatibility ◦ Ensure the audio codec used after transfer is supported by the phone/PSTN leg. If LiveKit is sending Opus but the provider/phone expects PCMU/PCMA, confirm a transcoder is active and functioning for that hop. 1. Check SRTP/DTLS and re‑encryption ◦ If secure media (SRTP) is used, ensure LiveKit successfully re‑encrypts media after any processing (Krisp/transcoding). Failures when re‑encrypting will result in silence on the phone side. 1. Look for SDP renegotiation issues ◦ Some SIP providers send a re‑INVITE that changes ports/codecs; if your SFU or SIP handler doesn’t accept it or fails to update RTP destinations, media will stop flowing. Make sure your SIP service applies the updated remote RTP IP/port and codec maps. 1. Confirm NAT/ACL/Firewall and TURN behavior ◦ If the SIP->phone leg crosses NAT, ensure the RTP ports are reachable. If you rely on TURN for media, verify TURN is used/advertised correctly and the provider accepts the media path. 1. Check whether audio is marked recvonly/sendonly ◦ After transfer check SDPs for 
a=sendrecv
vs 
a=recvonly
— the phone might be receiving only and not signaling the correct direction. Immediate quick tests you can run now • From the SIP host, run a packet capture during transfer and filter for RTP packets to the phone’s IP/port — confirm RTP payloads exist. • Force a well‑supported codec (PCMU/PCMA) in the SIP/SDP for the PSTN leg and retry the transfer to see if that restores audio. • Temporarily disable Krisp or any transcoding to rule out processing/re‑encryption failures. What I need from you to continue diagnosing • SIP trace (INVITE/200/ACK and any re‑INVITE/UPDATE) around the transfer time. • RTP packet capture (or confirmation whether RTP is sent to the phone IP/port) right after transfer. • Which SIP provider or phone model is receiving the call (Twilio/Telnyx/other or PBX). • Whether SRTP is used on the SIP leg and whether Krisp/transcoding is enabled. • The post‑transfer SDP offered/answered (if you can paste it). If you share the SIP trace + a short RTP capture or the post‑transfer SDP, I’ll point to the specific lines to inspect and give exact config/code changes to fix the media path. , with interactive elements
2 Views
Open in Slack
PreviousNext
Powered by