Freeze one DID, call and observed destination
Record UTC and local time, affected DID, caller identity, expected and actual destination, trunk, connectivity IP, port and activation state, provider-visible CDR, failover destination, edge result and first PBX match. Redact credentials and personal data.
Classify the first divergence: the portal inventory differs; the LNP request is not activated; the wrong connectivity IP is configured; the provider delivered elsewhere; automatic failover redirected to a backup line; no INVITE reached the edge; identity normalization changed the number; or the PBX chose another route.
Reconcile Espresso DID and LNP state before tracing
Iristel describes portal workflows for DID ordering and configuration, simple or batch LNP submission, status tracking, edits to pending or rejected requests, activation of confirmed ports, cancellation and history. Compare those records with the dated order, affected number, intended trunk, connectivity IP and failover destination.
Do not treat a confirmed port, saved IP or portal destination as proof of live routing. Preserve who changed it, when it became effective and what the provider currently reports, then test only an authorized ordinary call.
Match the provider attempt to the customer edge
Use the DID and precise time window to obtain the relevant provider CDR. Treat it as provider-side correlation, not proof of customer-edge receipt or media. At the expected edge, preserve the source, Request-URI, To, asserted identity, Via, Contact, authentication exchange, SDP and response sequence.
If there is no matching edge request, verify the current provider delivery target, connectivity IP and access path before editing the PBX. A portal IP value does not prove that NAT, firewall, DNS, transport or the selected interface is active.
Distinguish automatic failover from ordinary SIP delivery
Iristel describes automatic redirection to backup lines when a primary path fails, but the public material does not publish one trigger, timer, response-code list, retry order or restore rule for every account. Preserve the configured scope, destination, change history, provider event evidence and exact outcome for the affected call.
An answer on a backup line proves only that the redirected leg answered. It does not prove the primary failure mode, an alternate SIP target attempt, active-call survival or restored normal service. Exercise failover only under an owner- and provider-approved plan.
Follow delivered identity through Asterisk or FreePBX
When the INVITE reaches the correct edge, follow the effective PJSIP identify, endpoint, transport and context. Preserve Request-URI and asserted identity before and after digit normalization, then record the first loaded inbound route, time condition, destination and any forward. Correct only the first demonstrated divergence.
Keep assigned ANI restrictions separate from inbound matching. Iristel says outbound ANI must correspond to an assigned Iristel number within the provided trunk; do not solve an inbound route problem by presenting an unauthorized caller ID.
Retest normal routing without an emergency call
After an authorized correction, retest the affected DID and one unaffected control while recording provider delivery, edge receipt, PBX match, answer and media separately. If a failover change was involved, restore the ordinary destination and prove restoration with the same evidence chain.
Keep emergency validation outside this regression. DID-level address listing and on-request 911 termination are separate from ordinary call routing, and live emergency testing requires the provider-approved procedure. No Iristel account, trunk, DID, portal, CDR, PBX, packet, call, failover event, backup line or emergency result 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.
- Iristel business SIP Trunking ↗
- Iristel wholesale SIP Trunking ↗
- Iristel SIP trunk failover and redundancy ↗
- Iristel account and Espresso DID portals ↗
- Iristel wholesale E-911 services ↗
- Iristel Reasonable Use Policy ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.