VoIP.infoThe independent guide to business communications.
VoIP.info Provider research

Crazytel SIP Trunking: authentication, media and service-boundary evidence

Evaluate Crazytel Business SIP Trunking without merging registration, IP authentication, standard, Hybrid or CrazyPBX behavior, and keep portal, network, call and media evidence separate.

Reviewed 2026-10-26Crazytel Business SIP Trunking product and support records were reviewed October 26, 2026. Register-based, IP-authenticated, standard, Hybrid, CrazyPBX and call-centre services retain different authentication, transport, encryption, routing and commercial boundaries; the selected portal configuration and current order govern. No Crazytel account, trunk, credential, public IP, DID, caller ID, PBX, device, PoP, route, codec negotiation, packet, call, audio, failover, emergency outcome, price, availability, compatibility, status incident or support response was inspected or testedAdvancedDocumentation based · not lab tested

Name the Crazytel product and authentication mode

Crazytel publishes Business SIP Trunking alongside distinct Hybrid SIP Trunking, CrazyPBX and call-centre offers. Its current registration guide says a standard trunk can be register-based or IP-authentication-based. Record the exact product, portal trunk ID, enabled state, authentication mode, SIP address and change time before reusing a profile.

A register-based trunk uses username, password and registrar details. An IP-authenticated trunk instead binds trust to a configured public IP. Registration evidence should not be expected from an IP-auth trunk, while a successful registration does not prove inbound routing, caller identity, media or commercial entitlement.

Documented service facts

Reviewed 2026-10-26. Compare SIP trunk services →

SIP authentication

Documented

Standard Business SIP Trunking supports register-based credentials or direct IP authentication selected in the portal. Record the current mode; do not configure both by assumption.

SIP registration

Documented

Register-based trunks use username, password and SIP domain. Live Registrations and Registration Logs expose current observations; an IP-auth trunk is not expected to register.

Inbound delivery and identity

Documented

The product page describes inbound numbers, porting, caller-ID controls and delivery by registration or direct IP. Ownership, port completion, assignment, provider attempt, PBX receipt and completed call remain separate.

Continuity options

Documented

The product page describes Divert on Down and the network page describes geographic redundancy. Configured destination, trigger, selected alternate, completed call and restoration remain unverified.

Network and serviceability

Not verified

Crazytel publishes regional PoPs and proxy hostnames. Account eligibility, resolver answer, selected node, path, latency, incident state, availability and lead time require dated evidence.

Codecs, RTP and audio

Documented

The no-sound guide recommends G.711a and lists other allowed codecs. Offer and answer, packetization, RTP tuples, packet direction, decoding and audibility remain unverified.

Fax

Not verified

The reviewed standard SIP-trunk records do not establish one universal fax mode, gateway, T.38 policy, fallback behavior or completed-page result. Confirm the selected product and current support guidance.

Transport and media protection

Documented

The product page lists UDP, TCP and TLS. The current encryption guide says standard trunks do not support SRTP, while Hybrid and CrazyPBX do. Signaling transport and negotiated media protection remain separate.

Channels and call load

Documented

The product page publishes plan-specific channel language. Current order, product restrictions, PBX resources, live counters and completed simultaneous calls remain separate.

Emergency routing

Documented

The current 000 guide describes priority handling but also depends on working power and internet. Effective address, presented identity, callback and approved readiness evidence remain unverified.

Pricing and contract

Not verified

The product page contains date-sensitive Australian plan, tax, channel and usage terms. The current Critical Information Summary, order, balance, inclusions, restrictions and fees govern.

Portal, logs and status

Documented

The portal documentation describes Live Registrations and Registration Logs, while the status page is a live service-wide view. Neither proves one account, PBX, call or support outcome.

SMS and MMS

Not verified

The registration guide exposes an optional SMS sender setting, but the reviewed trunk records do not establish entitlement, sender approval, API, throughput, webhook security, retention or price.

Keep registration, NAT and reachability distinct

The updated registration guide exposes Live Registrations and registration logs with device, node, expiry, source IP, NAT, socket, contact and success or failure evidence. These records can establish a registration observation but not a completed call. Never publish the SIP password or QR code in a support note.

Crazytel recommends NAT Helper, a 180-second registration period and device keepalive for CGNAT, with shorter intervals for some limited devices. Those settings are mitigations, not proof of a stable public address, symmetric reachability or correct media forwarding.

Do not merge standard and Hybrid encryption claims

Crazytel’s October 26 encryption guide says Hybrid SIP trunks and CrazyPBX support SRTP, while standard SIP trunks do not. It names TLS on port 5061 and SRTP for Hybrid and separately describes encrypted WebRTC.

The Business SIP Trunking page also advertises UDP, TCP and TLS. Treat signaling transport and media protection as different facts: TLS availability on a standard trunk does not imply SRTP, and a configured encryption setting does not prove the negotiated call was protected.

Preserve server, DNS, proxy and selected PoP evidence

Use the SIP address from the portal in the server or registrar field. Crazytel’s proxy guide says any location-specific proxy belongs only in the outbound-proxy field and lists regional hostnames; it warns that centralised ISP DNS can affect nearest-PoP selection.

The network page describes cores, edges and automatic failover, while the status page is a current service-wide snapshot. Neither establishes the resolver result, selected node, latency, route, failover event or health of one account and call.

Separate number, caller ID, channel and media outcomes

The product page documents inbound numbers, caller-ID controls, registration or direct-IP delivery and plan-specific channel descriptions. Keep number ownership, port completion, trunk assignment, provider attempt, PBX receipt, outbound identity acceptance, channel counters and completed calls as separate states.

Crazytel recommends G.711a and lists other allowed codecs in its no-sound guide. That is configuration guidance rather than observed negotiation. Preserve offer and answer, packetization, RTP tuples, packet direction, decoding and audible media for the same call.

Treat failover, emergency calling and price as live policy

Crazytel markets Divert on Down and network redundancy. Record the configured destination, trigger, provider decision, completed alternate call and return to primary separately; a status page or product label is not a failover test.

The October 16 emergency guide describes priority 000 handling but also depends on working power and internet. Confirm current address, presented identity, callback and alternate method through Crazytel’s approved process; never place an uncoordinated emergency call. Plan names, prices, channel limits, taxes and usage restrictions are date-sensitive—confirm the current Critical Information Summary and order before purchase.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Hub · Provider records reviewed individually on their listed dates; account-specific terms and availability require direct confirmation

SIP trunk provider research

Compare the connection model, call routing, media support and cost structure of documented SIP trunk services.

Explore topic →
Troubleshooting · Crazytel Business SIP Trunking product and support records were reviewed October 26, 2026. Register-based, IP-authenticated, standard, Hybrid, CrazyPBX and call-centre services retain different authentication, transport, encryption, routing and commercial boundaries; the selected portal configuration and current order govern. No Crazytel account, trunk, credential, public IP, DID, caller ID, PBX, device, PoP, route, codec negotiation, packet, call, audio, failover, emergency outcome, price, availability, compatibility, status incident or support response was inspected or tested

Crazytel SIP trunk is down or calls fail

Find the first divergence across product, authentication, registration, public IP, DNS, proxy, PoP, DID, caller ID, channel, signaling, media, failover and emergency boundaries.

Read guide →
Guide

SIP trunking: numbers, capacity and operational control

Plan the carrier relationship that connects a self-managed PBX to outside calling.

Read guide →
Guide

SIP trunk channels and simultaneous calls

Size external capacity around busy-hour demand and the provider’s counting rules.

Read guide →
Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Guide

SIP trunk IP authentication

Understand source-address trust and the consequences of a WAN address change.

Read guide →
Protocol reference · RFC 3261 SIP, RFC 3711 SRTP, RFC 4568 SDP Security Descriptions, RFCs 5763 and 5764 DTLS-SRTP, and current Asterisk PJSIP documentation reviewed October 6, 2026; deployed endpoints, intermediaries, certificates and calls require direct verification

SIP TLS and SRTP: what each protects

Distinguish adjacent-hop signaling protection, SRTP media protection, SDES and DTLS-SRTP keying, and the actual termination points on every call leg.

Read guide →
Guide

DNS for SIP phones and trunks

Understand why a working IP connection can still fail to locate the intended calling service.

Read guide →
Guide

Firewall rules for VoIP

Define management, signaling and media access separately using actual deployment requirements.

Read guide →
Guide

NAT for VoIP: signaling and media addresses

Map each translation boundary and compare advertised destinations with reachable addresses.

Read guide →
Guide

PBX credentials and extension secrets

Keep administrator, handset, trunk and backup identities separate and retire them deliberately.

Read guide →
Guide

Planning emergency calling for a VoIP deployment

Assign responsibility for location, routing and outage procedures before rollout.

Read guide →
Guide

Business number porting: a cutover checklist

Keep ownership records, dependencies and a fallback plan aligned with the gaining provider’s process.

Read guide →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →
Guide · FreePBX 17 and current Asterisk res_pjsip documentation reviewed October 5, 2026; Sangoma's generic module pages are responsibility guides rather than an exact installed field map; no FreePBX host, module, account, credential, trunk, route, registration, number, identity, call, media path, failover, capacity, emergency workflow or compatibility was tested

Configure and verify a FreePBX 17 PJSIP trunk

Translate current carrier requirements into FreePBX-owned PJSIP trunk, route and identity controls, then verify the generated Asterisk objects and each call direction independently.

Read guide →
Guide · Current Asterisk PJSIP object, outbound-registration, configuration-example and res_pjsip references reviewed October 1, 2026; no account, carrier, PBX, endpoint, registration, identifier, route, call, emergency workflow, media stream, capacity or failover path was tested

Plan and configure an Asterisk SIP trunk

Translate each carrier direction into explicit PJSIP objects, identification, restricted dialplan, retry policy and leg-by-leg acceptance evidence.

Read guide →
Troubleshooting · Current SIPTRUNK IP-authentication, registration, status, inbound-call, failover, interconnection and general-configuration documentation reviewed October 14, 2026; the sources describe mutually exclusive credential-registration and static-public-IP modes but do not prove the selected account mode, public address, gateway resolution, Contact, registration, number assignment, route, failover treatment, capacity, compatibility or completed call, and no account, portal, credential, PBX, firewall, DNS answer, packet, registration, number, route, failover event, media stream or live call was inspected or tested

SIPTRUNK registration or IP-authentication mode does not match the call path

Determine whether the trunk uses credential registration or static-IP authentication, then trace the exact public address, gateway, Contact or stored destination, provider state, inbound route and failover treatment.

Read guide →
Troubleshooting · First-party Asterisk documentation and SIP standard reviewed September 30, 2026; FreePBX 17 terminology retained; no PBX, provider, number, route or live call test

Inbound VoIP calls do not reach the business

Trace carrier delivery, Asterisk endpoint identification, DID matching and the final destination without collapsing the boundaries.

Read guide →
Troubleshooting · Asterisk 22 LTS · FreePBX 17 / Debian 12 checks

One-way VoIP audio

Trace the missing direction from advertised media address to receiving endpoint.

Read guide →
Troubleshooting · Asterisk 22 LTS · FreePBX 17 / Debian 12 checks

VoIP call connects but has no audio

Separate endpoint audio selection from a media path that fails in both directions.

Read guide →
Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →