CarrierX SIP trunking: DID assignment, trunk-group routing and failure evidence

Follow the DID through four separate objects

CarrierX models a rented phone number, its assigned trunk group, one or more trunks inside that group, and the third-party SIP endpoint as separate objects. Preserve each SID, direction and effective value before changing the PBX. A correct endpoint does not prove that the DID is assigned to the intended group, and a correct group does not prove which trunk was selected.

For each inbound incident retain the dialed DID, trunk-group SID, routing type, candidate trunk SIDs, endpoint destination, provider call identifier, customer-edge receipt, PBX identification, route match, answer and media result.

Do not mix failover priority with round-robin weight

CarrierX documents failover and round_robin as distinct trunk-group routing types. Failover attempts the lowest numeric trunk priority first and then proceeds in priority order. Round-robin distributes calls according to each trunk’s weight. Priority is not weight, and weight is not a standby order.

The trunk-group routing_data field is explicitly documented as unused. Read priority and weight from each Trunk object rather than treating a stale group-level map, array order or screen position as the effective policy.

Separate one-call advancement from dead-trunk state

Soft failure codes can define a call failure without marking a trunk dead. Hard failure codes are counted within a configured interval; after the threshold, the trunk is marked dead through a cooldown. If a code appears in both lists, the hard-failure definition takes precedence. These stages are not interchangeable.

CarrierX publishes defaults including hard code 408, threshold three, interval 60 seconds and cooldown 120 seconds, but those are API defaults—not proof of the current group. Export the effective object and correlate each response, counter transition, next attempt and later recovery.

Treat SIP OPTIONS as an independent health input

A trunk group can name routing locations that send SIP OPTIONS. The OPTIONS threshold controls failed or successful pings before dead or alive state; an empty location list disables this monitoring. A successful OPTIONS exchange is not an answered customer call, and a failed call is not proof that OPTIONS marked the trunk dead.

Preserve the selected monitoring locations, threshold, request and response evidence, trunk state and call decision separately. Confirm the hard_failure_last_resort value because an all-dead group can retry the first trunk or return a configured 502 or 503 result.

Keep authorization, PBX identity and media independent

CarrierX documents IP authorization, proxy authentication and a header-token alternative for outbound calls; it warns that the header token is sent in clear text inside the INVITE. The reviewed quick starts do not establish SIP REGISTER as the inbound binding. Do not add registration merely because a PBX template expects it, and remove reusable tokens from shared traces.

For inbound calls, verify the documented System Gateway source, configured endpoint, PBX endpoint-identification result, context and delivered number. Then preserve offer and answer SDP, RTP endpoints, negotiated codec and decoded audio. Signaling acceptance does not prove two-way media.

Read capacity, codecs and resilience narrowly

The Trunk object exposes separate inbound and outbound simultaneous-call capacities and ordered narrowband and wideband codec controls. A zero capacity field means no configured limit on that trunk object; it does not prove unlimited account, carrier, PBX, access or destination capacity. The reviewed pages do not publish one account-wide call-start rate.

Run one authorized new-call failure and one restoration test at a time. Do not infer power, access, DNS, PBX or established-call resilience from provider-side trunk selection. No CarrierX service, object, packet, media path or call was tested for this guide.

Diagnose CarrierX selection from the object graph

Use the CarrierX trunk-group diagnostic to correlate the DID, group, routing type, trunk priority or weight, health state, endpoint and PBX result.