Register a SIP phone with Asterisk PJSIP: objects, contacts and proof

Map the phone to four different objects

A PJSIP endpoint owns call policy and references an auth object and one or more AORs. The auth object validates the phone's credentials. The AOR supplies the reachable locations, and an accepted REGISTER creates or refreshes a dynamic contact under that AOR. Those are related objects, not four names for the same state.

For inbound registration, Asterisk's current reference says the AOR object name must match the user portion of the REGISTER To URI, which is normally the username configured in the phone. The phone's registrar points to the PBX's reachable address; its SIP user and authentication ID may appear as separate handset fields. Record the exact phone model, firmware, account slot, transport, registrar, port, user and auth ID without exposing the secret.

PJSIP endpoint, auth and AOR

Define a restricted single-device identity

The endpoint below references a separate auth object and AOR, permits only one codec and enters a restricted internal context. max_contacts=1 limits dynamic registration contacts for the AOR; it is not a call-capacity setting. The fragment adds no public listener, paid trunk, emergency route or outbound permission.

This is documentation-based configuration, not a complete PBX. It requires a suitable existing transport, a matching dialplan and a unique strong secret inserted locally. Back up the current files and validate unused object names. Start on a restricted reachable network before adding NAT or remote-access complexity.

[2101]
type=endpoint
context=lab-internal
disallow=all
allow=ulaw
auth=auth-2101
aors=2101
direct_media=no

[auth-2101]
type=auth
auth_type=userpass
username=2101
password=REPLACE_WITH_UNIQUE_STRONG_SECRET

[2101]
type=aor
max_contacts=1

Observe the complete REGISTER transaction

Apply the configuration through the correct standalone Asterisk lifecycle and confirm the intended objects loaded. Enter the registrar, user, auth ID, secret and selected transport on the phone, then bound temporary PJSIP logging to one authorized attempt. An initial authentication challenge can be normal; acceptance requires the challenged request to complete and the expected contact to appear.

Inspect pjsip show endpoint 2101, pjsip show aor 2101 and pjsip show contacts. Preserve the response code, To user, authentication username, source address, Contact URI, expiry, user agent and Asterisk time. Repeated challenges, a missing endpoint or a contact under the wrong AOR are different failures. Remove secrets and sensitive addresses from shared evidence.

Choose contact replacement deliberately

Asterisk's current reference says max_contacts limits contacts added through registration. With NAT-oriented rewrite_contact, a refresh can appear with a changed source address and exceed that limit. remove_existing and remove_unavailable can remove contacts to make room, but they encode a replacement policy and can disconnect an intentionally retained device.

For a one-device identity, inspect why duplicate contacts exist before enabling replacement. If multiple devices are intentional, allocate and identify them explicitly. Test refresh, phone reboot, address change, Asterisk reload and Asterisk restart separately, recording which contact survives and how quickly the phone re-registers.

Keep qualification separate from registration

A contact can exist without being qualified. qualify_frequency controls OPTIONS attempts and qualify_timeout controls how long Asterisk waits, including DNS lookup time. In supported branches, qualify_2xx_only can require a 2xx response before the contact is marked available. These settings test the configured contact path; they do not authenticate the phone again or prove a call, dialplan or media path.

Record contact presence, qualification status, round-trip observation, transport state and registration expiry separately. A flapping contact may involve NAT state, address changes, transport lifetime, DNS or overloaded endpoints; increasing timeouts without a bounded reproduction can conceal rather than explain the failure.

Prove dialplan and media after registration

Create a second restricted internal endpoint and use the dialplan guide to permit only the intended destinations. Verify each direction separately: endpoint identification, dialplan selection, called contact, SIP dialog, negotiated codec, bidirectional RTP, decoded audio, hold and hangup. Registration proves only that Asterisk accepted and stored a contact.

Restart the handset and confirm recovery, then test busy, no-answer and unreachable behavior. Review caller ID, voicemail, forwarding and emergency policy before adding any paid trunk or broader route. Do not infer inbound reachability from an outbound call or treat a green phone icon as evidence of working media.

Prove how multiple registrations are dialed

After proving each registration, the PJSIP_DIAL_CONTACTS guide shows how to inspect the AoR set used for a call without assuming that one endpoint target expands to every device.

Verify which dynamic contact a REGISTER created

The AoR/contact diagnostic follows an accepted REGISTER through AoR association, contact identifier, expiry and replacement policy.

Prove the phone with a dynamic-contact inventory

Use the AMI inbound-registration guide to distinguish a current registrar binding from a static contact and later call behavior.

Relate a registered contact to the loaded endpoint

Use the AMI endpoint-state diagnostic to compare endpoint, AoR, dynamic contact and aggregate state without assuming a call outcome.

Check AoR limits and replacement policy around registration

Use the AMI AoR-list diagnostic to preserve the policy and contact set before and after one authorized REGISTER.