VoIP.infoThe independent guide to business communications.
VoIP.info Troubleshooting

didlogic outbound calls work but an inbound DID misses the PBX

Trace the purchased number, destination type, registration Contact or SIP URI, provider attempt, Asterisk identification, dialplan match and media without treating outbound success as inbound proof.

Reviewed 2026-10-18Current first-party didlogic SIP-account, inbound-destination, regional-gateway, PBX, Asterisk and interconnection documentation reviewed October 18, 2026. Digest registration and source-IP authentication are separate models; purchased-number destination, current registration Contact or SIP URI, provider attempt, customer-edge receipt, Asterisk endpoint identification, dialplan match, answer and media remain separate evidence. The reviewed pages do not publish one universal response-code, timeout, retry, sequence-advancement or restoration contract for every destination type. No didlogic account, credential, number, destination, registration, authorized IP, DNS answer, PBX, packet, media stream or live call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one inbound failure and one outbound control call

Record the purchased DID, timestamp and timezone, caller treatment, selected identity model, SIP account or authorized public IP, regional gateway, number destination type and target, destination order, registration Contact or SIP URI, provider and PBX call identifiers, customer-edge receipt, Asterisk endpoint, context, dialplan match, response, answer and media. Redact credentials and personal numbers.

The outbound control call shows that one egress identity and route worked at that time. It does not prove that the purchased number points to this SIP account or URI, that an inbound packet reached the same PBX, or that the dialplan accepted the delivered number form.

Prove the number destination before touching Asterisk

Open the purchased-number record and export the actual destination type, target and order. For digest authentication, confirm that it targets the intended SIP account and preserve the current Contact. For IP authentication, confirm the explicit SIP URI, FQDN, port and transport. Check whether account defaults populated a value when the number was created.

Do not reset the password, add a PBX catch-all or broaden the firewall while the number still points to a Webphone, external number, old SIP account or old URI. Correct the earliest owned mismatch first.

Verify the effective identity and regional gateway

For digest, retain the REGISTER request, challenge and successful binding to the expected Contact. For IP authentication, retain the provider-approved source address and the customer public address or SBC target used in the SIP URI. Resolve the configured regional gateway name and preserve current DNS answers rather than substituting a historical address.

A digest registration is not required evidence for IP authentication, and an authorized egress source is not the same object as an inbound destination. Keep those states separate in the incident timeline.

Follow the INVITE through endpoint identification and dialplan

If no request reaches the edge, preserve the provider-side destination, attempt and result for escalation. If it does, capture source, transport, Request-URI, To header and called-number form, then identify the first Asterisk peer or PJSIP endpoint, assigned context, normalization and first matching extension. The provider example explicitly handles both plus-prefixed and non-prefixed DIDs.

An Asterisk rejection can be deliberate protection rather than a carrier failure. Do not add _. or _X. acceptance until the source and number ownership are proved and the intended context is isolated.

Separate answer, media and later destinations

After signaling reaches the intended application, retain the answer response, SDP offer and answer, codec, DTMF mode, RTP endpoints, firewall decisions and packets in both directions. Use an authorized listening result to distinguish packet presence from intelligible audio.

If a sequence or hunt group is configured, preserve each target, response or transport outcome, elapsed time and later attempt. The public pages do not define one universal response-code or timer matrix, so a saved second destination is not proof that it should or did receive this call.

Correct one boundary and retest failure plus recovery

Change only the demonstrated owner: purchased-number destination, SIP-account binding, SIP URI, authorized IP, DNS-based gateway, Asterisk identify rule, context, DID normalization, inbound route or media policy. Preserve the prior state and repeat an authorized inbound call, outbound control, intended failure or no-answer branch when applicable, return to primary, answer, two-way media, clean release and restart.

Remove temporary captures, broad rules and elevated logging. One successful call does not establish availability, compatibility, capacity, emergency behavior or established-call survival. No didlogic account, number, route, PBX, network path or live 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.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Provider research · Current first-party didlogic SIP-account, inbound-destination, regional-gateway, PBX, Asterisk and interconnection documentation reviewed October 18, 2026. Digest registration and source-IP authentication are separate models; purchased-number destination, current registration Contact or SIP URI, provider attempt, customer-edge receipt, Asterisk endpoint identification, dialplan match, answer and media remain separate evidence. The reviewed pages do not publish one universal response-code, timeout, retry, sequence-advancement or restoration contract for every destination type. No didlogic account, credential, number, destination, registration, authorized IP, DNS answer, PBX, packet, media stream or live call was inspected or tested

didlogic SIP trunking: identity, DID destinations and PBX evidence

Separate digest registration from IP authentication, then trace each purchased number through its destination, provider attempt, PBX match and media.

Read guide →
Hub · Provider records reviewed individually on their listed dates; account-specific terms and availability require direct confirmation

SIP trunk provider research

Compare the connection model, call routing, media support and cost structure of documented SIP trunk services.

Explore topic →
Guide

SIP trunking: numbers, capacity and operational control

Plan the carrier relationship that connects a self-managed PBX to outside calling.

Read guide →
Guide

SIP trunk IP authentication

Understand source-address trust and the consequences of a WAN address change.

Read guide →
Protocol reference

SIP REGISTER explained

Understand contact bindings, authentication challenges and why registration does not prove calling works.

Read guide →
Guide · Current Asterisk PJSIP object, outbound-registration, configuration-example and res_pjsip references reviewed October 1, 2026; no account, carrier, PBX, endpoint, registration, identifier, route, call, emergency workflow, media stream, capacity or failover path was tested

Plan and configure an Asterisk SIP trunk

Translate each carrier direction into explicit PJSIP objects, identification, restricted dialplan, retry policy and leg-by-leg acceptance evidence.

Read guide →
Guide · FreePBX 17 and current Asterisk res_pjsip documentation reviewed October 5, 2026; Sangoma's generic module pages are responsibility guides rather than an exact installed field map; no FreePBX host, module, account, credential, trunk, route, registration, number, identity, call, media path, failover, capacity, emergency workflow or compatibility was tested

Configure and verify a FreePBX 17 PJSIP trunk

Translate current carrier requirements into FreePBX-owned PJSIP trunk, route and identity controls, then verify the generated Asterisk objects and each call direction independently.

Read guide →
Guide

Firewall rules for VoIP

Define management, signaling and media access separately using actual deployment requirements.

Read guide →
Troubleshooting · First-party Asterisk documentation and SIP standard reviewed September 30, 2026; FreePBX 17 terminology retained; no PBX, provider, number, route or live call test

Inbound VoIP calls do not reach the business

Trace carrier delivery, Asterisk endpoint identification, DID matching and the final destination without collapsing the boundaries.

Read guide →
Troubleshooting · Asterisk 22 LTS res_pjsip and endpoint-identifier references, the endpoint-identification article, current Asterisk PJSIP guidance and GHSA-qqxj-v78h-hrf9 were reviewed October 8, 2026; adapt the method to the installed patch, provider handoff and PBX management layer

Inbound SIP trunk rejected as an unidentified endpoint

Trace a carrier INVITE from packet source to PJSIP identify object before changing DID routes or authentication.

Read guide →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →