https://vapi.ai/ logo
Join Discord
Powered by
BYO SIP inbound from Claro returns 404 despite exa...
# support
g
Hi Vapi team, BYO SIP inbound calls from Claro reach Vapi, but Vapi responds 
404 Not Found
, even though the Request-URI user-part matches an active BYO phone number alias. Org ID: 
959b692f-b36c-4461-8335-c959c4290cad
Relevant BYO phones:
Copy code
text
8fbe63df-644b-411f-bfe7-59f14215ecfe
Cabecera Claro 2 (900)
number: +541140071900
numberE164CheckEnabled: true
assistantId: a27477da-f58d-4242-8308-2210b313d38f
credentialId: 6ee8d2b3-5b51-47a5-a29f-af49b7db57b5
status: active

a65a7069-869d-41da-a577-0116caeefeef
Alias Claro 2 - 1140071900
number: 1140071900
numberE164CheckEnabled: false
assistantId: a27477da-f58d-4242-8308-2210b313d38f
credentialId: 6ee8d2b3-5b51-47a5-a29f-af49b7db57b5
status: active
Credential gateway configuration after cleanup:
Copy code
json
[
  {
    "ip": "ollsbc.tramavirtclaro.com",
    "port": 5060,
    "outboundEnabled": true,
    "inboundEnabled": false
  },
  {
    "ip": "177.234.129.52",
    "port": 5060,
    "outboundEnabled": true,
    "inboundEnabled": true
  }
]
Claro confirmed multiple public inbound attempts reached Vapi. Example INVITE:
Copy code
sip
INVITE sip:1140071900@44.238.177.138;user=phone SIP/2.0
Via: SIP/2.0/UDP 177.234.129.52:5060
From: "1166301515" <sip:1166301515@mssoll02.claro.tel;user=phone>
To: <sip:+541140071900@44.238.177.138;user=phone>
Contact: <sip:177.234.129.52:5060;...>
Transport: UDP
Vapi response: 
SIP/2.0 404 Not Found
Example SIP Call-IDs from today: * DB84175EE971EADADA705517@0570ffffffff * 4E1D0E94BE2804EB2971F317@0a70ffffffff * 523579C2597B155E40206497@0d70ffffffff Question: Why is Vapi returning 404 when the incoming Request-URI user-part is exactly 
1140071900
, and there is an active BYO phone number with 
number: "1140071900"
, same credentialId, assistant assigned, and E.164 validation disabled? Does Vapi match BYO SIP inbound by Request-URI user-part? To header? credentialId / source IP? providerResourceId? another internal routing key? What configuration is required for this INVITE?
c
Hi, We investigated the issue and found that most of the failures are occurring due to incorrect SIP credential configuration. The connection should use the following SIP URI format: 
{phoneNumber}@<credential_id>.sip.vapi.ai
For reference, please review the SIP trunk documentation here: [Vapi SIP Trunk Documentation](https://docs.vapi.ai/advanced/sip/sip-trunk?utm_source=chatgpt.com) Additionally, please verify the configuration settings on your provider side: • If both Inbound and Outbound are enabled together → this can cause issues. • If only Outbound is enabled and a domain name or IP address is configured → this setup should work correctly. • If Inbound is enabled with a domain name configured → this can also lead to issues. Please review these settings and try again. If the issue persists, feel free to share the updated call details and we’ll continue investigating. https://cdn.discordapp.com/attachments/1508945698958217366/1508983871205539991/image.png?ex=6a19807e&is=6a182efe&hm=ee516b1745c1e0fd2a1e8230849cfc6e91396221d0aca8ed9dfae6fd69728568&
g
Thanks. This helps. To confirm: are you saying that, for BYO SIP inbound, Claro should not send the INVITE to the raw Vapi SBC IP like this?
Copy code
sip
INVITE sip:1140071900@44.238.177.138;user=phone SIP/2.0
And instead Claro must send the Request-URI to the credential-specific Vapi SIP domain? For our credential: 
credentialId: 6ee8d2b3-5b51-47a5-a29f-af49b7db57b5
Should the provider send exactly one of these? 
INVITE sip:1140071900@6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai SIP/2.0
or 
INVITE sip:+541140071900@6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai SIP/2.0
Also, we will update the gateway configuration to split directions:
Copy code
json
[
  {
    "ip": "ollsbc.tramavirtclaro.com",
    "port": 5060,
    "outboundEnabled": true,
    "inboundEnabled": false
  },
  {
    "ip": "177.234.129.52",
    "port": 5060,
    "outboundEnabled": false,
    "inboundEnabled": true
  }
]
Please confirm whether this is the expected configuration. Once you confirm the exact inbound SIP URI, we will ask Claro to update the inbound Request-URI accordingly.
--- Update after applying the gateway split you suggested. We updated the Claro credential so that:
Copy code
json
[
  {
    "ip": "ollsbc.tramavirtclaro.com",
    "port": 5060,
    "outboundEnabled": true,
    "inboundEnabled": false,
    "outboundProtocol": "udp"
  },
  {
    "ip": "177.234.129.52",
    "port": 5060,
    "outboundEnabled": false,
    "inboundEnabled": true,
    "outboundProtocol": "udp"
  }
]
Then we ran a new public inbound test to 
+541140071900
. Result: * Caller still hears the carrier message equivalent to “number not in service”. * No useful inbound call appears in the Vapi dashboard. * Previous Claro traces show the INVITE reaches Vapi as:
Copy code
sip
INVITE sip:1140071900@44.238.177.138;user=phone SIP/2.0
We already have an active BYO phone number alias:
Copy code
text
number: 1140071900
numberE164CheckEnabled: false
assistantId: a27477da-f58d-4242-8308-2210b313d38f
credentialId: 6ee8d2b3-5b51-47a5-a29f-af49b7db57b5
Can you please confirm the exact inbound SIP URI Claro must send to? Should it be: 
sip:1140071900@6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai
instead of sending to the raw Vapi SBC IP 
44.238.177.138
? We need the exact provider-side Request-URI format to give Claro.
c
Yes, Claro must stop sending the INVITE to the raw Vapi SBC IP (44.238.177.138) Claro must send the Request URI to your credential-specific Vapi SIP domain. Please ask them to update their configuration to send this: INVITE sip:1140071900@6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai SIP/2.0
g
Update on the Claro inbound issue. Claro updated the Request-URI to the credential-specific Vapi SIP domain. New INVITE:
Copy code
sip
INVITE sip:1140071900@6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai;user=phone SIP/2.0
Via: SIP/2.0/UDP 177.234.129.52:5060
From: "1166301515" <sip:1166301515@mssoll02.claro.tel;user=phone>
To: <sip:+541140071900@6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai;user=phone>
Call-ID: 130B4ACCFAEE11FC21DE0F97@1470ffffffff
Transport: UDP
Vapi now responds:
Copy code
sip
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest realm="6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai", algorithm=MD5, qop="auth", nonce="178033481517700"
So the previous 404 routing issue appears resolved. We are now blocked at SIP authentication. Current gateway config:
Copy code
json
[
  {
    "ip": "ollsbc.tramavirtclaro.com",
    "port": 5060,
    "outboundEnabled": true,
    "inboundEnabled": false,
    "outboundProtocol": "udp"
  },
  {
    "ip": "177.234.129.52",
    "port": 5060,
    "outboundEnabled": false,
    "inboundEnabled": true,
    "outboundProtocol": "udp"
  }
]
Questions: 1. Should inbound calls from 
177.234.129.52
be accepted by IP allowlist since that gateway is configured with 
inboundEnabled: true
? 2. If yes, why is Vapi returning 
401 Unauthorized
? 3. If Digest authentication is required for inbound to 
<credential_id>.sip.vapi.ai
, where do we configure the inbound SIP username/password in Vapi? 4. What exact username/password should Claro use to answer this Digest challenge? 5. Is 
;user=phone
in the Request-URI acceptable? We need to know whether the next step is: * configure Claro to respond to SIP Digest, or * fix the Vapi credential/configuration so inbound is accepted by IP allowlist.
--- Additional credential inspection result. We inspected the current BYO SIP credential via API after the gateway split. Credential ID: 6ee8d2b3-5b51-47a5-a29f-af49b7db57b5 Current gateway config:
Copy code
json
[
  {
    "ip": "ollsbc.tramavirtclaro.com",
    "port": 5060,
    "inboundEnabled": false,
    "outboundEnabled": true,
    "outboundProtocol": "udp"
  },
  {
    "ip": "177.234.129.52",
    "port": 5060,
    "inboundEnabled": true,
    "outboundEnabled": false,
    "outboundProtocol": "udp"
  }
]
We also inspected authentication-related properties on the credential, and there are no visible auth / authentication / username / password / inbound auth fields. So the current blocker is: Claro sends:
Copy code
sip
INVITE sip:1140071900@6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai;user=phone SIP/2.0
Via: SIP/2.0/UDP 177.234.129.52:5060
Vapi responds:
Copy code
sip
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest realm="6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai", algorithm=MD5, qop="auth"
Question: If inbound from 
177.234.129.52
is configured with 
inboundEnabled: true
, why is Vapi still issuing a Digest challenge? And if Digest is required, where exactly do we configure the inbound SIP username/password? The credential object does not expose any visible inbound authentication fields. We need a definitive answer: * Should this route work by IP allowlist? * Or must Claro authenticate with Digest? * If Digest is required, what exact credentials / fields should be configured and where?
c
Can you confirm Claro’s actual public signaling source IP and add it as a gateway with inboundEnabled: true? The IP in the SIP Via header may differ from the source IP reaching Vapi, which would cause the 401 Unauthorized. Please try this and let me know if it resolves the issue.
g
Thanks, that makes sense. Can you please tell us what source IP Vapi actually sees for this INVITE? SIP Call-ID: 130B4ACCFAEE11FC21DE0F97@1470ffffffff INVITE received: INVITE sip:1140071900@6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai;user=phone SIP/2.0 Claro trace shows: Via: SIP/2.0/UDP 177.234.129.52:5060 SIP Local IP: 177.234.129.52 SIP Remote IP: 44.238.177.138 But if Vapi sees a different packet source IP after NAT, we need that exact IP to add it as an inbound gateway. Please share the actual source IP observed by Vapi for this Call-ID.
--- We checked the PCAP from Claro. The actual IP packet for the INVITE to Vapi appears to have: - IP source: 177.234.129.52 - IP destination: 44.238.177.138 - UDP: 5060 → 5060 This matches the SIP Via and Contact: - Via: SIP/2.0/UDP 177.234.129.52:5060 - Contact: The 401 response comes back from: - IP source: 44.238.177.138 - IP destination: 177.234.129.52 So it does not look like Claro is NATing through a different public signaling source IP. The public source IP appears to be exactly 177.234.129.52, which is already configured as inboundEnabled=true in the credential. Given that, why is Vapi still returning 401 Unauthorized? Should this work by IP allowlist, or does inbound to credential_id.sip.vapi.ai always require Digest authentication?
--- Additional test result. We temporarily changed the credential to inbound-only to rule out mixed inbound/outbound gateway behavior. Temporary gateway config tested:
Copy code
[
  {
    "ip": "177.234.129.52",
    "port": 5060,
    "inboundEnabled": true,
    "outboundEnabled": false,
    "outboundProtocol": "udp"
  }
]
Then we ran a new inbound test to +541140071900. Result: - Same behavior: call disconnects. - No call object appears in Vapi dashboard. - This is consistent with the INVITE being rejected at SIP level before call creation. We also checked the PCAP from Claro. The actual IP packet for the INVITE to Vapi appears to be: IP source: 177.234.129.52 IP destination: 44.238.177.138 UDP: 5060 → 5060 This matches the SIP Via and Contact: Via: SIP/2.0/UDP 177.234.129.52:5060 Contact: So this does not look like a NAT/source-IP mismatch. The public source IP appears to be exactly 177.234.129.52, which is already configured as inboundEnabled=true. We restored the split gateway configuration afterward:
Copy code
[
  {
    "ip": "ollsbc.tramavirtclaro.com",
    "port": 5060,
    "outboundEnabled": true,
    "inboundEnabled": false,
    "outboundProtocol": "udp"
  },
  {
    "ip": "177.234.129.52",
    "port": 5060,
    "outboundEnabled": false,
    "inboundEnabled": true,
    "outboundProtocol": "udp"
  }
]
Given this, can you confirm definitively: 1. Should inbound to .sip.vapi.ai work by IP allowlist? 2. If yes, why is Vapi returning 401 to an INVITE from 177.234.129.52? 3. If no, where do we configure inbound Digest credentials in Vapi? 4. What username/password should Claro use to respond to the 401 challenge?
c
can you plese confirm these details about your setup 1- The (Inbound) failures are mostly because wrong creds. the connection should be via: correct SIP URI--->{phoneNumber}@.[sip.vapi.ai](http://sip.vapi.ai) ref: [https://docs.vapi.ai/advanced/sip/sip-trunk](https://docs.vapi.ai/advanced/sip/sip-trunk) 2- Check what is configure here: • if outbound/inbound both checked -- issue • if outbound checked and domain name or ip address is given--- no issue • if inbound checked and domain name is give --issue https://cdn.discordapp.com/attachments/1508945698958217366/1512205603705983006/image.png?ex=6a233eb7&is=6a21ed37&hm=55b9f3e5f23aa279dfda44beae702e102ca3fa56d7bc55dbef57b0f4e0ac5f40&
g
Thanks. We already applied that configuration. Current setup for credential: Credential ID: 
6ee8d2b3-5b51-47a5-a29f-af49b7db57b5
Provider-side inbound Request-URI is now:
Copy code
sip
INVITE sip:1140071900@6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai;user=phone SIP/2.0
So Claro is no longer sending to the raw Vapi SBC IP in the Request-URI. Current gateway configuration is split by direction:
Copy code
json
[
  {
    "ip": "ollsbc.tramavirtclaro.com",
    "port": 5060,
    "outboundEnabled": true,
    "inboundEnabled": false,
    "outboundProtocol": "udp"
  },
  {
    "ip": "177.234.129.52",
    "port": 5060,
    "outboundEnabled": false,
    "inboundEnabled": true,
    "outboundProtocol": "udp"
  }
]
So: * inbound + outbound are not both enabled on the same gateway * the inbound gateway is an IPv4 address, not a domain * the outbound gateway is the Claro domain We also checked the Claro PCAP. The actual packet for the INVITE to Vapi appears to be:
Copy code
text
IP source: 177.234.129.52
IP destination: 44.238.177.138
UDP: 5060 → 5060
This matches the SIP headers:
Copy code
sip
Via: SIP/2.0/UDP 177.234.129.52:5060
Contact: <sip:177.234.129.52:5060...>
But Vapi still responds:
Copy code
sip
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest realm="6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai", algorithm=MD5, qop="auth"
We also temporarily tested an inbound-only credential with only:
Copy code
json
[
  {
    "ip": "177.234.129.52",
    "port": 5060,
    "inboundEnabled": true,
    "outboundEnabled": false,
    "outboundProtocol": "udp"
  }
]
Same behavior. So the remaining question is should this inbound call from 
177.234.129.52
be accepted by IP allowlist, or does Vapi require SIP Digest authentication for inbound calls to 
<credential_id>.sip.vapi.ai
? If Digest is required, where exactly do we configure the inbound SIP username/password, and what credentials should Claro use?
--- Small additional test result: we also tried changing the inbound gateway from 177.234.129.52/32 to 177.234.129.52/24 to rule out a source-IP mismatch within the same public range. Result: Same behavior. The call still disconnects and no useful inbound call appears in Vapi. We restored the gateway back to /32.
--- Important additional context. We found another Vapi Discord support thread with a very similar inbound BYO SIP issue: 
“Inbound BYO SIP Trunk - 401 Unauthorized (IP-auth not working)”
The reported pattern is the same: - carrier is IP-auth only - INVITE reaches Vapi - Vapi responds 401 Unauthorized / Digest challenge - trusted peer IP is already configured In that thread, a support reply stated that this is a known friction point with BYO SIP trunking when the carrier is IP-auth only, and that Vapi may default to Digest challenge even when a trusted peer IP is configured, requiring a backend flag to bypass Digest for the org / trusted peer. Our case now matches same pattern. We also tested widening the inbound gateway netmask from /32 to /24 and it did not change the behavior. Can you please confirm whether our org/credential needs the same backend trusted-peer / IP-auth bypass flag enabled? If yes, please enable inbound IP-auth / no-Digest challenge for: - orgId: 959b692f-b36c-4461-8335-c959c4290cad - credentialId: 6ee8d2b3-5b51-47a5-a29f-af49b7db57b5 - trusted peer IP: 177.234.129.52
c
I'm investigating the flag requirements
can you share the discord thread link please
g
Sure, here is the thread I was referring to: https://discord.com/channels/1211482211119796234/1502458171229470811 The relevant part is the discussion around inbound BYO SIP returning 401 for an IP-auth-only carrier, and the mention of a backend flag to bypass Digest for a trusted peer IP.
News?
c
There is no such flag for it. At the end of the thread, it mentions that. "If inbound routing is configured, call your phone number from an external line." Can you confirm if you are following this
g
Yes, we are following that. Inbound routing is configured and we are testing from an external line. Current setup: - Provider sends the INVITE to the credential-specific SIP URI, not the raw Vapi SBC IP: INVITE sip:1140071900@6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai;user=phone SIP/2.0 - BYO phone number exists: number: 1140071900 numberE164CheckEnabled: false assistantId: a27477da-f58d-4242-8308-2210b313d38f credentialId: 6ee8d2b3-5b51-47a5-a29f-af49b7db57b5 status: active - Current gateway config:
Copy code
[
  {
    "ip": "ollsbc.tramavirtclaro.com",
    "port": 5060,
    "inboundEnabled": false,
    "outboundEnabled": true,
    "outboundProtocol": "udp",
    "netmask": 32
  },
  {
    "ip": "177.234.129.52",
    "port": 5060,
    "inboundEnabled": true,
    "outboundEnabled": false,
    "outboundProtocol": "udp",
    "netmask": 32
  }
]
- PCAP confirms the actual packet source appears to be: IP source: 177.234.129.52 IP destination: 44.238.177.138 UDP: 5060 → 5060 - We also tested "177.234.129.52/24" temporarily to rule out source-IP mismatch. Same behavior. The current behavior is: SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm="6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai", algorithm=MD5, qop="auth" So the external call is reaching Vapi, but Vapi is challenging with Digest before creating a call. Can you please confirm what exact part of the required inbound routing setup is still missing? If this route should work by IP allowlist, why is Vapi challenging an INVITE from "177.234.129.52"? If this route requires Digest authentication, where do we configure the inbound SIP username/password and what username should Claro use?
c
can you share the pcap
g
Attached is the PCAP for the failed inbound attempt returning 401. Relevant packets: Frame 3: IP source: 177.234.129.52 IP destination: 44.238.177.138 UDP: 5060 → 5060 INVITE sip:1140071900@6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai;user=phone SIP/2.0 SIP Call-ID: 130B4ACCFAEE11FC21DE0F97@1470ffffffff Frame 5: IP source: 44.238.177.138 IP destination: 177.234.129.52 SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm="6ee8d2b3-5b51-47a5-a29f-af49b7db57b5.sip.vapi.ai", algorithm=MD5, qop="auth" This PCAP appears to show that the actual packet source reaching Vapi is 177.234.129.52, which is already configured as inboundEnabled=true on the credential. Please have engineering verify the edge-side gateway allowlist match result for this Call-ID/timestamp. https://cdn.discordapp.com/attachments/1508945698958217366/1514634352087142540/1166301515_1166301515_mssoll02.claro.tel_to__541140071900_6ee8d2b3_5b51_47a5_a29f_af49b7db57b5.sip.vapi.ai.pcap?ex=6a2c14aa&is=6a2ac32a&hm=53fe6eb671edf468bc2117283f7f8b91b7c921fe04de9e647eb7e4aa4719c82b&
PreviousNext
Powered by