Freeze one failed transaction and classify the connection model
Record local and UTC time, account, PBX and installed driver, selected SIP login, intended credential or IP-authorized model, observed public source, portal confirmation state, registration response, number, inbound SIP URI or login, Call-ID, Request-URI, From, P-Asserted-Identity, first response, matched route and media result.
Classify the first divergence: wrong model, disabled login registration after trunk activation, unconfirmed or changed source address, number pointed to the wrong destination, blocked provider source, wrong called identity, unauthorized caller ID, PBX route mismatch or signaling success with missing media.
Prove registration or confirmed-source authorization
For the credential path, confirm the selected login owns the sanitized credentials and correlate REGISTER, Contact and expiry with the current PBX object. For the IP path, compare the actual public egress address with the portal-confirmed address and preserve the 8888 confirmation result if the provider workflow required it.
Do not wait for REGISTER on an IP-authorized trunk: Zadarma says its selected login becomes unavailable for registration. Correct only the intended model and remove unintended duplicate paths through the normal change process.
Trace inbound number ownership into the exact SIP destination
Confirm the number is active and inspect whether it targets another SIP login or the external-server SIP URI. Compare the provider attempt and source with the current published ingress set, then follow the Request-URI and called identity through endpoint identification, context, normalization and the first loaded PBX route.
A working outbound IP trunk does not prove inbound assignment. A reachable SIP URI does not prove the intended number points to it, and an edge allow rule does not prove a provider attempt occurred.
Validate From and P-Asserted-Identity against connected numbers
Preserve the exact outbound INVITE. For IP authorization, compare the From number with the connected-number inventory and E.164 form. If P-Asserted-Identity is present, confirm the account is authorized to use that number and whether the provider selected it over From.
Record the first provider response and resulting presented identity. Do not repair identity rejection with a global rewrite until the unauthorized or malformed header owner is proven.
Apply platform and transport boundaries before changing FreePBX
The reviewed provider page is labeled FreePBX 14. Inventory the running release, generated-configuration owner, loaded PJSIP endpoint, auth, AOR, registration and transport before translating its fields. If TLS or SRTP is intended, inspect certificate validation, negotiated transport and SDP rather than inferring protection from a checkbox.
Do not paste provider example secrets, addresses or disabled-verification settings into production. Preserve the current platform documentation and security owner's policy.
Correct one boundary and retest signaling and media
Correct only the demonstrated credential, registration, confirmed-address, number destination, SIP URI, provider-source rule, identity header or PBX-route mismatch. Retest one authorized non-emergency call and preserve the provider transaction, customer-edge receipt, final PBX destination, answer and packets in both media directions.
An echo-test result is one narrow media observation, not proof of PSTN routing, availability, compatibility, capacity, encryption, fax, pricing, emergency behavior or support outcome. No Zadarma account, call, packet or media stream was inspected or tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Zadarma SIP trunk connection methods ↗
- Zadarma IP-authorized SIP trunk FAQ ↗
- Zadarma FreePBX PJSIP setup ↗
- Zadarma server delivery by SIP URI ↗
- Zadarma Asterisk IP-authorized trunk setup ↗
- Zadarma P-Asserted-Identity caller-ID guidance ↗
- Zadarma echo-test guidance ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.