Callcentric SIP trunking: registration, DID Forward and treatment precedence

Inventory the outgoing, incoming and extension products separately

Callcentric separates the outgoing calling plan, incoming DID or DDI product and SIP extension identity. Its registration FAQ identifies the assigned 1777 number as username and authorization ID and sip.callcentric.net as proxy, realm and registrar. Record the exact extension, current Contact, outgoing plan, incoming number and owner of each route.

A successful REGISTER proves one binding for one extension; it does not establish the destination or treatment of a particular DID. Likewise, an active incoming number does not by itself include or prove the intended outgoing plan for a forwarded leg.

Read DID Forward before evaluating any Call Treatment

Callcentric describes DID Forward as a simplified rule that sends one incoming number to a PSTN number, another Callcentric account, SIP URI or IP address, or fax reception. Both the feature page and FAQ explicitly say that this direct DID Forward has higher priority than Call Treatments.

Export the DID Forward state, type and target before inspecting a network-down rule, schedule, hunt or PBX route. An active direct forward can bypass the Call Treatment layer entirely, so a correct lower-priority network-down rule may never be eligible.

Treat Network Down Forward as a bounded Call Treatment

The Network Down Forward page directs the operator to use Call Treatments to send incoming calls to another number when the Internet connection is down. Preserve the selected incoming number or scope, rule order, enabled state, destination and the exact provider-side condition observed during an authorized test.

The reviewed public pages do not define one universal registration threshold, SIP-response set, timeout, retry count or restoration interval for that condition. Do not substitute a single PBX OPTIONS result, a customer-interface outage or another carrier’s trigger policy for Callcentric’s observed decision.

Separate provider advancement from PBX and media evidence

For a normal call, retain the provider attempt, delivered request, customer-edge receipt, selected PBX object and route, answer, SDP and two-way RTP. For a forwarded call, retain the original incoming leg, selected Callcentric rule, new outgoing destination, answer, caller treatment and media on that separate leg.

A portal rule, registration state, provider call row or completed outbound leg does not prove that the intended PBX received the original INVITE or that intelligible audio flowed in both directions. Preserve identifiers and timestamps across each leg rather than collapsing them into one call.

Model forwarding cost and capacity by leg

Callcentric states that each forwarded call has an incoming and an outgoing leg. The incoming leg follows the selected incoming service; the forwarded leg uses included minutes or per-minute rates according to the outgoing plan. Record both products, destination, charge basis and simultaneous-call controls from the actual account before cutover.

Do not infer price, availability, included minutes or capacity from the public examples. Active calls, incoming channels, outgoing simultaneous-call allowance, call-start rate and PBX capacity remain different measures.

Test precedence, failure and return without broadening access

Begin with the direct DID Forward disabled only when that change is authorized and rollback is preserved. Prove the normal PBX path, then one approved network-down condition, the forwarded destination, caller treatment and return to the PBX after restoration. Record each provider decision, request or absence, answer, media and release separately.

Do not weaken credentials, accept arbitrary SIP sources or add a broad PBX catch-all to make the test pass. One successful new call does not prove active-call survival, universal availability, compatibility, emergency behavior or future pricing. No Callcentric service, rule, PBX, network path or call was tested for this guide.

Resolve Callcentric DID Forward precedence first

Use the Callcentric forwarding diagnostic to trace a direct DID Forward before lower-priority Call Treatments and the separate forwarded leg.