BYO SIP Trunk, error 401 Unauthorized
# support
z
Hi, I can't find out why i get a 401 Unauthorized. How can you help me to resolve and allow inbound calls ?
v
Hi there! 👋 I'd be happy to help you troubleshoot that 401 Unauthorized error with your BYO SIP Trunk. I don't have specific details about your particular setup, but I can definitely provide some general troubleshooting guidance for this common issue. Based on the information I have, a 401 Unauthorized error typically indicates an authentication problem with your SIP trunk. Here are some key troubleshooting steps: ## Understanding the Error A 401 Unauthorized error means that the initial request was missing valid authentication credentials. Vapi expects proper authentication for SIP connections, where the username must be your SIP username, and the password can be anything except the keyword "test" [according to documentation](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1334238882660618250). ## Troubleshooting Steps ### 1. Check Your SIP URI Format Make sure your SIP URI is correctly formatted. If you're seeing "invalid credentials," it could mean the SIP address wasn't set up correctly. Use the SIP-URI username instead of arbitrary ones. For example, if your SIP URI is sip:1111212@sip.vapi.ai, use 1111212 as the username [as mentioned in the documentation](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1329143416386355270). ### 2. Verify Authentication Credentials Double-check that the credentials provided to Vapi are correct if your SIP endpoint requires authentication. You can pass credentials by setting the
outboundAuthenticationPlan
while setting up the credentials [according to this source](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1338421915483897856). ### 3. Check Network Configuration
Verify that your network allows traffic on the SIP protocol and that any firewalls or NATs are configured to allow SIP messages to pass through [as recommended in the documentation](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1336713212233515089). ### 4. Ensure Proper Addressing You must send inbound requests to sip.vapi.ai and not directly to IP addresses. All requests and traffic to IP addresses have been blocked [according to this information](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1329037681908383794). ### 5. SIP Server Configuration Make sure your SIP server or PBX is configured to accept calls from Vapi's servers and that it is not rejecting the incoming INVITE requests [as noted in the documentation](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1336713212233515089). ## Example Configuration Here's an example of how to create a BYO SIP Trunk credential using the Vapi API:
Copy code
curl
curl -X POST https://api.vapi.ai/credential \
        -H "Authorization: Bearer YOUR_API_KEY" \
        -H "Content-Type: application/json" \
        -d '{
          "provider": "byo-sip-trunk",
          "name": "My SIP Trunk",
          "gateways": [
            {
              "ip": "your.sip.provider.ip", 
              "port": 5060,
              "inboundEnabled": true,
              "outboundEnabled": true
            }
          ],
          "outboundAuthenticationPlan": {
            "authUsername": "your_outbound_username",
            "authPassword": "your_outbound_password",
            "sipRegisterPlan": {
              "realm": "your.sip.provider.domain",
              "username": "your_register_username",
              "domain": "your.sip.provider.domain",
              "publicIpInContactEnabled": false
            }
          }
        }'
