503 Multiple accounts are attempting to default ro...
# support
z
I have attempted to place calls to the number (31203694169) I have registered with a BYOC SIP Trunk. I am aware that the issue occurs when there are 2 sip trunks assigned with the same phone number or when 2 trunks attempt to connect to a single SIP account. However, at the moment I am positive, that I only have 1 trunk, 1 number and 1 SIP account, but my calls still reject with 503. I can not provide you the call details, as it does not appear in the call logs
j
It sounds like the 503 is happening before the call fully reaches your SIP endpoint, which is why it’s not showing in the logs. This is often linked to registration conflicts, auth failures, or routing issues on the trunk side. I can help you trace where the rejection is happening and validate the full call path. We’ll also check SIP headers, registration status, and carrier routing. Can you confirm which provider hosts your BYOC trunk and whether the trunk is currently showing as “registered/active”? @Zhasa [Жаса]
z
I'm using DIDLogic, and the SIP is currently is not registered on their gateway, however, it is not required for inbound calls AFAIK. I have done this previously with the exact same setup, and despite not showing up as "Registered" it still routed the calls correctly, I am receiving the 503 from VAPI's IPs
I have observed the issue previously, when using the same phone number to 2 SIP trunks and when using 2 phone numbers to 2 SIP trunks to the same SIP account
j
First, we’ll verify whether DIDLogic is actively routing the DID to your current SIP endpoint, even without registration, and confirm there’s no stale mapping from a previous trunk. Next, we’ll trace the SIP flow to see if VAPI is rejecting the call due to routing, auth, or header conflicts before it reaches DIDLogic. Then we’ll audit the DID and trunk assignments on both sides to rule out hidden duplicates or cached bindings. We’ll also validate the SIP headers and credentials to ensure they align with DIDLogic’s requirements. If you’re open to it, we can discuss this privately so I can help you troubleshoot it properly. @Zhasa [Жаса]
z
should it route to my sip endpoint? I am placing a call to a number and expect it to reach VAPI's agent
isnt the VAPI the endpoint in this case?
The calls from VAPI work flawlessly, its the inbound calls im struggling with btw
TBH i think it is a bug where the platform thinks I still have a SIP trunk/the same number configured and thus it is confused. Could you check if this number is configured for anyone else?
BTW, is the routing logic the same for inbound calls? I used number@privateAPIkey.sip.vapi.ai Like this 88005553535@123a-123a-123a-123a-123a.sip.vapi.ai