Hoping someone here has run into this. I’ve been at it five hours over two
days and I’m out of ideas on the customer side.
We’ve got a BYOC setup — Twilio Elastic SIP Trunk, AU local DID +61485069111,
inbound bound to a Retell agent that’s been happily running in production for
a couple of weeks. Today I tried to wire the same number for outbound on a
new agent and every single dial fails with the same error:
“Error dialing to user, SIP status code: 478 SIP error category: unknown
Error: twirp error unknown: unexpected status from INVITE response:
sip status: 478: Unresolvable destination (478/TM)”
Three attempts, identical error every time:
call_4e34cf2bb8fccd946637dc9aea8 (yesterday)
call_6a19cc12a3ee9fad27c1b18448c (today, mid-debug)
call_05a846c8cc9a050649e047d0902 (today, latest — after I bound an
outbound_agent_id to the number)
org_Jj4FW8q6nppFsADK if anyone from the team is looking.
The weird part: Twilio Support has fully verified their side. Termination URI
on the trunk (spoke-voice-au.pstn.twilio.com) is configured, the IP ACL has
all three of your documented BYOC source ranges (18.98.16.120/30,
143.223.88.0/21, 161.115.160.0/19), the number’s bound to the trunk’s Numbers
tab, AU Geo Permissions are on for both Low-Risk and High-Risk for Toll
Fraud, no sub-accounts in play. And critically — Twilio’s Debugger shows
zero error events for any of my attempts. Meaning the INVITEs aren’t even
reaching Twilio’s app layer, despite all the IP whitelisting and DNS
resolving cleanly.
So somewhere between Retell’s SBC sending the INVITE and Twilio receiving
it, something is failing — but Twilio sees nothing and Retell’s log just
says “478 Unresolvable destination” without telling me what destination it
couldn’t resolve.
What I’ve tried on the Retell side (in case any of this is the issue):
- Setting the outbound trunk config termination_uri to every format I could
think of — “spoke-voice-au”, “spoke-voice-au.pstn.twilio.com”,
“sip:spoke-voice-au.pstn.twilio.com”, with port, without port. Retell
always normalises it back to just “spoke-voice-au” so I can’t tell what
it actually sends on the wire. - Transport is locked to TCP via the API (only thing it’ll accept).
- Auth username/password is blank — relying on IP ACL.
- outbound_agent_id was unset originally, so I bound the outbound agent to
the phone number today. No change. - Agent is published at version 1 with a webhook URL set. Inbound binding
on V20 is verified untouched.
The Route header in the call response shows sip:18.98.16.122;lr which
is in your documented /30 block — that’s a hint at where you’re trying to
route the response back to. But it’s not telling me what Request-URI you’re
actually sending the INVITE to.
What I think someone here might know:
- When Retell’s SBC throws SIP 478, what destination is it actually trying
to resolve? Is it the Twilio Termination URI, or is the SBC constructing
something else upstream? - Is there an org/workspace/account-level switch to enable outbound BYOC
that I might have missed? Inbound on this same number works perfectly. - Has anyone here actually got BYOC outbound working from an AU local DID
via Twilio? Want to confirm the combo is supported and not running into
some regional restriction.
Happy to run any diagnostic from my side. SIP trace, packet capture from
Twilio’s side, whatever’s useful. Just need a hint on which thread to pull
next.
Thanks!