Asterisk PJSIP Endpoint, AOR, Auth and Registration Explained

Understand object relationships before editing

A registration sends REGISTER and can reference outbound authentication. An endpoint defines channel behavior and references one or more AORs and optionally outbound auth. An AOR locates contacts. An identify object assigns inbound traffic to an endpoint based on a trusted matching rule. An object existing in CLI output does not mean all of its references resolve or that a contact exists.

Complete registration-auth trunk model

[carrier-auth]
type=auth
auth_type=userpass
username=EXAMPLE_USERNAME
password=PRIVATE_VALUE_NOT_STORED_IN_PUBLIC_SOURCE

[carrier-registration]
type=registration
transport=transport-udp
outbound_auth=carrier-auth
server_uri=sip:sip.example.net
client_uri=sip:EXAMPLE_USERNAME@sip.example.net
contact_user=carrier-inbound
retry_interval=60

[carrier-aor]
type=aor
contact=sip:sip.example.net
qualify_frequency=60

[carrier-endpoint]
type=endpoint
transport=transport-udp
context=from-carrier-restricted
aors=carrier-aor
outbound_auth=carrier-auth
disallow=all
allow=ulaw
direct_media=no

The registration and endpoint may reference the same outbound auth but serve different transactions. The registration client URI and credential must follow the peer contract. The endpoint still needs an AOR for outbound addressing. Keep the working secret outside public documentation and limit file access.

Static IP-auth trunk model

[carrier-aor]
type=aor
contact=sip:203.0.113.10:5060
qualify_frequency=60

[carrier-endpoint]
type=endpoint
transport=transport-udp
context=from-carrier-restricted
aors=carrier-aor
disallow=all
allow=ulaw
direct_media=no

[carrier-identify]
type=identify
endpoint=carrier-endpoint
match=203.0.113.10

This model has no REGISTER object and may have no digest auth. The identify match is a trust decision, so specify only approved peer sources and protect against spoofing at the network boundary. The endpoint context must not expose unrestricted dialing.

Registration relationship and state

sudo asterisk -rx "pjsip show registrations"
sudo asterisk -rx "pjsip show registration carrier-registration"

<Registration/ServerURI......................> <Auth.........> <Status.....>
carrier-registration/sip:sip.example.net      carrier-auth   Registered

Registered means the registrar accepted the current binding. It does not prove the endpoint AOR is dialable, an INVITE will be admitted, or media will pass. If the CLI shows no registrations on an IP-auth trunk, that is expected.

AOR and contact resolution

sudo asterisk -rx "pjsip show aor carrier-aor"
sudo asterisk -rx "pjsip show contacts"
sudo asterisk -rx "pjsip qualify carrier-aor"

Aor: carrier-aor  1
Contact: carrier-aor/sip:sip.example.net  Avail  42.100

An AOR object with zero contacts gives Asterisk no address for that logical destination. Causes include a missing static contact, an endpoint that never registered, max_contacts=0 for an inbound registration scenario, expired contacts, or a name mismatch. Qualification status reflects OPTIONS behavior only.

Inbound identify and matching order

sudo asterisk -rx "pjsip show identifiers"
sudo asterisk -rx "pjsip show endpoint carrier-endpoint"
sudo asterisk -rx "pjsip show identifies"

If a request logs “No matching endpoint found,” compare the packet’s observed source address with the identify match and inspect identifier order. Do not trust the From domain as proof of network source. Where source addresses legitimately vary, obtain the peer’s published architecture and use a supported, bounded matching method.

CLI verification matrix

Object exists but calls still fail

Rollback and security

Back up the complete object set because restoring only the endpoint can leave mismatched references. After rollback, show each object and repeat an inbound and outbound controlled test. Keep auth files private, constrain identify matches, isolate inbound contexts and avoid publishing CLI output that contains internal addresses or user names.

Related engineering resources

Safe object change sequence

When changing a trunk, model the desired object graph before editing: transport, endpoint, AOR/contact, authentication, optional registration and identify mapping. Validate object names and references in a staging file, back up every affected section, then introduce the smallest coherent set. Reloading an endpoint that references an absent AOR creates a predictable failure even though the endpoint itself appears in CLI output.

After change, prove outbound and inbound behavior separately. Outbound validation follows endpoint to AOR/contact and optional auth; inbound validation follows observed source or other identifier to endpoint and restricted context. Registration is a third transaction with its own auth relationship. Keeping these tests distinct prevents a Registered status from masking an inbound identify failure.

Expected state after object loading

The expected state is not merely “objects listed.” The selected endpoint must name the intended context, codecs, transport, AOR and outbound auth; the AOR must contain the correct static or registered contact; the registration must be Registered only when that model applies; and the identify object must map the observed authorized source to the same endpoint. Save a sanitized snapshot of those relationships before the call.

During the test, prove that the outbound INVITE uses the resolved contact and transport, and that an inbound request enters the restricted context through the expected identifier. If either direction selects a different object, return to matching and naming rather than changing media options. This expected-state record is the comparison point for rollback.

Inputs you need from your peer