Severe Static on Transfer Leg — Staff Hears Noise After AI Transfers Call

Support Help
1

We are experiencing a critical audio quality issue where the recipients of transferred calls hear severe static/noise immediately after our Retell AI agent transfers
the call to them. The static is so bad the conversation is impossible.

Key details:

  • Issue occurs ONLY after Retell transfers — the initial AI conversation has no static
  • Transfer recipients are on a WebEx phone system
  • Issue is consistent and reproducible, not a one-off
  • When staff call the patient back directly (bypassing Retell), audio is perfectly clear
  • First reported June 19, 2026, Physician Queue, multiple hunt groups affected

Our call flow:
Inbound caller → Twilio SIP trunk (+17575005707) → Retell AI → Retell transfers → Twilio PSTN → phone system → staff

Reference call:

  • Retell Call ID: call_c81edc85118deb12ac157c4e81d
  • Twilio Call SID: CA4d42a3dc1591bfe0be3f5da543d02c2a
  • Date: June 19, 2026, ~13:28 UTC
  • Recording available (62s Retell leg)

What we need help with:

  1. Is there a codec negotiation happening at the point of transfer that could introduce static? (Possible G.711 / transcoding mismatch)
  2. Does Retell use SIP REFER or dial-out bridge for transfers — and could this cause RTP stream issues?
  3. Any known issues with Retell → Twilio PSTN transfer audio quality?
  4. Can Retell provide any RTP/SIP logs for the transfer leg of the above call?

We have already opened a Twilio support ticket and requested a Voice Trace. Happy to share recordings or any additional logs.

Thank you

2

Hi @phonavar Thanks for the details, I have sent it to the team for a review. We will get back to you as soon as we have an information. Thanks

3

Hello @phonavar here’s what we found.

Transfer mechanism on this call

  • The transfer on call_c81edc85118deb12ac157c4e81d used cold SIP REFER
  • With SIP REFER, once Twilio accepts the REFER and we send NOTIFY sipfrag 200 OK, Retell drops out of the call entirely. Twilio becomes the B2BUA: it issues a new outbound INVITE from its SBC to the destination and bridges that leg directly to the caller. Retell never sees the audio the staff hears post-transfer.
  • Pre-transfer audio on our recording is clean, which matches what you observed.

Answers to your specific questions

  • Codec negotiation at the transfer point: Retell does not renegotiate codecs at REFER — we hand off and exit. Any transcoding (e.g. G.711 :left_right_arrow: Opus, ptime mismatch) on the new leg happens between Twilio’s SBC and the WebEx-side gateway.
  • REFER vs dial-out bridge: Cold transfer on this call was REFER. We also offer a SIP INVITE cold-transfer mode (selectable on the transfer node under “SIP Transfer Method”). Under SIP INVITE, Retell dials the destination and bridges both legs itself, so media stays anchored to Retell end-to-end. One caveat: Show Transferee as Caller only takes effect under SIP INVITE; it isn’t available under SIP REFER.
  • Known Retell → Twilio PSTN issues: none currently affecting your org. The pre-transfer leg of this specific call is clean on our side.
  • Retell RTP/SIP logs for the transfer leg: we don’t have any. There is no outbound PCAP for this call (Retell didn’t dial the B-leg under REFER), and our inbound capture only covers the A-leg up to the REFER handoff — pre-static, which you already confirm is clean.

Where to look next (in your Twilio account)
On Twilio Voice Insights for parent CallSid CA4d42a3dc1591bfe0be3f5da543d02c2a (subaccount AC1b04d381d375a3f3c6c90d9358e5b23f, trunk TK2dbb3b482ef022b36222634db1c579fb), open the call tree and find the REFER-spawned child call to +17576908093. On that child call summary, the relevant signals are MOS, jitter, packet loss, packet delay variation, and the SIP ladder — in particular the negotiated codec and ptime on the 200 OK SDP from the WebEx side. If those metrics are degraded on the Twilio:left_right_arrow:WebEx leg, that points to the WebEx-side gateway / trunk codec config; if they’re clean, the impairment sits further downstream on the WebEx side.

Quick mitigation test
If you’d like to immediately rule REFER in or out, switch the transfer node’s SIP Transfer Method from SIP REFER to SIP INVITE on a test agent and reproduce. Under SIP INVITE, Retell stays in the media path and re-renders the audio itself end-to-end — if the static disappears, the issue was in the REFER-bridged codec/path between Twilio and WebEx; if it persists, the problem is purely on the WebEx-side leg.

Happy to look at additional call IDs or compare SIP ladders if you can share the Voice Insights export.

Thank You