didlogic SIP trunking: identity, DID destinations and PBX evidence

Choose the trunk identity before reading its health signal

didlogic documents digest authentication with a generated five-digit SIP username and password, and a separate source-IP authentication model for static infrastructure. Digest uses SIP REGISTER and can deliver inbound calls to the registered SIP account. IP authentication does not need registration; inbound numbers must target an explicit SIP URI.

Record the selected model, credential or authorized public address, regional gateway, transport, customer owner and intended inbound destination. A green registration is meaningful for the digest model but is neither required nor expected proof for an IP-authenticated trunk.

Follow each purchased number to its effective destination

The inbound setup page supports SIP account, Webphone, SIP URI and external telephone-number destinations, plus sequence and hunt-group arrangements. Export the selected destination type, target, order and any default that was applied when the number was created. A working outbound call proves an authenticated egress path, not the inbound destination of a purchased number.

For IP-authenticated Asterisk delivery, the current guide tells the operator to select SIP URI, enter the number and FQDN, port and transport, and place the destination at the top when other destinations exist. Preserve the actual saved value and ordering rather than relying on the configuration that was intended.

Keep gateway selection, DNS and provider identity independent

didlogic publishes regional gateway DNS names and recommends allowing traffic by DNS name rather than pinning the displayed addresses. Its pages also say media addresses are numerous and can change. Preserve the configured name, resolved answers and time-to-live, provider source observed at the edge, selected Asterisk endpoint or identify object and transport.

A reachable regional gateway, successful REGISTER or accepted outbound request does not prove that an inbound INVITE used the same route or matched the intended PBX object. Do not copy an old address into a permanent allowlist without current account guidance and bounded testing.

Trace delivered DID form and the first dialplan match

The first-party Asterisk example handles the DID both without and with a leading plus in the from-siptrunk context and includes a catch-all for unknown values. Capture the actual Request-URI user, To header, endpoint or peer selected by Asterisk, assigned context, normalized extension, first matching dialplan rule and final SIP response.

Provider delivery to the customer edge is not proof that the intended extension, queue, menu or voicemail was selected. Avoid adding a broad catch-all before the delivered form and ownership of the mismatch are known; it can conceal misrouted numbers or admit calls to an unintended context.

Separate signaling success from audio and capacity

The PBX pages prioritize G.711 u-law and A-law and describe UDP 10000–20000 as the typical RTP range. Interconnection also records signaling addresses, transports, media ranges, codecs, DTMF preference and requested calls per second. Retain SDP offer and answer, selected codec, DTMF mode, RTP endpoints, firewall decisions and packets in both directions.

Registration, a 200 response, call duration or provider record does not prove two-way intelligible media. Concurrent calls, call-start rate, account limits and PBX capacity are different controls and must not be converted into one capacity claim.

Test normal routing, a bounded failure and restoration

For a sequence or hunt group, record the first target, exact response or transport outcome, elapsed time, any later provider attempt, answer and caller treatment. The reviewed pages document ordered destinations but not one complete matrix for every SIP response, timeout, retry or return-to-primary behavior. Do not import another carrier’s rules or represent a later configured destination as a tested failover result.

Change the earliest proved mismatch, retain rollback material and repeat an authorized inbound and outbound call, answer, two-way media, DTMF or transfer if required, clean release and restart. No didlogic service, PBX, firewall, failover event or live call was tested for this guide.

Trace a didlogic inbound DID independently of outbound success

Use the didlogic inbound-DID diagnostic to follow the purchased number, destination, current Contact or SIP URI, provider attempt, PBX match and media.