Hi, I have an inbound SIP issue and my email ticket may be slow. Setup: byo-sip-trunk credential id 329aa07d-705b-41d9-b709-a82423239d7e, gateway ip 194.140.135.80. DID +34910052268 is a byo-phone-number linked to that credential, with an assistant assigned. My provider (Netelip) routes inbound calls to +34910052268@329aa07d-705b-41d9-b709-a82423239d7e.sip.vapi.ai and sends SIP only from 194.140.135.80. Problem: inbound calls to +34910052268 fail immediately (caller hears "call failed", no ring) and NO call record is created in Vapi, so it is rejected at SIP signaling. I previously had a wrong gateway IP and got 401 Unauthorized; I fixed the IP and it still fails. Can someone check the SBC logs for inbound INVITEs to +34910052268 from 194.140.135.80 and tell me what SIP response Vapi sends and why? Also: should the byo-phone-number be E.164 (+34910052268) or without the "+"?

You’re right to focus on SIP signaling since no call record in Vapi usually means the INVITE is getting rejected before it reaches the assistant layer. Based on your setup, I’d verify the exact Request-URI formatting, auth expectations on the SBC, and whether the DID mapping matches the inbound INVITE headers Vapi expects. The previous 401 suggests the trunk is reachable now, so this may be a DID normalization or header-routing mismatch rather than connectivity itself. I can help trace the likely failure path and narrow down exactly what Vapi is rejecting. Do you know if Netelip is sending the INVITE To/Request-URI with the “+” included or stripping it to national format? @George

Thanks! Netelip ran a fresh test call and captured the SIP trace. Answering your question: Netelip sends the Request-URI and To header WITH the leading "+": sip:+34910052268@... There is also a header X-Called-DDI: 34910052268 (without +). My byo-phone-number is registered as +34910052268. Trace (AFTER I corrected the gateway IP — the INVITE now correctly comes from 194.140.135.80, which matches my byo-sip-trunk gateway): Netelip 194.140.135.80 -> Vapi 44.229.228.186 INVITE sip:+34910052268@329aa07d-705b-41d9-b709-a82423239d7e.sip.vapi.ai SIP/2.0 From: "951200000" ;tag=as74309db6 To: Contact: X-Called-DDI: 34910052268 Vapi 44.229.228.186 -> Netelip 194.140.135.80 SIP/2.0 100 Trying SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm="329aa07d-705b-41d9-b709-a82423239d7e.sip.vapi.ai", algorithm=MD5, qop="auth", nonce="177952701776700" So even though the INVITE now comes from the whitelisted gateway IP, Vapi still challenges every inbound INVITE with 401 digest auth, and my provider sends no credentials, so the call fails. The IP-based byo-sip-trunk gateway is NOT suppressing the digest challenge. Questions: 1. For inbound on a byo-sip-trunk, how should this authenticate? Should Vapi accept by source IP (and if so, why is it still challenging)? Or must my provider send the INVITE with SIP digest credentials — and if so, where do I set the username/password Vapi will accept? 2. Netelip also reports REGISTER requests FROM your SBC (44.229.228.186) TO their server (vpbx.netelip.com) for 5422388100616@5548f645-16b8-414a-b1ad-2c769c33079e.sip.vapi.ai, answered with 403 Forbidden. My account only has ONE credential (329aa07d-...). Is Vapi supposed to register to my provider, and is that 5548f645 credential related to my account?

At this stage I honestly don’t think the issue is on Netelip anymore, the SIP trace already proves the INVITE is reaching Vapi correctly and the SBC is actively responding. The bigger concern is that Vapi is still forcing digest auth even after the source IP matches, plus the unexpected REGISTER attempts from a completely different credential ID strongly suggest there may be a stale or misprovisioned SIP trunk object on the backend. What I’d personally test next is creating a completely fresh BYO SIP credential, whitelisting only "194.140.135.80", then rebinding the DID + assistant to that new credential and retesting immediately. If the 401 disappears, that would confirm the original credential is internally misconfigured rather than a carrier issue. I’ve worked through similar SIP/SBC routing edge cases before, so if you’re open to it, happy to dig into this with you privately and help isolate it faster. @George

Thanks, that's a helpful angle. I'd like to keep this in the public thread so the Vapi team has full visibility. Your idea — that my BYO SIP trunk credential may be stale or misprovisioned on the backend — makes sense. Could a Vapi team member check whether that credential and its gateway (IP 194.140.135.80) are correctly set up on your side? It's the "Netelip Shams Trunk" credential from my original post above. I can recreate it if needed, but I'd like to confirm it's a provisioning issue first, since recreating it would also change the SIP subdomain my carrier routes to. One more question: for inbound on a BYO SIP trunk, should Vapi accept the call by source IP, or is SIP authentication required? The trace shows Vapi still rejecting the call even though it arrives from the whitelisted gateway IP.

@Matt asking members to work with you privately in support threads is against our rules. If you have a service to offer, the only place to do so is in #1503535612689645679 See this thread for more information regarding this rule https://discord.com/channels/1211482211119796234/1211484481848873020/1507507852757958848

