We're having big time figuring out how to integrate our customer's phone number with vapi. Our customer has a pbx offered by the local operator. - Inbound Call: * Steps Completed to achieve inbound calls: 1. Created through API a sip phone number : sip:navicom-alex@sip.vapi.ai. 2. Attached the phone number to an assistant. 3. In the customer's pbx, we forwarded the call from a specific number to the above sip uri, call gets dropped immediately with busy. * Steps taken to debug: 1. Removed the assistant, and set a serveruri on the account level, to get a webhook that might give us some clues on what's going on, performed the test calls, no webhooks triggered, no call logs recorded in the dashboard. 2.For testing purposes, we forwarded the same phone number to open test sip uris like 3333@sip2sip.info & 4444@sip2sip.info and everything works, which might suggest it's something on vapi's sip uri, that drops the call..

hey @supershift checking if you are able to make progress post our call?

Hey @Shubham Bajaj , Thanks for the call , i have sent the infos to the client's sip provider , now waiting for a reply there.

The server expects plain username and password in the

Authorization

header instead of Base64-encoded

Basic

format, the issue is likely caused by a mismatch between what the client sends and what the server expects. Here’s how to analyze and resolve the problem: ### Analysis 1. What is Sent by You - The client is sending this header:

Authorization: Basic a2FtYWxpbzpuYXZpY29t

-

a2FtYWxpbzpuYXZpY29t

is Base64-encoded, representing

kamalio:navicom

(username:password). 2. What the Server Expects - If the server expects the username and password to be sent in plain text (which is unconventional for

Authorization

headers), the header should look like:

Authorization: kamalio:navicom

3. Mismatch - The server likely tries to decode the Base64 string as plain text, causing a misinterpretation or an internal server error.

Hi @Shubham Bajaj

I use twilio and telenyx, do you want me to do it using them?

So i wrote a script to randomly test the sip ... The vapi's sip uri, expects the Authorization header to include Digest Authorization fields like realm, nonce, and a calculated response, which contradicts the basic or plain password authentication requirement you guys mentioned.. Here is what worked for forwarding the calls to sip uri, Example request with sipexer cli:

./sipexer -invite \
  -ruri "sip:navicom-alex@sip.vapi.ai" \
  -fu "kamalio" \
  -fdomain "sip.vapi.ai" \
  -tu "navicom-alex" \
  -tdomain "sip.vapi.ai" \
  -xh "Authorization: Digest username=\"kamalio\", realm=\"<REALM>\", nonce=\"<NONCE>\", uri=\"sip:navicom-alex@sip.vapi.ai\", response=\"<CALCULATED_RESPONSE>\", algorithm=MD5" \
  udp:sip.vapi.ai:5060