404 "No trunk found" — Zadarma (Bulgaria) to LiveKit Cloud — GeoDNS routing issue?

Telephony
1

Hi,

We’re getting 404 No trunk found on every inbound SIP call from Zadarma (Bulgarian SIP provider) to our LiveKit Cloud project. After extensive debugging we believe this is a GeoDNS/anycast routing issue similar to the one described here: SIP 404 “No trunk found” — DNS routing mismatch on LiveKit Cloud

Environment:

  • LiveKit Cloud project SIP URI: ytlj4qounpm.sip.livekit.cloud

  • SIP provider: Zadarma (zadarma.com) — Bulgarian virtual number

  • Inbound trunk ID: ST_o3tpcif66zzu

  • Dispatch rule configured with agentName matching a running Python agent :white_check_mark:

What the SIP log from Zadarma shows:

To: <sip:35924373387@ytlj4qounpm.sip.livekit.cloud>
SIP/2.0 404 No trunk found
Via: SIP/2.0/UDP 185.45.152.192:5060
src: 185.45.152.200 (Zadarma PBX)
dst: 161.115.161.184:5060

What we confirmed:

  • TCP port 5060 open and responding :white_check_mark:

  • nslookup ytlj4qounpm.sip.livekit.cloud → 161.115.161.26 and 161.115.161.184 :white_check_mark:

  • Zadarma IP ranges correctly added to allowedAddresses :white_check_mark:

  • LiveKit → Telephony → Calls shows 0 calls — never registers anything

  • Call forwarding to a real phone number works perfectly :white_check_mark:

  • Python agent running and registered as bulgarian-agent :white_check_mark:

Trunk configurations tested (all return 404):

  • With numbers: ["+35924373387", "35924373387"]

  • With numbers: [] (empty — accept any number)

  • With and without allowedAddresses

  • With and without authUsername/authPassword

Suspected cause: Zadarma sends from Bulgaria and likely hits a different LiveKit SIP server than the one where our trunk is registered — same pattern as the DNS routing mismatch thread above.

Question:

  1. Is ytlj4qounpm.eu.sip.livekit.cloud a valid EU region-pinned endpoint we can use?

  2. Will region pinning solve the GeoDNS mismatch?

  3. Is there anything else in the trunk configuration we might be missing?

Thanks!

2

This is almost always either wrong phone number or sometimes you have the number defined twice maybe even twice in the same trunk.

3

I took a look at the server logs and I see the issue. The problem is you are using the WebRTC URI instead of the SIP URI. Look here and use the SIP URL for the SIP invites: