Capture one rejected request and its real inputs
Record the timestamp, method, transport, local listener, packet source address and port, Request-URI, To user, From user and the exact warning or rejection. For REGISTER, also preserve every Contact URI host and port before any supported rewrite, then the AoR name and stored-contact result if one exists. Protect credentials and customer identifiers.
State whether no response was sent, authentication never began, the endpoint was unidentified, the REGISTER was rejected, the contact was not stored or a later call failed. These symptoms can share an address but they do not prove the same ACL stage failed.
Inventory every loaded ACL owner
Confirm that res_pjsip_acl is present, then inventory module-wide ACL objects, the endpoint's ACL fields and any named acl.conf sections they reference. Use acl show or acl show <name> for named lists and preserve the loaded PJSIP endpoint and identification state. Compare that runtime snapshot with the configuration owner instead of editing generated files.
Do not assume the first matching CIDR in source text is the effective rule. A request may encounter a module-wide source rule, endpoint source rule and REGISTER Contact rule, while endpoint identification and authentication remain separate decisions.
Compare packet source with Contact address only for REGISTER
For ordinary INVITE, OPTIONS, SUBSCRIBE or MESSAGE traffic, follow the packet source through the applicable source-address controls. For REGISTER, compare both the packet source and each advertised Contact address with their respective source and Contact lists. A NATed phone can send from a permitted public tuple while advertising a private address; a proxy can create another legitimate arrangement that must come from the actual design.
Do not solve a Contact rejection by broadly permitting private, loopback or all addresses. First prove what Asterisk received, what later destination would be stored and whether supported contact rewriting or a proxy policy owns the correction.
Separate ACL rejection from identification and authentication
If the source ACLs pass, continue to endpoint identification, then authentication and dialplan authorization. A source in an allowed subnet does not establish which endpoint should own the request. A correctly identified endpoint can still require credentials, and a completed digest exchange does not authorize arbitrary destinations or calling identities.
Use the existing unidentified-request diagnostic when the failure is the identifier order or match object. Use registration and authentication diagnostics for 401, 403, AoR or credential problems. Do not disable authentication, enable anonymous access or move an endpoint into a broader context to make an ACL symptom disappear.
Change one rule and prove both sides of the boundary
Correct only the demonstrated owner: stale provider network, wrong host mask, missing named ACL reference, unsafe Contact target or unsupported client or proxy behavior. Preserve the previous rule and rollback. Apply through the supported configuration owner, reload only the affected supported layer and verify the loaded state.
Repeat the same request, then run an unrelated negative source and an unsafe Contact control. Confirm endpoint identification, authentication, intended routing and expected call direction without widening Internet exposure. Remove temporary logging and captures. No host, ACL, endpoint, registration, provider path or call was tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 22 res_pjsip_acl configuration reference ↗
- Asterisk 22 res_pjsip endpoint configuration reference ↗
- Asterisk PJSIP configuration sections and relationships ↗
- Asterisk pjsip.conf sample ↗
- Asterisk debug-information collection guide ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.