Sorry for responding so late, could i please get help with this because we want to release the agent but this is the last issue we have, I have also contacted Vapi on email and this was their answer ", Thanks for the detailed call IDs and configuration. Finding: The issue is not a NAT/connectivity failure. Our logs confirm bidirectional RTP packet flow is working - we received over 2,000 RTP packets from Zadarma on the first call. The root cause is delayed audio packet arrival from Zadarma's network. Specifically: Call 019e640b (high latency at ~50s): We logged a 9.4-second delay between when our system detected you stopped speaking and when the full audio arrived for transcription. This matches exactly your report of the agent not hearing you for 15+ seconds at the ~50-second mark. Call 019e649f (agent hears nothing): RTP packets arrived but contained no transcribable speech, which triggered our 30-second silence timeout. Why this happens: Your Zadarma gateway uses UDP-only transport. Over the public internet, UDP has no packet ordering or delivery guarantees. During silence periods, NAT bindings can time out, causing RTP packets to arrive late or in bursts when speech resumes. Recommended next steps: Ask Zadarma to enable TCP or TLS transport (port 5061) - this is the most reliable fix, as TCP handles packet ordering and retransmission automatically Ask Zadarma to review their RTP relay buffering - share these call IDs and the timing evidence above with their support team If the issue persists, consider testing with an alternative SIP trunk provider that supports TCP/TLS (e.g., Twilio, Telnyx) to confirm whether the issue is Zadarma-specific" we have contacted zadarma and they told us to use their Zadarma app to change the protocol, but no luck whatsoever

looking forward to hearing from you!

Changing the protocol in the Zadarma app controls the SIP signaling side, but the audio issue is on the RTP media path, which is separate. Here are a few things to try right now: 1. Increase your silence timeout Your assistant may be hanging up before delayed audio arrives. Add this to your assistant config:

json
{
  "silenceTimeoutSeconds": 60
}

2. Change the protocol on the Vapi side In your SIP trunk credential settings in Vapi, set

outboundProtocol

to

"tcp"

. This is different from what the Zadarma app controls, this changes how Vapi communicates with Zadarma's gateway:

json
{
  "gateways": [{
    "ip": "pbx.zadarma.com",
    "port": 5060,
    "outboundProtocol": "tcp"
  }]

3. Enable SIP OPTIONS ping This helps keep NAT bindings alive between packets. Enable

optionsPingEnabled: true

on your gateway config in Vapi.

If the issue persists after all three, the most reliable path would be to test with a different SIP provider (Twilio or Telnyx both support TCP/TLS natively) to confirm whether this is Zadarma-specific. That would also help you unblock your launch while we continue investigating.

Let us know how these changes go.

Hi Aliin, Quick follow-up. The call ID you shared (

019e8d96

) is linked to a phone number that's since been deleted from your account, which limits what we can investigate.

Could you make a new test call using your current phone number setup (

fca42445-5f57-4465-a697-3f278dc1bac9

/ Zadarma Moldova TCP) and share that call ID with us?

Also, to get to the bottom of this, we'd need to see the RTP packet flow from Zadarma's side. Could you ask Zadarma to capture an RTP packet trace (pcap) during one of these Also, to get to the bottom of this, we'd need to see the RTP packet flow from Zadarma's side. Could you ask Zadarma to capture an RTP packet trace (pcap) during one of these problematic calls? That will show us exactly where the audio packets are being delayed or dropped between their servers and ours.

To move forward on diagnosing this, we really do need Zadarma to provide that pcap. We understand they've been unresponsive, but this is the only way to get visibility into what's happening on the RTP media path.

When requesting from Zadarma, you can share these details to help them locate the traffic:

- Vapi SBC IPs:

44.229.228.186

and

44.238.177.138

- RTP port range: UDP 40000-60000 - Call times and the specific timestamps where audio drops

Zadarma support asked us to ensure VoIP has correct functionality by opening access to their IP subnets. We do not manage any firewall on our end as we use VAPI as a cloud platform. We received the following network details from Zadarma support. Please confirm if these IP ranges and ports are already allowed on your end, or if any firewall rules need to be updated: Zadarma IP subnets: - 185.45.152.0/24 - 185.45.154.0/24 - 185.45.155.0/24 - 195.122.19.0/27 - 103.109.103.64/28 - 91.203.21.0/27 - 31.31.222.192/27 Ports: - Signaling: UDP 5060 or TCP 5065 - RTP media: UDP 10000-50000 Can you please confirm these are whitelisted on VAPI's side? This may be the root cause of the delayed RTP packets

Could you push back on Zadarma and specifically ask their technical team (not just support) to capture a packet trace during one of the problematic calls? You can share these details with them to make it easier: • Vapi SBC IPs: 44.229.228.186 and 44.238.177.138 • RTP port range: UDP 40000–60000 • The exact timestamps where audio drops (e.g. Romania call 1:29–1:38, Moldova call 0:00–0:06)

This will allow us to see exactly where the packets are being delayed or lost, and is the fastest path to getting this resolved for your launch. Let us know how it goes!