ClearlyIP trunking: number routing, FreePBX objects and failover evidence

Start with documentation currency, not a remembered template

ClearlyIP's current product page still describes SIP trunking, self-service management, failover and FreePBX integration. The linked legacy knowledge base now carries an explicit notice that it is no longer updated and points to kb.14ip.com. Treat its screenshots, hostnames, module filenames and field behavior as historical workflow evidence until the current portal, replacement documentation and installed release agree.

Record the page URL and review date beside every configuration claim. A first-party page can remain useful evidence without proving that every value is current, enabled for an account or compatible with a particular FreePBX release.

Map the number owner and routing mode before the PBX

The legacy portal reference distinguishes a Primary Location from SubLocations and says numbers can route to either. It documents default Primary Location routing plus optional Smart Routing with linear or random selection. It also documents three delivered identity forms: ten-digit NPA, eleven-digit E.164 without a plus, or the trunk username.

Preserve the affected number, Primary Location, any SubLocations, selected routing mode, ordered destinations and delivered identity form. A registered PBX can be healthy while the number selects another Location, SubLocation or identity that misses the intended inbound route.

Treat FreePBX automation as generated state requiring review

The legacy module reference says its outbound action creates two trunks and separate domestic and emergency routes. Its inbound action creates missing DID routes to a verification destination that reads back the DID and caller identity; the administrator must then select the intended destination.

Record the installed module and FreePBX versions, keycode owner, generated trunks, route order, inbound DID patterns and current destinations. A route created by automation is not proof that the business destination is selected, loaded or reached, and rerunning automation must not silently replace local route intent.

Keep regional registration and SubLocation topology separate

The legacy trunk-details page lists regional registration servers and UDP SRV names and recommends multiple regions. A separate portal section says a Primary Location and its SubLocations normally need the same server, and documents a different topology when separate servers or SRV are required.

Preserve the configured registrar or SRV name, current DNS answers, chosen target, REGISTER challenge, Contact, expiry and portal-observed address for each PBX. Multiple configured servers, an SRV answer and a Registered label are different evidence; none proves which Location receives one inbound call.

Resolve number-level precedence before testing failover

The legacy portal reference says a per-number failover overrides the Location-level rule. It documents DID, SIP URI or another Location as destinations and distinguishes immediate diversion from an unreachable-PBX trigger. Its Smart Routing controls are another selection layer, not a substitute name for failover.

Freeze the effective rule for the affected number before testing. Preserve the trigger, provider attempt, SIP response or timeout, selected destination, caller identity and media result. The reviewed material does not establish one current universal timer, response-code matrix, retry count, restoration interval or active-call survival result.

Match the delivered request to loaded FreePBX and Asterisk state

The legacy troubleshooting page says inbound calls normally use a ten-digit DID and can be refused when the host or inbound route does not match. Compare the actual source, transport, Request-URI, To and asserted identity with loaded PJSIP endpoint identification, context and the first FreePBX route match.

Inspect generated and loaded state before editing. Do not solve one mismatch with anonymous SIP, a catch-all route or unrestricted source trust. Use the paired diagnostic to correct the earliest demonstrated owner.

Run a bounded acceptance record

For one pilot number, record the documentation versions, portal routing owner, registrations, provider attempt, customer-edge receipt, PBX object, inbound route, answer, SDP and two-way audio. Then test only the authorized failover condition, verify the selected destination and restore normal routing deliberately.

Confirm current number availability, pricing, capacity, emergency obligations, signaling transport, media protection and platform support in the current account or dated order. No ClearlyIP account, module, route, failover event, packet or call was inspected for this guide.

Diagnose a registered trunk with the wrong DID route or failover

Use the ClearlyIP routing diagnostic to join source freshness, number ownership, Location selection, FreePBX route state and failover evidence.