VoIP.infoThe independent guide to business communications.
VoIP.info Troubleshooting

ClearlyIP trunk registers but DID routing or failover is wrong

Trace the number owner, Location or Smart Routing mode, delivered identity, generated FreePBX route and effective failover rule without treating registration as end-to-end proof.

Reviewed 2026-10-18The current ClearlyIP product page and first-party configuration references were reviewed October 18, 2026. The legacy knowledge base now expressly says that it is no longer updated and directs readers to kb.14ip.com; its registration, Location, number-routing, failover and FreePBX-module details are therefore retained only as historical workflow evidence that must be confirmed against the replacement documentation, current portal, installed module and running PBX. The batch separates product availability from documentation currency, number ownership from Smart Routing, Location and SubLocation registration from inbound route matching, generated FreePBX objects from loaded state, and failover configuration from an observed provider attempt. No ClearlyIP account, Location, SubLocation, number, credential, keycode, module, PBX, registration, DNS answer, route, failover event, packet, media stream, price, availability, compatibility, capacity or live call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one failed inbound attempt and the source versions

Record the called number, timestamp and timezone, current product page, replacement-documentation destination, legacy page used, portal Location, number routing mode, PBX registration, provider attempt, edge receipt, PBX response, route result and audio. Preserve a working outbound call or Registered label only as a bounded control.

Redact credentials, keycodes, telephone numbers, addresses and call content. The legacy knowledge-base notice means remembered screenshots or module filenames must not be assumed current.

Prove which Location or SubLocation owns the number

Confirm the number's Primary Location, any selected SubLocation and whether routing is Primary, Smart Routing linear or random. Preserve the actual ordered destinations. Then record whether the inbound identity is delivered as ten digits, eleven digits or the trunk username.

A valid REGISTER from one PBX does not prove that the number selects that Location or identity. Correct the provider routing owner before broadening an inbound route.

Correlate registration with the selected provider destination

For every applicable Location or SubLocation, preserve the configured regional registrar or SRV name, DNS answers, selected server, REGISTER exchange, Contact, expiry and portal-observed address. Compare that state with the destination the provider attempted for the failed call.

If Primary and SubLocations are involved, verify the current supported server topology. Do not assume multiple configured servers or an SRV record proves usable regional recovery.

Inspect the generated FreePBX route and its real destination

Compare the delivered source and identity with loaded PJSIP identify rules, context and the first matching inbound route. ClearlyIP's legacy module workflow creates missing routes to a verification destination; confirm that the affected DID now targets the intended queue, ring group, extension or other business owner.

Check generated configuration and loaded Asterisk state before rerunning the module. A visible route, Apply Config action or successful verification announcement is not proof that the production destination answers.

Resolve failover precedence and prove the trigger

Freeze the per-number rule before the Location-level rule because the legacy portal reference gives the number rule precedence. Keep Smart Routing order, immediate diversion and unreachable-triggered failover separate. Then preserve the actual provider attempt, response or timeout and selected DID, SIP URI or Location.

Do not manufacture an outage, reject calls broadly or infer a universal response-code matrix. Test only an authorized condition and distinguish new-call recovery from preservation of an established call.

Correct the earliest mismatch and repeat the same call

Change only the earliest demonstrated fault: stale documentation assumption, number owner, Smart Routing destination, delivered identity form, registration target, Contact, PJSIP identification, context, inbound route destination or failover rule. Repeat the same inbound call, verify answer and two-way audio, and restore normal routing.

No ClearlyIP account, PBX, registration, failover event, packet, media stream or live call was inspected for this diagnostic.

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

Provider research · The current ClearlyIP product page and first-party configuration references were reviewed October 18, 2026. The legacy knowledge base now expressly says that it is no longer updated and directs readers to kb.14ip.com; its registration, Location, number-routing, failover and FreePBX-module details are therefore retained only as historical workflow evidence that must be confirmed against the replacement documentation, current portal, installed module and running PBX. The batch separates product availability from documentation currency, number ownership from Smart Routing, Location and SubLocation registration from inbound route matching, generated FreePBX objects from loaded state, and failover configuration from an observed provider attempt. No ClearlyIP account, Location, SubLocation, number, credential, keycode, module, PBX, registration, DNS answer, route, failover event, packet, media stream, price, availability, compatibility, capacity or live call was inspected or tested

ClearlyIP trunking: number routing, FreePBX objects and failover evidence

Trace one number through its Location or Smart Routing owner, registered PBX, generated FreePBX route and per-number failover while preserving the legacy-documentation boundary.

Read guide →
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 →
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 failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Protocol reference

SIP REGISTER explained

Understand contact bindings, authentication challenges and why registration does not prove calling works.

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 →
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 · FreePBX 17 on Debian 12; route semantics cross-checked against Sangoma PBX GUI 13 guides and current FreePBX Blacklist 17.0.1.2 release/17.0 source on October 11, 2026; exact installed modules, generated or loaded route hooks and calls were not tested

FreePBX inbound and outbound routes

Follow the incoming number and outgoing dial pattern as two separate routing decisions.

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 · FreePBX inbound-route and example documentation plus current Asterisk PJSIP troubleshooting and res_pjsip references reviewed October 5, 2026; exact FreePBX 17 module fields, generated dialplan and provider delivery format require runtime verification

FreePBX inbound route mismatch: trunk identity, DID, CID and destination proof

Trace one inbound call from the accepted trunk through delivered number and caller identity to the selected FreePBX destination.

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 →