Thanks Amanda. Setting that aside — could a Vapi team member help with my original issue in this thread? Inbound SIP calls to my BYO SIP trunk still return 401 even though the INVITE arrives from my whitelisted gateway IP (194.140.135.80). What is the correct way to authenticate inbound calls on a BYO SIP trunk, and could someone check whether my trunk credential is correctly provisioned on your side?

Everything posted in here does get routed to support. I cannot speak to the queuing system in place but someone will be in touch.

Hi, I checked the logs for your setup and found the issue. Your Netelip calls are reaching Vapi’s SIP edge correctly, but they are being rejected before reaching the application layer because

numberE164CheckEnabled

is currently enabled on the BYO phone number configuration. With this enabled, the SBC performs strict E.164 matching on the SIP

To:

header, and the match is failing at the edge level. That is why: • no inbound call record appears in the dashboard • the call is dropped before Vapi fully processes it Your gateway IP configuration change on May 22 was correct and resolved the earlier authentication issue. The remaining issue is this strict E.164 validation setting. Please disable it using:

curl -X PATCH https://api.vapi.ai/phone-number/24886e2c-8356-469d-bbeb-c2d562d6ec05 \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"numberE164CheckEnabled": false}'

After making this change: 1. Ask Netelip to place another test call 2. Check Dashboard → Calls 3. If the call record appears, the SIP INVITE is successfully reaching Vapi’s application layer Also: • Your number format

+34910052268

is already correct • The issue is not the stored number format itself, only the strict matching behavior enabled by

numberE164CheckEnabled

If the issue still persists after disabling the setting, please share a fresh test timestamp/call attempt and we can investigate further.

Hello Vapi support, I need urgent help with a BYO SIP Trunk credential reassignment on a Phone Number. I've done diagnostic work and confirmed an issue. Setup: - Phone Number "Mayordomo — Asistente Jorge", DID +34910052268 - Phone Number ID: db861579-3de2-4593-892b-89b880fbdcc4 - Currently assigned to old SIP credential (a48c0b5c-...). - I created a new SIP credential "Netelip LiveKit Mayordomo" (id: 6118bf8e-e059-4e2f-9f12-5d6e317b0d94) per recommendation from my SIP provider (Netelip) who confirmed a Vapi bug with hostname "livekit.netelip.com" (they gave me IP 185.8.244.81 as workaround). Tests done: 1. Outbound test calls with old credential: "Customer Busy" immediately (~0s, no SIP logs). 2. PATCH'd credentialId via API to the new one (returned 200 OK with updated credentialId verified in GET). 3. Outbound test calls after PATCH: STILL "Customer Busy" immediately, no logs. 4. INBOUND BREAKS: after PATCH, calls TO the DID +34910052268 land on a female voice voicemail-like message (not the assigned assistant). This is a regression caused by the PATCH. 5. Reverted PATCH: inbound restored to normal Mayordomo assistant. Questions: 1. Is changing credentialId of a BYO Phone Number unsupported? The PATCH succeeded but broke routing. 2. How can I properly reassign a SIP Trunk credential to an existing BYO Phone Number? 3. Could you check why the new credential 6118bf8e-... doesn't accept outbound calls when assigned? Is there a registration issue at IP 185.8.244.81? Thanks for the help.

Hi, Please share the call id, so we can investigate. In the meantime please be noted: 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 3- Also, please add authentication configuration https://cdn.discordapp.com/attachments/1507609229958053908/1512009635396321330/image.png?ex=6a228834&is=6a2136b4&hm=25b92401603de49dd8aea5d44d6ac141d4ccb2c771f5fcf55a575d39d3dac9a1&

Thanks for the quick response! You're right — my current SIP Trunk "Netelip LiveKit Mayordomo" (id: 6118bf8e-e059-4e2f-9f12-5d6e317b0d94) has BOTH inbound AND outbound checked, with IP 185.8.244.81. That matches your "issue" case in point 2. Call IDs for investigation: - 019e771e-db81-711b-9b71-eeb5e3a0afca (older test, original creds) - 019e848b-d9c1-7003-a0b7-982fae566b1f (yesterday, after PATCH credentialId to new credential) Two follow-up questions before I make changes: 1. SEPARATION OF DIRECTIONS: Should I create TWO separate SIP Trunks for the same SIP provider (Netelip)? - Trunk A: outbound only + IP 185.8.244.81 (for Mayordomo making outbound calls) - Trunk B: inbound only (for Mayordomo receiving calls) If yes, how do I assign BOTH to the same Phone Number (+34910052268)? Is it via credentialId for outbound and a different field for inbound? 2. ASSIGNMENT METHOD: The doc you referenced (https://docs.vapi.ai/advanced/sip/sip-trunk) shows {phoneNumber}@.sip.vapi.ai as the SIP URI. That's the URL my SIP provider should call to reach Vapi (inbound to Vapi). But for OUTBOUND from Vapi to my provider, does Vapi use the credential's gateway IP/domain directly? And does each Phone Number have only ONE credentialId, or can it have separate inbound/outbound credentials? 3. AUTHENTICATION (point 3): My current "Netelip LiveKit Mayordomo" credential has SIP Registration enabled with username +34910052268, password set, realm 185.8.244.81. Is this correct for outbound, or should I leave SIP Registration disabled and use a different auth mechanism? Thanks for your help.

