Freeze one DID, one group and one observed failure
Record the DID, timestamp and timezone, assigned inbound trunk group, member trunk IDs and types, priority, weight, ringing timeout, rerouting disconnect-code selection, group and per-trunk capacity limits, the first INVITE destination, response or timeout, every DIDWW CDR attempt and the final caller result. Redact credentials, authorization fields, customer addresses and telephone numbers before sharing evidence.
Classify the symptom before editing: no first attempt, first attempt but no second CDR, second attempt to an unexpected member, capacity rejection, or a second delivery that the PBX mishandles. Those outcomes have different state owners.
Prove DID assignment and exact group membership first
DIDWW describes an inbound trunk group as a routing object containing SIP and PSTN trunks, and says each trunk can belong to only one group. A trunk visible in the account does not prove it belongs to the DID's assigned group. Preserve the DID assignment, group ID and ordered member inventory from the same time window.
A standalone SIP trunk can use a static endpoint or dynamic registration, while a group can mix trunk types. Prove the exact member selected before diagnosing DNS, registration or PBX state; those mechanisms are not interchangeable.
Read priority, weight and capacity as different controls
DIDWW says lower priority numbers are tried first. Weight distributes calls among members that share a priority; it does not create a guaranteed member sequence. Group and per-trunk capacity limits are separate controls, and the response-code reference records distinct capacity-limit outcomes.
If the requirement is standby behavior, compare priorities before weights. If the complaint is uneven distribution among equal-priority trunks, collect a bounded series of attempts rather than inferring a defect from one call. A capacity rejection is not proof that the next member is eligible or reachable.
Bind advancement to the configured timeout or rerouting code
The failover reference says the ringing timeout controls how long DIDWW waits for a response and that selected rerouting disconnect codes trigger another trunk attempt. Preserve the configured values and the first attempt's actual final response, absence of response or DIDWW internal reason. A code appearing in a call log is not by itself proof that the code was selected for rerouting.
Keep 404, 408, 480, 486, 487, 488, 500, 503, 603 and an unanswered ringing timeout distinct. Do not rewrite a PBX response merely to force failover: first decide whether the intended business treatment is retry, busy, voicemail, rejection or error.
Reconcile one CDR per routing attempt
DIDWW says DNS SRV and trunk-group failover generate a separate CDR for each attempt. Its Voice IN stream exposes routing_attempt, is_last_cdr, destination, time, disconnect fields and call identifiers. Correlate attempts by the provider identifiers and a narrow time window; do not mistake the final successful CDR for the only delivery attempt.
routing_attempt: 1 plus is_last_cdr: true establishes that DIDWW recorded no later attempt for that routing process. It does not, without the group configuration and first outcome, explain whether the route ended by policy, timeout, capacity, caller cancellation or another condition.
Exercise the failing branch and restoration separately
After correcting the earliest demonstrated mismatch, use an authorized maintenance test to preserve the normal first member, the approved failure result, the expected next attempt, the next PBX match, answer response and two-way media. Restore the primary condition and verify a later new call returns to the intended policy.
DNS SRV at a static trunk with an empty port is a separate failover layer from a trunk group and can add more attempts and CDRs. Record which layer advanced. Remove temporary responses and elevated logging when finished. One successful new-call exercise does not prove active-call survival, availability, capacity, emergency behavior or seamless restoration.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- DIDWW service failover and load balancing ↗
- DIDWW inbound trunk groups ↗
- DIDWW inbound SIP trunk configuration ↗
- DIDWW SIP response codes in call logs ↗
- DIDWW Voice IN CDR streaming attributes ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.