SIP Trunk Configuration Infobip
# support
m
I am currently facing issues setting up a SIP configuration between Infobip and Vapi.ai. When I place a call, it isn't even answered, and I receive the error UNDELIVERABLE_REJECTED_PLATFORM in the Infobip logs. I believe I have configured everything correctly on the Infobip side: Destination hosts: Added api.vapi.ai and sip.vapi.ai. Source hosts: Added 44.229.228.186/32 and 44.238.177.138/32. Additionally, I completed the setup on Vapi.ai using the BYO (Bring Your Own carrier) method, where I registered my Infobip number. Is there anything I might have missed in this configuration?
c
Hi there, Thank you for your message. Our team is currently out of the office. We operate Monday through Friday, from 9:00 AM to 8:00 PM Pacific Standard Time (PST). We’ll get back to you as soon as possible during our normal business hours. If your message is urgent, please mark it accordingly or include “URGENT” in the subject line, and we’ll do our best to respond promptly. Warm regards, Vapi Customer Support Team
v
It’s important to ensure your Infobip number is properly associated with your SIP trunk credential in Vapi. Try explicitly linking your external number to the SIP trunk using the following API call:
Copy code
bash
curl -X POST "https://api.vapi.ai/phone-number" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_VAPI_PRIVATE_KEY" \
  -d '{
    "provider": "byo-phone-number",
    "name": "Infobip Number",
    "number": "YOUR_INFObip_NUMBER",
    "numberE164CheckEnabled": false,
    "credentialId": "YOUR_CREDENTIAL_ID"
  }'
Double-check that the
credentialId
matches your Infobip SIP trunk credential in Vapi and that the number is in E.164 format if required by your provider. This step is often missed and can cause the call to be rejected at the platform level according to the documentation I have found. Source: - [Vapi SIP Trunk Documentation](https://docs.vapi.ai/advanced/sip/sip-trunk)
t
That Infobip error usually means the call is getting blocked before it ever reaches Vapi, so it’s more of a SIP routing or trust issue than a Vapi agent issue. I’d double-check that Infobip is sending the call to the exact SIP URI Vapi expects (domain, port, and transport all matter) and that the From/To headers match the number you registered with BYO. Also make sure Infobip’s outbound SBC IPs are fully allowed and that both sides are using the same transport (UDP/TCP/TLS). A small mismatch there can cause this exact behavior. Are you routing the call via a SIP trunk or a direct SIP URI, and which transport are you using? @Matheus M M
c
Hi Matheus M M, Check these items (concise checklist): - Confirm exact target SIP URI Infobip sends: it must be credential-specific domain returned by Vapi (e.g., YOUR_CREDENTIAL_ID.sip.vapi.ai) including transport and port. Mistmatch → immediate rejection. See SIP trunk docs: https://docs.vapi.ai/advanced/sip/sip-trunk - Ensure Infobip uses the same transport (UDP/TCP/TLS) and port as the Vapi gateway entry. Transport mismatch often causes UNDELIVERABLE_REJECTED_PLATFORM. - Verify From/To headers match the phone number you attached to the Vapi credential (and any provider-required P-Preferred-Identity). Some providers reject if these differ. - Confirm you have explicitly associated the Infobip number with the Vapi credential (phone-number resource). Use the API call you included and ensure credentialId equals the Vapi credential for Infobip. - Example reference: https://docs.vapi.ai/advanced/sip/sip-trunk - Double-check Infobip is sending calls from the exact SBC IPs you added; some providers use multiple outbound IPs — whitelist all outbound SBC IPs Infobip uses. - If you require IP auth on the Vapi credential, ensure the gateway is configured with inboundEnabled and expects IP-based auth; otherwise use SIP Authorization headers. - Inspect Infobip call logs for SIP response codes and any reason phrase (e.g., 401/403) and share the INVITE (redact sensitive headers) plus the Vapi credentialId and a sample phone-call ID — that lets us pinpoint whether calls reach Vapi or are blocked before. If you want, share: - The exact SIP Request-URI Infobip is using - Transport/port - Whether Infobip sends Authorization headers - credentialId you used when creating the Vapi credential We'll review next steps after that.
t
Ok