Hi, No, you do not need to create two separate SIP trunks for this. You can create a single SIP trunk and configure multiple gateways within it: • One gateway dedicated to inbound calls • One gateway dedicated to outbound calls This is the recommended setup when using the same SIP provider for both inbound and outbound traffic. Just ensure that the inbound and outbound configurations are separated at the gateway level rather than by creating separate SIP trunks. Thank you.

Hi Vapi support team, Update on our SIP Trunk issue (LiveKit Mayordomo, credentialId 6118bf8e-e059-4e2f-9f12-5d6e317b0d94, DID +34910052268). We applied the architectural change you recommended (single SIP trunk with two specialized gateways: inbound-only + outbound-only on 185.8.244.81) via API PATCH. Both gateways are visible in the dashboard with correct directions. We also re-applied authPassword and set outboundLeadingPlusEnabled: true. Outbound test result: - Before PATCH: SIP customer-busy immediate - After PATCH gateways only: SIP 401 Unauthorized - After PATCH gateways + password + leadingPlus: SIP 503 Service Unavailable - Vapi call ID: 019ea0c7-1979-7001-82b1-5a38a164423e (timestamp 2026-06-07T06:31) Reassigning PhoneNumber credentialId from old (a48c0b5c, Suministros legacy SIP trunk that lacks CallerID auth for +34910052268) to the LiveKit one (6118bf8e) BREAKS INBOUND: instead of routing to our assistant Mayordomo (id 6c82c3d6-95d1-40cc-bbc7-c6eb8e9f1e8a), incoming calls answer with a generic female voice / default voicemail that hangs up after a few seconds. We contacted our SIP provider Netelip. They confirmed in writing: "The DID +34 910 05 22 68 is being routed correctly from our network. The issue appears to be on the destination platform (SIP registration, routing). From our side as interconnection bridge, we recommend reviewing the configuration on the receiving platform."

Hi, It seems there may be an issue with your setup. Could you please share: • A screenshot of your gateway configuration • A screenshot of your authentication settings to confirm they are configured correctly • A PCAP file for the call, if you have one available • If you have whitelisted both the IPs: 44.229.228.186/32 & 44.238.177.138/32 Also, please verify that the inbound SIP URI is tied to the correct Credential ID (UUID). The format should be:

sip:{phoneNumber}@{credential_id}.sip.vapi.ai

To help protect any sensitive information, we recommend sending the screenshots and PCAP file via email rather than Discord (support@vapi.ai) Thanks, Vapi Support Team

Subject: Re: SIP Trunk Issue — LiveKit Mayordomo +34910052268 — attached screenshots + Netelip coordination pending Hi Vapi support team, Thanks for the detailed pointers. Attached: 1. Screenshot of gateway configuration (Netelip LiveKit Mayordomo trunk — 2 specialized gateways on 185.8.244.81) 2. Screenshot of authentication settings (SIP Registration: Domain 185.8.244.81, Username +34910052268, Realm 185.8.244.81) PCAP file: requested to Netelip, will forward as soon as they provide it (their SBC has access to SIP capture, we don't from our side). IPs 44.229.228.186/32 and 44.238.177.138/32: requested to Netelip to confirm whitelist status. Will confirm in next email. Critical follow-up question on the inbound SIP URI format you mentioned: You stated the format should be: sip:{phoneNumber}@{credential_id}.sip.vapi.ai For our Mayordomo it should be: sip:+34910052268@6118bf8e-e059-4e2f-9f12-5d6e317b0d94.sip.vapi.ai Our hypothesis: when we PATCH'd the PhoneNumber credentialId from the old credential (a48c0b5c-...) to the new LiveKit one (6118bf8e-...), Netelip is likely still routing the DID to the OLD SIP URI (with a48c0b5c). That would explain why incoming calls answer with a generic voicemail / female voice instead of our Mayordomo assistant (6c82c3d6-...): Vapi doesn't find the assistant binding at the old URI under the new credential context. Could you confirm: (a) Is there a fallback voicemail in Vapi when a SIP URI is received but the credential doesn't bind it to an assistant? (b) For outbound, is there any required field beyond gateways + outboundAuthenticationPlan + outboundLeadingPlusEnabled that we might be missing in the credential? We are coordinating with Netelip to update the SIP URI target on their side and request the PCAP + IP whitelist confirmation. We will email those as soon as we have them. Thanks, Jorge Macías

Hi, I don't see any screenshot attached to your message. Could you please check the attachment and resend it? Regarding your question, fallback behavior does not occur automatically from our side unless it has been explicitly configured in your setup. For the required configuration details and setup instructions, please refer to the documentation and verify that your configuration matches the recommended settings: https://docs.vapi.ai/advanced/sip/sip-trunk Thanks, Vapi Support Team