Asterisk PJSIP: Endpoint Identify & Match (Fix 401/No Matching Endpoint) (Latest Versions)

In modern PJSIP-based Asterisk deployments, one of the most critical mechanisms for accepting inbound SIP traffic from providers is the identify → match IP configuration.

Unlike legacy chan_sip, where inbound calls were loosely matched, PJSIP requires an explicit mapping between:

• The source IP address of the incoming SIP request
• The PJSIP endpoint that should handle the call

If this mapping is missing or incorrect, inbound calls will reach Asterisk but will be rejected before the dialplan — creating one of the most confusing real-world telecom failures.

Real Production Failure Scenario

A common situation in enterprise call centers:

• SIP provider sends an INVITE to your public IP
• Asterisk receives the packet successfully
• No ringing occurs
• CLI shows No matching endpoint found

Engineers often suspect:

• Dialplan errors
• Firewall problems
• Codec mismatch

But the real cause is usually:

👉 Missing or incorrect identify match IP.

How PJSIP Matches Inbound Calls

When a SIP INVITE arrives, PJSIP performs the following sequence:

1. Read source IP address of packet
2. Search all identify sections for a matching IP
3. If match found → bind request to that endpoint
4. Apply endpoint context → send call to dialplan

If no identify match exists, Asterisk will:

• Reject the call
• Never execute dialplan
• Log authentication or endpoint errors

Complete PJSIP Identify Configuration Example

[provider-endpoint]
type=endpoint
transport=transport-udp
context=inbound-provider
disallow=all
allow=ulaw,alaw
aors=provider-aor

[provider-aor]
type=aor
contact=sip:PROVIDER_IP

[provider-identify]
type=identify
endpoint=provider-endpoint
match=PROVIDER_IP

This configuration explicitly tells Asterisk:

“If a SIP request arrives from PROVIDER_IP, treat it as provider-endpoint and route it to inbound-provider context.”

Multiple Provider IP Addresses

Many telecom providers send SIP traffic from:

• Primary signaling IP
• Secondary failover IP
• Load-balanced IP range

PJSIP supports multiple match entries:

[provider-identify]
type=identify
endpoint=provider-endpoint
match=203.0.113.10
match=203.0.113.11
match=203.0.113.12

Missing even one provider IP can cause:

• Intermittent inbound call failures
• Calls working sometimes but not always

Identify vs Registration-Based Trunks

Two inbound authentication models exist:

1. Registration-Based

• Provider sends calls only after successful registration
• Identify may still be required in strict deployments

2. IP-Authenticated (Most Enterprise Trunks)

• No SIP username/password used for inbound calls
• Provider trusts your public IP
• Identify match becomes mandatory

Debugging “No Matching Endpoint Found”

Step 1 — Enable SIP Logging

pjsip set logger on

Look for:

No matching endpoint found

Step 2 — Confirm Source IP

Read the INVITE packet’s real IP address.

Providers sometimes send from:

• Unexpected media gateway IP
• Different region load balancer

Step 3 — Capture Packets with tcpdump

sudo tcpdump -i any -s 0 -w inbound_identify.pcap udp port 5060

Open in Wireshark → verify actual source IP → add to match.

Security Importance of Identify Matching

Identify matching is not only functional — it is also a security control.

• Prevents unauthorized SIP traffic from random internet hosts
• Ensures only trusted provider IPs can reach dialplan
• Reduces SIP scanning and fraud risk

For production telecom systems, strict identify configuration is mandatory.

Real-World Misconfiguration Examples

Inbound Calls Reach Server but Never Ring

Cause → identify missing or wrong IP.

Calls Work Only Sometimes

Cause → provider using multiple signaling IPs, only one configured.

Random SIP Scans Trigger Dialplan

Cause → overly permissive identify or anonymous endpoint enabled.

Best Practices for Production Systems

• Always request full IP list from SIP provider
• Configure all match entries explicitly
• Combine identify with firewall IP whitelisting
• Monitor logs for unexpected inbound sources

MYLINEHUB Architecture Note

In MYLINEHUB telecom deployments:

• PJSIP identify matching is enforced for every trunk
• Inbound routing depends on secure endpoint mapping
• Voice AI flows triggered via ARI rely on correct endpoint resolution

Without proper identify configuration, inbound AI or queue routing would never activate — even if SIP connectivity exists.

Key Takeaway

In PJSIP, inbound call handling begins before the dialplan.

The identify → match IP configuration is the gatekeeper that determines whether:

• a call is trusted
• an endpoint is selected
• the dialplan is executed

Mastering identify matching is essential for stable, secure, production-grade Asterisk telecom systems.