Phone makes calls but cannot receive them

Use a controlled incoming call

Call the extension internally first, then call its public route if it has one. Record the time, source, destination and exact outcome. If internal delivery fails, the carrier is not the first suspect. Use the PBX log and SIP trace to prove whether the running dialplan selected the extension and whether Asterisk attempted an outbound INVITE to a device contact.

Inbound and outbound routing are separate

Separate endpoint, AoR and contact evidence

In Asterisk PJSIP, the endpoint supplies the calling profile, an associated Address of Record tells Asterisk where that endpoint can be contacted, and one or more Contact URIs provide the actual destinations. Use pjsip show endpoint <name> to confirm the loaded AoR association, then pjsip show aor <name> to inspect its contacts. An endpoint with no AoR or an AoR with no contact cannot be reached merely because outbound calls worked earlier.

A contact may be created by an accepted REGISTER or configured as a static SIP URI. Keep registration acceptance, stored contact, qualification status and successful call delivery separate. Do not add a static contact to conceal a broken dynamic-registration design.

Check contact ownership and network reachability

Confirm that each stored contact belongs to the intended device and reflects its current network path. A phone can send an outbound request through NAT while an old or unroutable contact sends inbound requests elsewhere. Check for duplicate account use, unexpected contacts and the configured maximum-contact policy; another device registered to the same identity can change which contacts receive a call.

If Asterisk sends the INVITE but receives no usable response, inspect the selected contact, transport, firewall state and NAT mapping. If Asterisk never creates the attempt, return to destination logic and AoR/contact resolution before troubleshooting media.

Inspect handset behavior

If the INVITE reaches the phone, check do-not-disturb, local forwarding, account activation and the SIP response it sends. A 180 or 183 response, audible local ringing, user answer, 200 response, established dialog and usable media are separate outcomes. A silent ringtone or headset setting can make an alerting call appear undelivered; compare the phone's call history with the PBX record.

Confirm persistence

Repeat delivery after a handset restart and after enough time to exercise registration renewal and contact expiry. Test through the public number as well as the direct extension, and confirm that the stored contact and selected device remain expected. Do not solve stale contacts by allowing unlimited registrations or disabling qualification without understanding the account design and security boundary.

Check SureVoIP’s first destination before blaming the backup

Use the SureVoIP multi-destination workflow when an inbound call does not reach a later destination; the documented policy advances on timeout, not every response.

Separate a removed Magrathea pool member from a PBX rejection

The Magrathea provider-specific diagnostic distinguishes provider pool state, probe handling, call selection and failure after SIP delivery.

Prove NFON endpoint selection before changing the backup PBX

The NFON provider-specific workflow keeps number routing, high-availability mode, endpoint readiness, INVITE delivery and PBX acceptance separate.