Our SIP infrastructure (Retell AI voice agents) receives inbound PSTN calls through Elastic SIP Trunking and transfers some of them to a human by sending a **SIP REFER** (Call Transfer enabled on the trunk, `transfer_mode = enable-all`, `transfer_caller_id = from-transferee`). Twilio executes the REFER correctly: the new leg to the Refer-To number is created, rings, and is bridged when answered.
**Problem:** while the Refer-To destination is ringing, the transferee (the original PSTN caller) hears **complete silence** — no ringback tone, no early media — until the destination answers or the leg fails. This lasts 30 to 60 seconds on every transfer that is not answered quickly, and callers hang up.
We have confirmed with dual-channel `` recordings that nothing is sent toward the caller during the ringing phase (channel RMS = 0.000 for the whole ringing window), and with the transferor’s own recordings that the transferor sends silence as well. Until early September the callers did hear a ringback tone; the transferor (Retell) changed its SIP stack on 3–4 September 2026, and we understand from Twilio’s documentation (“Early media with Call Transfers is not supported”) and from the Twilio Help Center Assistant that Twilio neither relays early media nor generates ringback on REFER transfers, so the tone they heard before was generated by the transferor.
We would like Twilio to confirm this analysis from your SIP logs, and tell us whether **any Twilio-side option exists** to play a ringback tone to the transferee during a REFER transfer.
Reference calls (all on 1 October 2026, caller +33 6 62 23 44 26)
IE1 — trunk “EU SIP TRUNCK” (domain `212122111.pstn.twilio.com`, origination `sip:sip.retellai.com`)
| UTC time | Parent leg (Twilio → Retell) | REFER leg created by Twilio | Destination | Result | What the caller heard |
|---|---|---|---|---|---|
| 19:55:06 | `CA3ae5d9f730af3618d14d851e9520f1aa` | `CA46da067482aea04e850e4e9baa3cf6b6` | +33 6 74 28 49 66 (mobile) | completed, answered after ~9 s | **silence** until answer |
| 19:58:53 | `CA44fe32faa86f8ae0137be8fd692666a4` | `CA0f54cc9f1eb2be8d467425a8c0bb57d5` | +33 3 39 64 02 21 (office PBX) | `failed` after exactly 60 s | **silence** for 60 s |
| 23:03:04 | `CA7ea058a0776441dd65f6b3520b9c84f9` | `CAe7d489aca28eca7e33a800f66dfa6533` | +33 6 74 28 49 66 (mobile) | completed, answered after 7 s | **silence** |
| 23:18:04 | inbound `CA735f5aade38d87dfb38c4d9a9705511d` → `` child `CAd55716536b9a63dbed3e1c7953cf96f1` → trunk leg `CAecf4cf6175e9cc8ab11253385180ec2a` | `CA88d961ed7bb3608ce4c2a506986fa4ad` | +33 3 39 64 02 21 | `failed` after 60 s | **silence** for 60 s (production path, with the Programmable Voice `` in front) |
US1 — trunk “SIP Trunk France Number” (domain `retell-france-number1.pstn.twilio.com`)
| UTC time | Parent leg | REFER leg | Destination | Result | Origination URI at that time | What the caller heard |
|---|---|---|---|---|---|---|
| 18:08:45 | `CAb6f1349cbe2361c4e13e470629c8053d` | `CA409498ba201bca2d8870d54daa815e52` | +33 6 62 23 44 26 | no-answer (caller’s own mobile) | `sip:5t4n6j0wnrl.sip.livekit.cloud` (legacy Retell stack) | **ringback audible** |
| 23:22:33 | `CA4674c673b4fdfe4c55cbd6912cfc08fa` | `CAced558899646e48e7cf66884f429921d` | +33 6 62 23 44 26 | completed after ~10 s | `sip:sip.retellai.com` (new Retell stack) | **silence** |
The last two calls are the same agent, same trunk, same transfer node, same destination, 5 hours apart; the only change between them is the trunk’s origination URI (and therefore the transferor’s SIP stack). This is why we believe the tone heard before was generated by the transferor, not by Twilio.
Over the last 90 days on the IE1 trunk, 1,309 REFER legs were created toward +33 3 39 64 02 21; 469 of them ended without an answer, each after 30–60 s of silence for the caller.
What we ask
- From your SIP logs for the IE1 legs above (`CA46da0674…`, `CA0f54cc9f…`, `CA88d961ed…`): what provisional responses (180 / 183, with or without SDP) did Twilio receive from the Refer-To destination, and what media, if any, was sent toward the transferee during ringing? We want to confirm that Twilio sends nothing by design in this scenario.
- Is there **any** Twilio-side mechanism to play a ringback tone to the transferee during a REFER transfer — trunk setting, SIP header manipulation, or passing the destination’s early media? If not, please confirm so we can stop looking on the Twilio side.
- The REFER legs toward +33 3 39 64 02 21 consistently end with status `failed` after exactly 60 s (never `no-answer`, 10–30 legs per week since June). What is the final SIP response Twilio receives from the carrier in these cases, and is the 60 s limit a Twilio timer or the carrier’s?
- Voice Insights returns `20404` for every IE1 call we query (`insights.dublin.ie1.twilio.com/v1/Voice/{CallSid}/Summary` and `/Events`), including calls from the same day. Is Voice Insights expected to be available for IE1 trunking calls, and if so what are we doing wrong?
Our configuration, for reference
- IE1 trunk “EU SIP TRUNCK”: origination `sip:sip.retellai.com`, termination `212122111.pstn.twilio.com` with credential list auth, `transfer_mode enable-all`, `transfer_caller_id from-transferee`, `secure false`, no trunk recording. Numbers +33 9 74 99 31 92 (Retell) and +33 7 57 90 19 85 (Programmable Voice Function that plays an announcement, then `` to +33 9 74 99 31 92).
- US1 trunks “SIP Trunk France Number” and “SIP Voice Real Estate”: origination migrated from `sip:5t4n6j0wnrl.sip.livekit.cloud` to `sip:sip.retellai.com` on 1 October 2026 (22:56 and 23:01 UTC).
- Transferor: Retell AI cold transfer, SIP REFER mode, ring duration 59 s (IE1 agent) / 21 s (US1 agent), show-transferee-as-caller disabled.
Thank you.