You have two phone numbers. 503650144 is the one customers call — it only serves to connect to the agent. And you also have:
Number 503650144 — Inbound Call Agent: Maja Riodental/V100, Outbound Call Agent: None (disable outbound).
Number 931c80c9fc1b446aa86fa0cede7db353 — Inbound Call Agent: None (disable inbound), Outbound Call Agent: Maja Riodental/V100. This one is only for outbound calls.
When calling from number 503650144, you present yourself with that number 503650144 — and in Poland this is not allowed, as it falls under the so-called Bezpieczna Zatoka regulation. The end user must present itself with the SIP trunk username, in this case 931c80c9fc1b446aa86fa0cede7db353, and only on that basis does the operator assign the end user the number they are allowed to present.
You should be calling from the second number, and there should be an option at the agent level to choose which trunk to use for outbound calls.
Also, there should generally be an option for authentication via URI — it is not serious for a company of your size not to have this option. If it existed, connections would be free for us, but as it stands they cost as much as butter in the times of law and justice.
Hey, thanks for the detailed writeup. There’s more control here than it first looks, so a few things that should help.
Outbound caller ID comes from the from_number on the call, not from the inbound number. So to present from your second number, place the outbound call using that number as the from_number. Each number you import carries its own trunk settings, so choosing the from_number is effectively how you pick the trunk. There isn’t a separate “choose trunk” toggle on the agent itself; it’s driven by the number you dial from.
On authentication, you are not stuck with IP whitelisting. Credential based SIP auth is supported for custom telephony. When you import a number via SIP you set sip_trunk_auth_username and sip_trunk_auth_password (in the UI: select credentials as the authentication method, then add the username and password). So Retell can authenticate to your trunk with the SIP username rather than just presenting a raw number, which is the piece that maps to what your operator wants under Bezpieczna Zatoka.
Where I’ll be honest: I can’t confirm Retell’s flow fully satisfies the Polish setup where the operator authenticates the trunk by username and then assigns the permitted CLI itself. Retell still sends the from_number in the From/PAI, so whether your carrier accepts that or overrides it based on the trunk login is an operator side thing worth testing. If the exact URI/digest scheme your carrier needs isn’t matching, that’s the one to raise with Retell support directly.
One question so I can point you better: are these numbers imported via your own SIP trunk (termination URI plus credentials), or purchased through Retell? That changes what’s in your control.
