Freeze one DID and one failed inbound attempt
Record local and UTC time, production account, DID, explicit trunk-group assignment, default trunk group, group ID, ring type, PoP, ordered switch IPs and ports, expected IDT Express source, firewall result, delivered Request-URI, loaded PBX route, Call-ID, SIP responses, SDP summary and media symptom. Redact API and SIP secrets.
Classify the earliest divergence: wrong API environment; wrong DID; explicit assignment missing; unexpected default fallback; wrong group; wrong ring type; wrong switch order; wrong PoP; blocked source; no edge receipt; PBX rejection; or signaling success without working media.
Read production state without confusing it with a call
Use the live API endpoint to read the DID and trunk-group objects, preserving the API request ID and returned group fields. Do not use sandbox data as production evidence: IDT Express says sandbox data is fake and sandbox calls do not affect the account. Keep API status and errors separate from SIP responses.
If the live request returns 403, 422 or 429, resolve the API credential, input or throttling boundary before assuming the SIP route changed. A successful API read proves the stored management object, not that IDT Express sent an INVITE, a firewall admitted it or the PBX accepted it.
Resolve explicit assignment and default fallback first
Compare the DID current assignment with the intended trunk group and identify the account default. New DIDs begin on the default group, deleted groups move their DIDs there, and default routing can be used when the intended route cannot be determined. Preserve the before-and-after object if a correction is required.
Do not reorder switches to mask a wrong group. If only one DID fails or reaches an unexpected destination, prove its assignment before changing the firewall or PBX. If every DID on the same group fails, continue with ring type, switch targets and PoP.
Interpret ring type and switch evidence literally
For a sequential group, correlate the first switch attempt and the exact evidence that it was unreachable before expecting the next array entry. For a simultaneous group, correlate every parallel INVITE, provisional and final response, the selected answer and cancellation of other branches. Keep a busy or policy rejection distinct from no response.
Confirm each configured target is an IPv4 address with the intended port and that the current edge actually owns it. Do not call the route resilient merely because multiple addresses are stored; prove the documented trigger and result with an approved bounded test.
Follow PoP source through the firewall and PBX route
Match the configured US, UK or HK PoP to the current source addresses in IDT Express documentation. At the edge, retain source, destination, port, timestamp and return traffic. At the PBX, compare Request-URI and identity with the loaded inbound route rather than a stale GUI draft.
If no packet reaches the edge, preserve that negative capture and provider correlation data. If the edge receives the INVITE but the PBX does not, narrow the firewall, NAT or forwarding rule. If the PBX rejects it, correct the proven identity or dialplan boundary instead of opening broad access.
Carry a connected dialog into SDP, media and a bounded retest
When signaling connects, compare the offer and answer, selected G.711 A-law, G.711 mu-law, G.729A, G.729AB or G.723 payload, advertised addresses and packets in both directions. Treat T.38 as separately negotiated fax evidence, not a guarantee. Correct only the demonstrated assignment, default, ring type, switch, PoP, source rule, PBX route or media boundary.
Repeat one authorized non-emergency transaction and correlate the live API object, Call-ID, branch responses, selected switch, PBX decision, answer and both media directions. Do not describe it as proof of outbound service, emergency activation, capacity, price, availability, compatibility or support performance.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IDT Express DID and trunk-group API ↗
- IDT Express SIP Trunking ↗
- IDT Express SIP-trunk provider services ↗
- IDT Express DID Numbers ↗
- IDT Express DID setup troubleshooting ↗
- IDT Express SIP trunk security ↗
- IDT Express voice termination ↗
- IDT Express guide to SIP trunking ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.