VoIP.info Guide

Register an IP phone with FreePBX: contact and call evidence

Map registrar, SIP identity, authentication and transport without treating a registration indicator as completed-call evidence.

Reviewed 2026-10-30FreePBX 17 · Debian 12; Sangoma field reference is explicitly labelled PBX GUI version 13, reviewed September 30, 2026IntermediateDocumentation based · not lab tested

Freeze the intended registration path

Record the exact phone model and firmware, account slot, FreePBX extension, registrar name or address, port, transport, network location and provisioning owner before changing anything. The handset needs power, addressing, name resolution when used, reachability to the intended PJSIP listener and an applied extension configuration. A reachable web interface or ICMP response does not prove that SIP reaches the correct listener.

For the first acceptance, use an authorized, restricted local path where practical. Treat a later remote path as a separate design covering NAT, VPN or TLS. Do not temporarily expose the PBX broadly, disable certificate validation or leave SIP ALG changes undocumented merely to make an endpoint register.

Registration: isolate transport from authentication
If REGISTER never reaches the server, check DNS, transport and firewall. If the server challenges, inspect the authenticated retry. A 200 response confirms registration, after which calls need separate testing.

A first 401 challenge can be normal. Read the response to the authenticated retry before changing credentials.

Map labels to SIP roles, not guesses

Use the intended PBX name or address as the registrar and enter the extension's SIP identity, authentication username and device secret in the fields required by the exact phone. Never substitute the FreePBX administrator or User Manager password. Manufacturer labels vary, so server, registrar, proxy, outbound proxy, user ID, auth ID and display name must be mapped with the endpoint's own administration guide.

In Asterisk, the endpoint profile, auth object, AOR and dynamic contact are related but distinct. Max Contacts limits how many contacts REGISTER may create for the AOR; it does not describe simultaneous calls. Transport selection must match a configured PBX listener and, for TLS, the intended trust and name-validation path.

Classify the failure by the last proven boundary

A phone that sends no request, a request that never reaches the PBX, an unanswered request, a normal authentication challenge, a rejected credential, an interval-policy failure and a successful REGISTER with the wrong contact are different symptoms. Capture one bounded attempt and correlate handset time, PBX time, source address, transport, response code and the expected endpoint/AOR.

A handset's registered icon should correspond to the expected current contact on the intended AOR. Qualification or contact reachability remains separate from authentication, dialplan selection and media. Before changing routes, inspect identity, auth username, secret, registrar, port and transport, then check whether a firewall or intrusion-prevention rule reacted to earlier failures.

Prove call behavior beyond registration

Call a known internal destination in both directions and record alerting, answer, bidirectional audio and hangup separately. Then check hold, attended and blind transfer, voicemail deposit and retrieval, and message-waiting indication only when those features are in scope. Registration and a completed SIP dialog do not prove RTP, decoded audio or correct caller identity.

Restart the handset and verify both registration recovery and configuration persistence. A provisioning service may restore older values after reboot, so identify the authoritative source before accepting a manual change. Add external and emergency calling only after permissions, asserted identity and location policy are understood and the provider's authorized test path is documented. No phone, PBX listener, certificate, extension, auth object, AOR, contact, call, media path, voicemail, provisioning service or emergency route was tested for this review.

Keep registration separate from provisioning state

A phone can register with an old label, button map, firmware or server URL. Use the Endpoint Manager pipeline and old-configuration diagnostic to trace MAC mapping, template, generated file, fetch and runtime without changing extension authentication first.

Trace a FreePBX phone into the loaded dynamic contact

The AMI inbound-registration diagnostic reconciles generated ownership, AoR limits, dynamic contact and endpoint relationship.

Verify generated endpoint relationships after registration

The AMI endpoint-state diagnostic compares the FreePBX owner with loaded endpoint, AoR, auth, transport and contact rows.

Trace a generated FreePBX AoR to the loaded inventory

The AMI AoR-list diagnostic checks the generator, loaded object, registrar and contact lifecycle before changing the extension.

Trace a FreePBX extension into exact PJSIP contact state

The AMI contact-state diagnostic checks the generated owner, exact contact, registration lifecycle and qualification separately.

Trace generated FreePBX credentials to loaded auth evidence

The AMI auth-list diagnostic follows the supported owner, endpoint relationship and challenge path.

Register the Edge E account without flattening the phone layout

Use the Edge E diagnostic to keep FreePBX extension state, phone key pages, module positions, radio path and completed calls separate.

Register the Edge E account without flattening keys or modules

Use the E350/E500/E550 diagnostic to keep FreePBX extension state, registrations, phone pages, modules, radio path and completed calls separate.

Register Trio C60 OpenSIP without inheriting Teams state

The Trio C60 supports up to three OpenSIP registrations, but Teams sign-in, USB audio, calendar events and completed room calls remain separate evidence.

Register the Rove base service before handset acceptance

On B4 multicell, HP documentation places voice-service registration on one primary base. Registration, handset assignment, ringing, handover and media remain separate evidence.

Verify endpoint time before interpreting certificate-dependent registration

The wrong-time diagnostic keeps phone time, trust, registration response and PBX contact state distinct.

Register GAC2570 SIP without inheriting GVC state

A GAC2570 SIP account and its Conference Control connection to a compatible GVC device are different paths. Prove the intended endpoint, contact and ordinary call independently.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.