[Source](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1341469652366266408)
z
where can i get full api documentation for credential ?
n
@Zaji A 401 error from the provider can mean various things. What carrier are you trying to connect to ?
z
Mine 🙂
We are ISP
And we try to connect a Cisco CUBE from a customer
Apr 2 13:19:22.922: //3726806/1426EB00000A/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:"PHONE NUMBER CONFIGURED IN VAPI"@sip.vapi.ai:5060 SIP/2.0 Via: SIP/2.0/UDP "PUBLIC IP OF CUBE":5060;branch=z9hG4bK484087963 Remote-Party-ID: ;party=calling;screen=yes;privacy=off From: ;tag=5A4C39CA-1DEF To: Date: Wed, 02 Apr 2025 13:19:22 GMT Call-ID: EB342942-EFB11F0-86BDD976-EDB27C54@"PUBLIC IP OF CUBE" Supported: 100rel,timer,resource-priority,replaces Min-SE: 1800 Cisco-Guid: 0338094848-0000065536-0000696716-0051843244 User-Agent: Cisco-SIPGateway/IOS-17.12.4 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1743599962 Contact: Expires: 180 Allow-Events: telephone-event Max-Forwards: 67 Session-ID: e355f5f1d5d357019305536a1903bb97;remote=00000000000000000000000000000000 Session-Expires: 86400 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 250
--------------------------------------------------------- This is the SIP Invite and this is what i get in response from VAPI :
Apr 2 13:19:23.077: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP "PUBLIC IP OF CUBE":5060;branch=z9hG4bK484087963;rport=63097 From: ;tag=5A4C39CA-1DEF To: ;tag=3N6XcK3HFvUKm Call-ID: EB342942-EFB11F0-86BDD976-EDB27C54@"PUBLIC IP OF CUBE" CSeq: 101 INVITE Timestamp: 1743599959 0.000114 WWW-Authenticate: Digest realm="sip.vapi.ai", algorithm=MD5, qop="auth", nonce="174359995951500" Content-Length: 0
k
Hey Zaji, for inbound calls, VAPI requires an authorization header. You need to pass the username and password here. The username has to be your SIP username, and the password can be anything except empty whitespace.
s
Thanks @Nir S (CEO/Founder @Cloudonix) for helping @Zaji
z
I got the same behavior when i try with an ASTERISK server
n
@Zaji did you manage to solve your issue?
z
now on ASTERISK i get the 401, challenge response but after i get 403 Forbidden. Nowhere inside the VAPI Documentation i find out exact information about what do you need to be inside the SIP Header to authenticate inbound call.
So the answer is no....
n
Has nothing to do with SIP headers. Are you dialing into VAPI or out of VAPI?
z
into
when i use the phone number to dial out of VAPI it works
but not when i try to call a number that i route into VAPI
n
Ok
What version of Asterisk are u using?
z
22
n
Walking on the cutting edge i see. How did you configure your SIP trunk ?
[ { "id": "b476d2db-b419-49f5-8525-a194c5043188", "orgId": "046c0d8d-d297-41af-bf1b-e93f360040aa", "provider": "byo-sip-trunk", "createdAt": "2025-04-04T12:06:30.080Z", "updatedAt": "2025-04-04T12:38:32.502Z", "gateways": [ { "ip": "185.55.146.11" } ], "name": "0368336693", "outboundAuthenticationPlan": { "authUsername": "0368336693", "sipRegisterPlan": { "domain": "asterisk", "username": "0368336693", "realm": "asterisk", "publicIpInContactEnabled": true } } },
Here is all information about SIP Trunk on ASTERISK and on VAPI + test call log
n
What a mess. Your pjsip config files would greatly help. However, as far as I can recall, VAPI's inbound/outbound configurations are non-symmetrical, while Asterisk expects pjsip endpoints to be symmetrical. Ping me via DM and maybe I can help you. Although, i still think your going the wrong path.
b
Having a similar issue, is there a reason why VAPI requests authorisation on inbound calls? Should it not implicitly trust the IP if it matches the regsitration address? This sort of thing used to be a bug on Asterisk/chansip devices
Just putting this together in my head, it's probably due to VAPI not doing any sort of authentication on the phone numbers. If two customers setup the same phone number you would get an issue with the inbound routing not knowing who to route to. Therefore they do a 401 unauthorized check to match the SIP username. Not a bad work around but this will limit a few customers who utilize carrier platforms that don't allow for custom SIP flows.
s
@Zaji Checking if this is resolved for you?
z
still not resolved
[0368336693] type=endpoint transport=0.0.0.0-udp context=from-internal disallow=all allow=ulaw,alaw,gsm,g726,g722,h264,mpeg4 aors=0368336693 send_connected_line=no rtp_keepalive=0 language=en outbound_auth=0368336693 auth=0368336693 from_domain=185.55.146.11 contact_user=0368336693 user_eq_phone=no t38_udptl=no t38_udptl_ec=none fax_detect=no trust_id_inbound=no t38_udptl_nat=no direct_media=no rtp_symmetric=yes dtmf_mode=auto
any news ?
k
Hey Zaji, we are working on it. Will provide you the details once it is fixed.
n
@Sahil This issue was already resolved via our SBC. Generally speaking, the way @Zaji has things setup requires that VAPI Register to his system - which VAPI doesn't do, nor should it.
s
@Nir S (CEO/Founder @Cloudonix) would love to learn more about it like how fixed it cause there are other people who are facing the same issue.
n
@Sahil Well, here is the issue with SIP trunking in general - it's not a "standard", in general, SIP isn't a standard, it's a collection of RFC documents, that are very open to a business interpretation.
So, when it comes to SIP trunking, it can come in several variants
1. Back-2-Back: two IP numbers that are statically defined as white-listed and allow traffic between them. 2. Domain Based: calls are sent anonymously to a unique hash domain name, serving as a pre-shared secret. 3. Domain Based + Authorization Key: Same as before, only with an added SIP header for authorization. To all of the above, you can add something called a technical prefix, which is prefixed to the destination number - for example, 91919#12127773456. All of the above are based on a non-challenge reponse workflow.
Now, you have the username/password challenge workflows, that can be added to the above - in order to make life more complex.
Now, you can add mandatory
SIP REGISTER
on top of the above username/password challenge, which makes life even more complex.
In order to fully support all of the above use cases, you need a full-blown SBC with B2BUA and B2B capabilities. This is a very expesnive piece of software, which is normally charged according to the number of concurrent calls you have.
Because Cloudonix is a communications platform, we have our own home-grown SBC infrastructure, which we can shape and mold. After several people came to us with a similar issue to @Zaji's, we built a specific SBC controller for that use-case (currently in last stages of integration and testing) - which we will make available on our platform via the UI and our API.
In fact, to make life easier for people integrating VAPI and Cloudonix, we created a CLI tool for that
The tool automates the overall setup of SIP trunks and phone numbers in VAPI and Cloudonix
k
Thank you, Nir. Will go through these documentation and if I got stuck can I message you?
n
sure, have fun
b
I'm still not really understanding how any of this solves the issue aside from pushing us down the route of a third party service? I mean no offense but we have our own SBCs and like Sahil I'm from a carriage service provider (Australia based though). I've spoken to some other carriers here and for the end platform to reverse the registration for the inbound leg of the call is generally unheard of. The only other example which comes to mind is Bandwidth (previously Voxbone) but that is for use with their call termination services product (e.g. you generally have one set of credentials for ALL clients/calls). I will probably end up having my team develop a workaround for this as we have a client who is interested in a POC with Vapi but I think if Vapi want to stay competitive then it might be wise to address this issue and have a more 'standard' way of allowing inbound calls from carrier platforms. Either by making phone numbers unique across the platform, using the pre-shared unique hash (e.g. FQDN, Genesys, 3CX etc do this), or some sort of custom header line (similar to the prefix method mentioned above) any of these would be easier to integrate with rather than a challenge response.
n
In general, I agree with what you said - however, you need to understand that VAPI is not a telecom company, it's an AI company, there product is an AI product. As such, their focus is on the AI product, starting to build a telephony agnostic product, that caters to all cases is de-focusing. I totally get what you said, you can go into source codes like Asterisk, Kamailio and even GnuGK (God forbid), and you'll find my name of various patches. But even I know that focus is critical, specifically for companies that roam between multiple disciplines. That is why their default is Twilio, Telnyx and such.
s
Ben, check DM.
11 Views