Choose credential registration or static-IP authorization
Zadarma documents two connection models. The login-and-password path registers equipment using the account's SIP connection data. The IP-authorized trunk instead requires one or more confirmed static public addresses and uses a selected SIP login as the trunk identifier. Preserve the current account, selected login, intended model, credential owner, confirmed addresses and PBX object; do not configure both paths by assumption.
After the IP-authorized trunk is activated, Zadarma says the selected SIP login becomes unavailable for registration and incoming calls. A missing registration state is therefore expected evidence for that model, not automatically a fault.
Documented service facts
Reviewed 2026-10-22. Compare SIP trunk services →
Authentication
DocumentedZadarma documents credential registration and a separate trunk authorized by one or more confirmed static source addresses. Enabling the IP-authorized trunk consumes a selected SIP login as its identifier and makes that login unavailable for registration. Preserve one intended model and its owner.
SIP registration
DocumentedRegistration belongs to the login-and-password path. The IP-authorized trunk instead accepts outbound traffic from confirmed source addresses; its selected login no longer registers or receives inbound calls. Registration, source confirmation, number routing and call completion remain separate evidence.
Inbound delivery
DocumentedInbound numbers can target another registered SIP login or an external-server SIP URI without registration. Preserve number ownership, the selected destination, current provider source addresses, delivered called identity and first loaded PBX route independently.
Inbound failover
Not verifiedZadarma permits several confirmed source IP addresses for outbound authorization, including main and reserve customer links, but that does not document inbound destination order, failure detection, retry rules or established-call survival. The reviewed public pages do not establish a customer-controlled inbound failover policy. Obtain the exact number-route behavior and test every approved fault and restoration path.
Number and regional availability
Not verifiedZadarma markets virtual numbers in 110 countries and number porting in 40 countries. Exact inventory, portability, identity documents, activation time, caller-ID rights and inbound features remain specific to country, number type, account and date. Verify the selected number in the ordering flow and retain the applicable requirements.
Audio codecs
DocumentedZadarma's current FreePBX PJSIP guide instructs users to leave A-law and mu-law enabled, and its Asterisk IP-trunk example likewise permits alaw and ulaw. A configuration example is not proof of negotiation on every destination. Preserve the offer, answer, payloads, DTMF result and any transcoding for each required route.
T.38 fax
Not verifiedThe reviewed trunk and PBX setup pages do not establish T.38 support or route-specific fax behavior. Zadarma separately documents receiving fax in its hosted PBX, which is not evidence that a customer SIP trunk negotiates T.38 or carries in-band fax reliably. Confirm the exact route and qualify approved documents end to end.
Signaling and media encryption
DocumentedZadarma publishes optional TLS and SRTP examples, including a FreePBX 14 page that sets TLS 1.2 but disables client verification. Treat this as version-scoped interconnection evidence, not proof of certificate-authenticated transport or a current security baseline.
Concurrent calls and call starts
Not verifiedZadarma says outbound channel limits depend on the selected plan and publishes current examples for Standard, Office and Corporation plans. Those public figures can change by region and package, and the reviewed pages do not establish inbound concurrency, calls per second or burst controls. Capture the account's active limits before any authorized load test.
Emergency calling
Not verifiedNo trunk-specific emergency-calling activation, validated location, callback, number eligibility or approved test procedure was verified in the reviewed public setup and number pages. Country coverage and a local number do not establish emergency access. Obtain written route and location requirements for every operating site and retain an independent fallback until accepted.
Pricing model
DocumentedZadarma publishes pay-as-you-go and bundled plans, with outgoing rates, included minutes, numbers and channel allowances varying by region and billing term. A displayed plan is not an account quote. Preserve the dated plan, destination rates, billing increment, included-use conditions, number fees, taxes, currency and renewal term.
Administration and support
DocumentedPreserve the selected connection model, confirmed source addresses or credential owner, number-level inbound destination, connected caller-ID inventory, From and P-Asserted-Identity, current provider sources, loaded PBX objects and authorized change history.
SMS
Not verifiedZadarma offers SMS separately, with inbound availability limited to eligible mobile numbers and country-specific conditions. A voice number or SIP trunk does not establish SMS capability, sender approval, consent, API behavior, throughput or fees. Verify the exact number and messaging program independently.
Prove address confirmation before trusting source identity
The IP-authorization workflow accepts outbound calls only from confirmed addresses. Zadarma documents confirming an address by routing a call to 8888 on sip.zadarma.com. Preserve the observed public source, portal address state, confirmation result, outbound destination, caller identity and first provider response.
A saved address, a successful confirmation call and a completed later call are three different observations. Multiple confirmed addresses can represent main and backup customer Internet paths, but they do not publish inbound failover order, restoration or established-call survival.
Route inbound numbers independently through SIP URI or another login
Zadarma states that an IP-authorized trunk's identifying login no longer receives incoming calls. Inbound calls can instead use another SIP login or a number-level external-server SIP URI without registration. Preserve number ownership, the selected inbound destination, exact URI, current provider source list, delivered called identity and first PBX route.
Outbound source authorization does not assign a number or prove inbound reachability. Likewise, a registered spare login does not establish that the intended number points to it.
Keep caller-ID authorization and signaling headers separate
For an IP-authorized trunk, Zadarma documents an international E.164 number in the From header and says an invalid or unconnected value can be replaced by the account default. Separate guidance says P-Asserted-Identity can select a connected number and takes priority when valid. Preserve the exact authorized-number inventory, From, P-Asserted-Identity, privacy state and provider response.
A locally formatted display value is not proof of authorization. Correct only the header owner demonstrated by the provider trace and the current account policy; do not copy example numbers or broad identity rewrites into production.
Translate examples to the installed FreePBX and Asterisk release
The current first-party FreePBX page is labeled for FreePBX 14 and shows PJSIP plus optional TLS and SRTP settings. Its example sets TLS 1.2 while leaving client verification disabled. Treat that as version-scoped provider interconnection evidence, not a current security baseline or proof of authenticated transport.
Inventory the running distribution, generated-configuration owner, loaded PJSIP objects, certificate trust, transport, route and dial normalization before translating the example. Preserve current first-party hosts and source ranges rather than freezing screenshots into permanent policy.
Test signaling, media, limits and commercial terms separately
After signaling succeeds, preserve both SDP bodies, selected codec and DTMF payload, RTP endpoints, NAT translation and packets in each direction. Zadarma's echo test can exercise one account-to-provider audio path, but it is not proof of a particular PSTN destination, inbound route, two-way production media or service quality.
Capacity, number eligibility, pricing, emergency calling, messaging, encryption and support remain account-, location-, route- and date-specific. Obtain the current order and governing terms; no account, call, packet, media stream or emergency result was tested for this guide.
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 ↗
- Zadarma United States number catalogue ↗
- Zadarma hosted-PBX fax FAQ ↗
- Zadarma TLS and SRTP connection guidance ↗
- Zadarma price-plan comparison ↗
- Zadarma API documentation ↗
- Zadarma SMS service ↗
- Zadarma SMS rates and receiving conditions ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.