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

Inbound calls after PJSIP registration use the wrong endpoint or context

Prove the accepted registration Contact and returning INVITE, then separate line-token preservation, endpoint identification, endpoint context and called extension.

Reviewed 2026-10-07Current Asterisk outbound-registration, proxy, line-matching and troubleshooting guidance plus Asterisk 22 registration and AMI references reviewed October 7, 2026; no Asterisk host, registration, Contact, line token, endpoint, identify rule, provider, proxy, request, context, extension, route, media path, compatibility, availability, price or live call was inspected or testedAdvancedDocumentation based · not lab tested

Capture the registration and returning call as one timeline

For the affected registration, preserve the loaded registration name, status, server URI, client URI, Contact user, Line and Endpoint fields. Capture the successful REGISTER Contact and the later inbound INVITE's source, Request-URI, To header, called user and any line parameter. A green registration state without the actual Contact is insufficient evidence for the return path.

Record the endpoint and context Asterisk selected, or the unidentified-request rejection. Keep a request matched to the wrong endpoint separate from one matched correctly but rejected because the extension is absent from its context.

Verify whether the far side returned the line token

If line matching is intended, confirm that the registration had both line=yes and the expected endpoint, then compare the unique token in the Contact with the returning request. The Asterisk proxy guide says the provider must support returning it in the Request-URI or To header. If the token is missing or changed, preserve that provider or proxy behavior before adding another local rule.

If the token returns intact but the expected endpoint is not selected, confirm the exact loaded registration and endpoint names and the active endpoint-identifier modules. Do not reuse a token from an earlier registration cycle as proof of the current binding.

Separate Contact user from endpoint matching

Compare the inbound Request-URI user with the registered contact_user. That value can control the extension presented to the dialplan, but it does not establish endpoint identity. Then inspect the selected endpoint's loaded context and confirm the exact extension or pattern exists there.

A change to Contact user can move the call to a different extension while leaving the endpoint wrong. A context change can make the call route while weakening tenant or trunk separation. Correct only the demonstrated destination or identity owner.

Resolve shared-proxy ambiguity explicitly

When several trunks arrive from one proxy address, a broad source-IP identify rule can collapse them onto one endpoint. Decide whether the provider supports returned line tokens, an agreed identifying header or distinct signaling addresses. Inspect the global identifier order and every endpoint's allowed methods before adding an overlapping rule.

The first successful match can hide a more specific rule. Treat that as identity-policy evidence, not as a reason to reorder mechanisms globally without checking phones, trunks and security consequences.

Correct one owner and retest negative cases

Correct only the loaded registration's line and endpoint pair, Contact user, provider return behavior, explicit identify rule, identifier order, endpoint context or dialplan destination. Apply the supported configuration path and confirm the fresh loaded objects and a new REGISTER Contact.

Retest an authorized inbound number, an invalid number, missing or altered token, unexpected source and each shared-proxy trunk. Preserve selected endpoint, context, extension, SIP response and both media directions separately. No Asterisk host, registration, Contact, line token, endpoint, provider, proxy, request, context, extension, route, media path, compatibility, availability, price or 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

Guide · Current Asterisk outbound-registration, proxy, line-matching and troubleshooting guidance plus Asterisk 22 registration and AMI references and certified Asterisk 22.8 wizard reference reviewed October 7, 2026; no Asterisk host, registration, Contact, line token, endpoint, identify rule, provider, proxy, request, context, extension, route, media path or live call was inspected or tested

Asterisk outbound registration line matching: Contact, endpoint and inbound call boundaries

Keep the registered address, Contact user, unique line parameter, selected endpoint and endpoint context separate when relating an outbound registration to a returning call.

Read guide →
Guide · Asterisk 22 LTS

Asterisk outbound registration: what it proves

Distinguish a carrier registration from endpoint configuration and successful incoming or outgoing calls.

Read guide →
Guide · Asterisk 22 LTS res_pjsip and endpoint-identifier references, the Asterisk endpoint-identification article and GHSA-qqxj-v78h-hrf9 were reviewed October 8, 2026; no PBX, package, module, configuration, endpoint, identify object, address, DNS answer, request, security event, registration, authentication, route, media path or live call was inspected or tested

Asterisk PJSIP endpoint identification: order, scope and evidence

Control how Asterisk 22 maps an incoming SIP request to an endpoint before authentication and dialplan routing.

Read guide →
Troubleshooting · Asterisk 22 LTS res_pjsip and endpoint-identifier references, the Asterisk endpoint-identification article, current object-relationship and troubleshooting guidance and GHSA-qqxj-v78h-hrf9 were reviewed October 8, 2026; the installed branch, patches, modules, generated configuration, endpoints, identify objects, DNS, provider signaling addresses, proxy path and SIP transactions require runtime verification

Asterisk PJSIP cannot identify an inbound request: endpoint-matching diagnosis

Trace the rejected SIP message through loaded identifier modules, global order, endpoint permissions and exact IP, username, header or request-URI evidence before changing authentication or routing.

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 →
Troubleshooting · Asterisk 22 LTS documentation reviewed September 26, 2026; verify options on the installed branch

Asterisk outbound registration stopped retrying

Separate an unloaded registration, a temporary failure and a permanent rejection before changing retry policy.

Read guide →
Diagnostic · Current Asterisk PJSIP transport-selection, proxy and troubleshooting guidance plus Asterisk 22 res_pjsip and outbound-registration references reviewed October 7, 2026; no Asterisk host, transport, socket, connection, DNS response, proxy, registrar, endpoint, certificate, request, media path, compatibility, availability, price or live call was inspected or tested

Asterisk PJSIP uses the wrong UDP, TCP or TLS transport

Capture one affected request, then separate its URI, DNS target, explicit object, implicit first-valid choice, existing connection and proxy owner before changing transport order.

Read guide →