pjsip
"No matching endpoint found" in Asterisk
Asterisk received a SIP request and could not match it to any configured endpoint. On a box reachable from the internet, the overwhelming majority of these are scanners guessing extensions - the diagnosis is entirely in whether you recognise the source address.
What it looks like in the log
[2026-08-17 03:12:44] NOTICE[2210] res_pjsip/pjsip_distributor.c: Request 'REGISTER' from '"1001" <sip:1001@203.0.113.40>' failed for '203.0.113.40:5062' (callid: a94c2f0b) - No matching endpoint foundWhat it means
Before Asterisk will process a request, res_pjsip has to decide which endpoint it came from - by the user in the From header, or by source IP through an identify section. When neither matches anything configured, the request is rejected and this NOTICE is logged.
The line therefore has two completely different readings. From an address you do not recognise, it is an attack surface report: someone on the internet is probing for extensions to register against. From your own device or your carrier's address, it is a configuration mismatch, and the quoted user and IP in the line tell you exactly what failed to match.
Most common causes
-
01Internet scanners probing for extensions
The dominant source by far on any box with port 5060 open. Automated tools try REGISTER with common extension numbers around the clock. The signature is unknown IPs, sequential or dictionary usernames, and volume at all hours.
-
02A device registering with the wrong name
A phone configured with an extension number or auth name that does not exist on the PBX - a typo during provisioning, or an endpoint that was renamed - fails to match and logs this on every registration attempt.
-
03A trunk with no identify section
Inbound INVITEs from a carrier that authenticates by IP need a
type=identifysection naming the carrier's addresses. Without one, every inbound call from the trunk is rejected with this line. -
04The carrier sending from an address you did not list
Providers add and change media gateways. An identify section listing last year's IPs rejects traffic from this year's, and the failure starts without anything changing on your side.
-
05A deleted endpoint a device still remembers
An extension removed from the PBX while the physical phone keeps its config keeps trying to register, generating a steady stream of these from inside your own network.
How to tell which one it is
Read the source address in the line and answer one question: is it yours, your users', or your carrier's? An address you cannot account for is a scanner, and the correct response is a firewall rule, not a config change.
If the address is legitimate, compare the quoted user against pjsip show endpoints and the source IP against pjsip show identifies. Whichever lookup fails to match is the one to fix.
How to fix it
-
Stop answering scanners
Front the box with fail2ban or a firewall that limits port 5060 to known addresses. A PBX that only serves known trunks and a VPN has no reason to accept SIP from the whole internet.
-
Match the device's registration name to a real endpoint
Compare the user in the NOTICE character for character against the configured endpoint names. Provisioning typos live here.
-
Add or update the identify section for the trunk
List every signalling address the carrier documents in a
type=identifysection pointing at the trunk endpoint - and re-check that list when inbound calls start failing after years of working. -
Deprovision devices when their extensions go
A retired extension's phone keeps trying forever. Factory-reset or reconfigure the device rather than leaving it to fill the log.