Freeze one call and the effective object graph
Record the dialed DID, timestamp and timezone, phone-number SID, assigned trunk-group SID, routing type, every candidate trunk SID, priority, weight and endpoint destination. Add the provider call identifier, signaling attempts, responses, edge receipt, PBX identification, route match, answer, SDP and two-way audio. Redact credentials and tokens.
Export the effective API objects before changing them. A screenshot or remembered order cannot prove the values that selected one trunk for one call.
Confirm DID assignment before judging routing
Verify that the affected phone number targets the intended trunk group and that the group contains the expected active trunks. Then confirm call direction and endpoint destination for each trunk. A call sent through another group is not a priority or weight failure.
If no CarrierX attempt exists, preserve the bounded negative evidence and the number assignment. Do not widen a PBX route or firewall to solve an unproved provider-side mapping.
Read priority only for failover and weight only for round robin
For failover, sort the Trunk objects by ascending priority and compare the actual attempt sequence. For round_robin, compare distribution with each trunk’s weight over an approved sample; do not expect a fixed standby order from weights.
Ignore routing_data as an execution source because CarrierX documents it as unused. Retain ties and zero values explicitly rather than inventing ordering behavior not stated in the current object.
Classify the failure and health state separately
For each attempt record no response, transport failure or final SIP response. Compare that outcome with the effective soft and hard code lists. If it is hard, retain the threshold, interval, counter evidence, cooldown and later state; if it is soft, do not claim that the trunk was marked dead.
Separately capture SIP OPTIONS locations, threshold and observed probes. Confirm the all-dead last-resort value before interpreting a retry of the first trunk or a returned 502 or 503.
Prove edge receipt, PBX matching and media
For every provider attempt, look for a matching packet at the customer edge. Compare its source, Request-URI and identity headers with the intended CarrierX endpoint and the PBX endpoint-identification rule, context and first dialplan match. A provider attempt is not proof of customer-edge receipt.
If signaling succeeds, inspect offer and answer SDP, observed RTP, codec and decoded audio in both directions. A trunk-group decision does not establish a working media path.
Correct the earliest mismatch and retest recovery
Change only the demonstrated owner: DID assignment, routing type, trunk priority, trunk weight, hard or soft code list, threshold, interval, cooldown, OPTIONS locations, endpoint destination, PBX identification or media policy. Repeat one control call, one authorized failure and one post-cooldown restoration call.
Remove temporary captures and rules. This does not prove established-call survival, access diversity, unlimited capacity, compatibility, availability, pricing or every SIP response. No account, object, PBX, packet or call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- CarrierX trunk-group object ↗
- CarrierX trunk object ↗
- CarrierX SIP trunk quick start ↗
- CarrierX receive and place calls ↗
- CarrierX phone-number model ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.