I upgraded to the latest livekit version 1.5.7 and now voicemail has a weird behaviour on the transfer path, instead of the voicemail it says: please press star for fax machine. Noticed that if I put waitUntilAnswered=false it doesn’t do that but I can’t hear the full voicemail recording

Thanks for reaching out, luisa. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Thanks. Details below: 1. We’re using LiveKit SIP integration from a Python worker, not a separate built-in voicemail product flow. For warm transfer, we dial the transfer target with CreateSIPParticipant into a consult room, then move the SIP participant into the caller room once connected. For cold transfer, we use TransferSIPParticipant / SIP REFER. 2. We do use custom transfer audio/messages: - Caller hold audio: our own ringing WAV while the transfer target is being dialed. - Optional whisper message to the transfer target. - Optional post-transfer message after bridge. - Voicemail detection is app-side: we probe/transcribe the transfer target audio and skip bridge if voicemail is detected. We do not have any configured prompt/message that says “star”, so if that audio is being heard, we’re trying to determine whether it’s coming from LiveKit/SIP/Twilio/carrier behavior versus our media path. 3. Package versions: - livekit-agents==1.5.7 - livekit==1.1.7 - livekit-api>=1.0.7,<2 - livekit-protocol>=1.1,<2 - livekit-plugins-deepgram/openai/elevenlabs/silero==1.5.7 4. Transfer/waitUntilAnswered behavior: Originally warm transfer used CreateSIPParticipant with wait_until_answered=True. Observed behavior: - With waitUntilAnswered=True: we no longer hear the odd “star”/voice sound, but by the time our app gets control and starts listening, the actual voicemail greeting is already midway or near the end. - With waitUntilAnswered=False: we can create the SIP participant earlier and watch sip.callStatus until active before bridging, but the “star” audio/symptom still appears. 5. Transfer target: The failing target is a normal PSTN mobile number, specifically a T-Mobile Android voicemail path. It is not intentionally a fax endpoint or auto-attendant. We don’t yet have a SIP INVITE/200/ACK trace handy, but can collect one if needed. The key question we’re trying to answer is: when using CreateSIPParticipant with waitUntilAnswered false/true, is there any LiveKit-generated audio/prompt, dialtone behavior, DTMF prompt, or carrier-side media behavior that could explain the “star” audio before/around voicemail?

Thanks — this is helpful detail. I’m responding about whether LiveKit itself emits any “press star for fax” prompt during CreateSIPParticipant/transfer, and what to check next. Short answer: LiveKit does not generate a built‑in “press star for fax” prompt during transfers. That audio is very likely coming from the PSTN/carrier or the remote voicemail system as early media or an automated attendant/fax-detection behavior, not from LiveKit. What to check next (recommended diagnostic steps) 1. Capture a SIP trace (INVITE, 180/183, 200 OK, ACK) and the RTP/SDP for the outbound leg to confirm whether early media is present and what SDP codec/flags are negotiated. Early media with audio before 200 OK often explains odd prompts. 2. Inspect the 183/180 responses for any SDP — if you see audio in provisional responses, that’s early media (carrier-provided prompts). 3. Compare the call flow with wait_until_answered=True vs False: ◦ With True you’ll naturally miss earlier carrier prompts (agent only receives media after answer). ◦ With False you’ll receive early media — which matches your observation that the “star” audio appears only when you start receiving early media. 1. Check whether the carrier (or SIP trunk provider like Twilio) applies any fax/voicemail detection or plays prompts for voicemail—ask them to review that destination number’s handling. Some carriers insert a “press *” prompt for voicemail/fax detection. 2. Temporarily remove/disable any app-side injected audio (ringing/whisper/post-transfer) to confirm the source is remote and not something mixed in on your media path. 3. If you need to suppress carrier early media, bridge only after 200 OK (i.e., keep wait_until_answered=True) or detect and ignore early-media RTP packets until the call is fully answered. If you want, send the SIP INVITE/180/183/200 logs (redact sensitive tokens) or a short recording of the audio and I’ll help read the trace to identify early media vs inband prompts and point to the exact SIP response causing it. Sources: send_dtmf_events | LiveKit Documentation | Agents telephony integration | LiveKit Documentation | WarmTransferTask | LiveKit Documentation, with interactive elements

I dislable the silence and I still hear a blip and then please press the bla bla, is it cause we use our own voicemail detection and livekit added his own?

Thanks — I’m responding about whether LiveKit is adding voicemail prompts and what the “blip → please press *” likely means. LiveKit does not inject voicemail prompts or automatic “press * for fax” audio. That blip and announcement are almost certainly coming from the PSTN/carrier or the remote voicemail system as early media or carrier-side fax/voicemail detection — not from LiveKit or its built‑in voicemail detection. Next steps to isolate and fix: 1. Capture a SIP trace for the outbound leg (INVITE, 180/183, 200 OK, ACK). Look for SDP in provisional (180/183) responses — audio there = early media from the carrier. 2. Compare behavior with

wait_until_answered=True

vs `False`: ◦ True hides early media (you only hear after 200 OK). ◦ False exposes early media (you’ll hear carrier prompts before answer). 1. Temporarily disable your injected media (ringing/whisper/post-transfer) to confirm the audio isn’t coming from your mixing pipeline. 2. Ask your SIP trunk/carrier (or check their call logs/settings) whether they perform voicemail/fax detection or play a “press *” prompt for that destination number. Some carriers insert that prompt before bridging to voicemail. 3. If you want to suppress it, bridge only after 200 OK (keep

wait_until_answered=True

) or detect and ignore early‑media RTP until the call is answered. If you can share a redacted SIP trace or a short recording of the audio, I’ll review it and point to the exact SIP response/early‑media causing the prompt. , with interactive elements

I found it So yes: Twilio clearly shows two-leg routing. The working prod path is the

302

intermediate number on prod trunk/domain. The dev/staging path uses

<tel:9494184930|949-418-4930>

and a different LiveKit SIP domain/trunk. but why?

Thanks — this is helpful and you’re on the right track. What you found (summary): the prod path uses a Twilio two‑leg route via an intermediate (302) number on the prod trunk/domain, while dev/staging uses a different trunk that routes directly to 949‑418‑4930. That difference explains the behavior. Why this causes the “press *” prompt: • The prod two‑leg/proxy hop masks or changes early media from the carrier (so you don’t hear the carrier’s voicemail/fax prompt). • The dev trunk routes directly to the PSTN endpoint and exposes early media from the destination network (the “blip → please press *” you hear). • LiveKit is not injecting that prompt — it’s coming from Twilio/carrier routing differences. What you can do next (options): • Point dev/staging to the same Twilio trunk/domain used by prod so calls follow the same two‑leg route (makes behavior consistent). • Or ask Twilio to disable fax/voicemail detection or early‑media prompts for the dev trunk/number so the carrier doesn’t play that prompt. • Or keep using

wait_until_answered=True

(bridge after 200 OK) so you avoid early media, or detect/ignore early‑media RTP until the call is fully answered. If you want, share a redacted SIP trace from the dev call (INVITE / 180/183 with SDP / 200) or a short audio clip and I’ll confirm which SIP response contains the early media and point to the exact hop that’s inserting it. , with interactive elements