Inbound DID matching appears to use the To header rather than the Request-URI — transferred calls rejected as "Unknown Number"

Support Help
1

We’re seeing inbound calls rejected with SIP 486 Busy Here and X-RetellAI-Error: Unknown Number, but only when the call reaches us via a transfer from an upstream voice platform. Direct calls to the same number connect and run normally, every time — we have three successes and two failures within a 40-minute window on the same DID.

Our carrier captured the INVITE that Retell rejected. Redacted, it looks like this:

INVITE sip:+1XXXXXXXXXX@sip.retellai.com:5060 SIP/2.0 ← our Retell number
Via: SIP/2.0/UDP :5020;branch=
From: sip:+1CCCCCCCCCC@;isup-oli=00;tag= ← original caller
To: sip:+1UUUUUUUUUU@sip.retellai.com ← number originally dialed, owned by the upstream platform
Call-ID: 208196070_134089947@

Call-ID 208196070_134089947, 2026-09-14 12:41:09 UTC, post-dial delay 230 ms.

The Request-URI carries a DID that is provisioned in our Retell account. The To header carries the number the caller originally dialed, which belongs to a third-party platform and is not in our account. Retell returns “Unknown Number”, which suggests the destination agent is being resolved from To.

Per RFC 3261 §16.5 the Request-URI is the routing target, and §8.1.1.1 describes To as the logical recipient of the original request — it is deliberately left unchanged when a call is retargeted. So on any transferred, redirected or proxied call, To will routinely reference a number outside the receiving platform, while the Request-URI holds the number actually dialed at the final hop. Our carrier independently reviewed the trace and reached the same conclusion, and their CDRs record the hangup source as CALLED_PARTY — i.e. the rejection came from your side, not from any carrier-level screening.

We reproduced this on a second, newly provisioned DID with the same result, which is consistent with the Request-URI being ignored: the To header is identical in both cases regardless of which of our numbers is targeted.

These rejected calls produce no call_id in our Retell call history, presumably because the INVITE is refused before a call is created — so the SIP Call-ID above is the only identifier we can correlate on.

Is this matching behaviour intentional? If not, could inbound routing resolve on the Request-URI first and fall back to To only when the Request-URI doesn’t match a number in the account? As it stands, any call transferred into a Retell agent from another platform will fail unless that platform happens to re-originate the INVITE. Bandwidth is our telephony provider.

Happy to share the full unredacted trace, the affected DIDs and our account ID privately with support.

2

Hey @dan Could you please share your Agent ID and Org ID? This will help us investigate the issue further.

Thank You

3

Agent id: agent_c78389b18aed9b2f64103dec0d
Workspace id: org_sz0CKkETTYunDNsh

4

@Shah-Fazal any update on this?

5

Hey @dan Your issue has been escalated to the team. Once I receive a response from them, I’ll let you know.

Thank You

6

Hey @Shah-Fazal . Thank you for responding to that. I would really appreciate if you could escalate it as urgent request. We have to go live with a client and it is really important we do it tomorrow as it was supposed to be done last week.
Thanks again so much and looking forward to it

7

Hello @dan Your point about the To header versus the Request-URI is well taken. We are now checking how our inbound number resolution handled the call at 12:41:09 UTC on 14 September. I’ll come back to you once team confirms what happened on that call.

In the meantime, one option that may work around this is having the upstream platform perform the transfer with a SIP REFER, with Refer-To set to your Retell number. With REFER, the party being transferred originates a new call to the Refer-To target. The INVITE is built for your Retell number rather than retargeted from the original one, so both the Request-URI and the To header should carry your Retell number.

Thank You

8

Hey @Shah-Fazal any update on it?

9

Hey @dan no update yet, pinged team again. Once I receive a response from them, I’ll let you know.

Thank You

10

Hey @dan Team confirmed that the to header does not matter for call routing. Our inbound admission keys off the Request-URI user-part; the “Unknown Number” reject only fires when that value doesn’t match a DID on your account.

Since the same DID succeeds on direct calls and fails intermittently on transferred ones, the likely issue is wrong number in R-URI. After retargeting, some upstream platforms leave URI parameters or encodings in place, e.g. sip:+1XXXXXXXXXX;npdi;rn=+1YYY@sip.retellai.com, sip:+1XXXXXXXXXX;user=phone@…, a display-name, or percent-encoded characters.

However, you’ve confirmed that the number in Request-URI is correct, so can you please send a call trace (pcap) on the edge that sends packets to Retell so we can look into this further.

Thank You

11

Hey Dan. I read through the SIP trace and Retell’s replies. Your Request-URI/To analysis looks right to me.

If getting the client live is more important than waiting for Retell to change their inbound resolution, I’d probably stop treating this as a Retell debugging problem and put the workaround one hop upstream — either re-originate the transfer so the new INVITE is addressed cleanly to the Retell DID, or normalize the signaling at the SBC/trunk layer.

12

Noted thanks for the suggestion.