The IP to allowlist
95.216.218.102.Nearly every carrier authorises outbound calls by source IP, so this address has
to be on your trunk’s allowlist before anything will connect. Do this first: a
trunk that is correct in every other respect still fails without it, and the
failure looks like a fault at our end rather than a missing permission.Every trunk returns it as platform_ip, so you can read it from the API rather
than trusting this page to stay current:Where inbound calls should be sent
sip:95.216.218.102:5090.This is the other half of a trunk, and it is separate configuration in a
different part of your carrier’s console from the allowlist above. The allowlist
tells them to accept calls from us; this tells them where to deliver calls
to us. Twilio calls the field the Origination URI; other carriers call it
a termination point, a destination SIP URI, or just the host. It is the same
string.Getting this wrong fails in the quietest way this product has: you buy a number,
point it at an agent, and it simply never rings. Nothing appears in your logs or
ours, because the call never arrives — the carrier had nowhere to deliver it.Every trunk returns it as origination_uri, so read it from the API rather than
trusting this page to stay current:What you need
Any SIP provider will do. From them you need:- a host —
sip.carrier.example - credentials — username and password, if they use registration
- your numbers, and whether inbound calls are delivered to that trunk
- an IP allowlist entry for
95.216.218.102, or a credential list if you would rather authenticate with a username and password
Connecting it
transport is udp, tcp or tls.
Registering a number
A number must belong to a trunk before it can place a call:inbound_agent_id and calls to that number are answered
automatically by that agent.
Carrier-side setup
Your carrier needs to know where to send traffic, and — more often the cause of a silent failure — needs to agree that you are allowed to place the call at all. Work through all of these before blaming the API:Allowlist the Wixzel Phone IP
username and password. If the IP is not on your carrier’s allowlist,
your INVITE is rejected before it is ever rated, and nothing appears on
your bill to hint at why.Calls originate from 95.216.218.102. Add that to whatever your carrier
calls its IP access control list, and see the carrier notes below for where
that setting lives on the common providers.Verify the caller ID
from_number_id has to be one your carrier has authorised you
to present. Carriers routinely accept the call, log it, then drop it when the
presented caller ID is not provisioned on the account.Complete KYC and any destination registration
Check the balance and the destination is enabled
Twilio
Twilio authorises outbound calls by source IP, and rejects anything else instantly.Open the trunk's termination settings
Add the platform IP to an IP Access Control List
95.216.218.102. A Credential List
works instead, if you would rather authenticate with a username and
password — put those on the trunk’s username and password fields and
Wixzel Phone will use them in place of IP auth.Check the Termination SIP URI matches the trunk host
host on your Wixzel trunk must be the same
your-domain.pstn.twilio.com shown in the console.Confirm the caller ID is a number on that account
from_number_id it does not own.Set the Origination URI, for inbound
sip:95.216.218.102:5090 — or whatever
GET /v1/sip-trunks reports as origination_uri.Outbound works without this; inbound does not, and does not complain. Attach
your numbers to the trunk in the same console, then give the number an
inbound_agent_id here so there is an agent to answer them.Wholesale carriers
Most non-Twilio carriers also authorise by IP, and additionally care about number formatting and account verification. If calls are accepted and then dropped rather than rejected outright, work through the troubleshooting below — particularlysend_plus and the KYC step above.
Trunk changes take effect immediately: creating, updating or deleting a trunk
rewrites the telephony configuration and reloads it, so there is nothing to
restart.
When a call does not connect
A call that is accepted by the API and then fails looks like this:POST /v1/calls returns 202 with status: "queued", and a later GET /v1/calls
shows status: "failed", a short duration_seconds, and cost_micros: null.
cost_micros: null is the important part. You are not charged for a call that
never connected — no answer means no billable seconds, and the credit reserved
at admission is released. A failed call costs you nothing, which also means the
absence of a charge is not evidence of a problem on our side.
Work down this list in order.
1. Read your carrier's own call logs first
1. Read your carrier's own call logs first
- The call is not listed. It never reached your carrier. The IP allowlist, the trunk host or the firewall is wrong.
- Listed, answered, with a duration and a cost. The call worked at the telephony layer. If the caller heard nothing, the problem is media, not signalling — see the audio note below.
- Listed, zero answered, zero cost, a short duration. The carrier
accepted your
INVITEand then cleared the call. This is a carrier-side permission problem far more often than a configuration one: caller ID not provisioned, KYC incomplete, or the destination not enabled. Nothing on the Wixzel Phone side can fix it, and the fastest route is your carrier’s support with the timestamp and the call id from their log.
2. Check the number is actually on a trunk
2. Check the number is actually on a trunk
400 number_not_on_trunk means the number has no sip_trunk_id. Calls are
placed over your trunk, so a number that is not on one has nowhere to go.3. 408 Request Timeout: try send_plus: false
3. 408 Request Timeout: try send_plus: false
100 Trying and then 408 Request Timeout a few
seconds later, they could not route the destination. The most common reason
is the leading +.Wixzel Phone dials sip:+15551234567@your-carrier by default, which is what
Twilio and Telnyx expect. Many wholesale carriers cannot parse a + in the
request URI: they accept the INVITE, fail to route it, and time out. The call
shows in their portal as received and never answered, which looks like a
fault at your end.Send bare digits instead:dial_prefix implies this: a tech prefix is matched literally, so
the + is always dropped when one is configured.4. 403 Forbidden: check the caller ID
4. 403 Forbidden: check the caller ID
403 is a permission decision, usually about who you claim to be rather
than who you are dialling. Check that the number behind from_number_id is
one your carrier has authorised you to present.Carriers commonly reject a call with no caller ID at all. If you are testing
from a softphone or an Asterisk CLI rather than through the API, confirm you
are actually sending one — an INVITE with From: "Anonymous" earns a 403
from most carriers regardless of how well the account is configured.5. Rejected in about a second: the IP is not allowlisted
5. Rejected in about a second: the IP is not allowlisted
95.216.218.102 to it.The distinguishing feature is the timing. An unauthorised source is rejected
immediately, because the carrier does not need to look anything up to decide.
A call that is accepted and then fails several seconds later is a different
problem — routing, formatting or account permissions — and the entries above
cover those.This is worth checking first whenever the same trunk works from another
server. Identical trunk settings do not carry the allowlist with them.6. Interpret the hangup cause
6. Interpret the hangup cause
Normal Clearing (Q.850 cause 16) on a call that was never answered is not
as reassuring as it sounds. It means the far end ended the call deliberately
rather than erroring — a rejection can be dressed as a normal hangup. Read it
as “something upstream chose to end this”, not as “the call completed”.A duration of a few seconds with no answer is usually the carrier clearing
the call, not a person declining it. A human declining a call typically takes
longer than the ring itself.7. An inbound number never rings at all
7. An inbound number never rings at all
sip:95.216.218.102:5090 (or whatever
GET /v1/sip-trunks reports as origination_uri) as the destination for
that number, that the number is attached to the trunk on their side, and
that it has an inbound_agent_id here so something answers it.8. Connected, but no audio
8. Connected, but no audio

