@User Hi, I am looking for help diagnosing what looks like a Vapi-side digest-auth bug on BYOSIP outbound. Setup - Carrier: Fayn.cz - Vapi BYOSIP credential, provider byo-sip-trunk - Gateway: sp.fayn.cz:5060 UDP, inboundEnabled: false, outboundEnabled: true - outboundLeadingPlusEnabled: false (carrier requires E.164 without leading +) - outboundAuthenticationPlan configured with authUsername + authPassword * Symptom* Every outbound call ends with: call.in-progress.error-providerfault-outbound-sip-407-proxy-authentication-required Carrier never receives a usable Proxy-Authorization response. Reproduced across multiple days, multiple destinations (mobile + landline), with and without outboundLeadingPlusEnabled, with and without optionsPingEnabled, after carrier password reset. No change. Troubleshooting I built a raw Python SIP UDP client using the identical username and password that's in the Vapi credential and pointed it at the same gateway. Results: Step 1 — OPTIONS: 200 Alive. Step 2 — REGISTER (round 2 with digest): 200 OK, registered, Contact accepted, expires 3060s. Step 3 — INVITE to invalid destination (round 2 with digest): 100 Trying → 404 Not Found (= auth accepted, routing rejected as expected). Step 4 — INVITE to real destination (round 2 with digest): 100 Trying → 183 Session Progress → 180 Ringing — **phone actually rang**. *407 call IDs: * - 019e21a3-ec60-7ddd-b7f1-4cb4da3e62db - 019e2618-3a39-7000-ad64-4801cbca2285 - 019e31d0-bddc-7000-ab68-97dc1249f773 Do you have any pointers or ideas as to how to solve this or where the problem could be?

This honestly looks more like a Vapi/BYOSIP digest handling issue than a carrier issue, especially since your raw SIP client successfully completes REGISTER and INVITE with the exact same credentials and gateway. I’d probably inspect whether Vapi is failing on nonce reuse, qop handling, realm mismatch, or not generating the second INVITE correctly after the 407 challenge. The fact that the carrier never sees a valid Proxy-Authorization header is the biggest clue. I can help debug the SIP flow deeper if you want comparing the successful Python INVITE transaction against the Vapi-generated one should expose the mismatch pretty quickly. @Scrouty

@Rita Heritage That"d be awesome, what could I provide you to help identify the issue?

What I really need is the full call flow from the failing Vapi attempt, especially the 401 or 407 response and whatever it sends immediately after that. Then, alongside that, the same section from your working Python SIP client so we can line them up. The key thing I’ll be looking for is whether Vapi is correctly rebuilding the authentication response after the challenge or if something in the nonce/realm flow is getting lost or mismatched. That’s usually where this kind of issue hides. If you can drop those two traces, I can point out the exact break in the handshake pretty quickly. @Scrouty

@Rita Heritage There are the python raw trace and flow descriptions of the vapi-fayn flow https://cdn.discordapp.com/attachments/1505869484668223488/1505954193880387604/sip-python-trace.txt?ex=6a0c80a3&is=6a0b2f23&hm=2f1a3e9112c815db6c185df47585dc5eb584966db296cccc3d8af2e7cd7e249a& https://cdn.discordapp.com/attachments/1505869484668223488/1505954194392350820/sip-vapi-failing-trace-description.txt?ex=6a0c80a3&is=6a0b2f23&hm=bfa73ea451f0a02a1d31446fc199b6b830679eef43034c7ca61f5f92eb8d09cf&

@Scrouty I sent a friend request kindly acc

I had tested pure alfanumerical password, did not help.