VMware ESXi and vSphere Cluster Management

Configuring SIP Hardphones to Register with Asterisk

Learn how to connect a physical SIP desk phone to Asterisk, configure its network and account settings, verify registration, and troubleshoot calls.

A hardphone is a physical IP desk telephone that makes and receives calls through a VoIP system. It communicates with an Asterisk PBX over an IP network using SIP, the Session Initiation Protocol used to establish and manage calls.

A hardphone is different from a softphone, which is software running on a computer or mobile device. It is also different from an analog telephone, which sends analog electrical signals and normally requires an analog telephone adapter or telephony card before it can work with Asterisk.

For a phone to register successfully, a matching SIP account or endpoint must exist in two places: on the phone and on Asterisk. The phone stores an identity and password, while Asterisk stores the endpoint definition, authentication details, registration behavior, and dialplan permissions.

How a hardphone connects to Asterisk

The phone first joins the local Ethernet network and receives or is assigned an IP address. It then sends a SIP registration request to the Asterisk server, also called the SIP registrar. Asterisk authenticates the request and records the phone's current contact address.

Once registered, Asterisk knows where to send calls for that endpoint. The dialplan context assigned to the endpoint determines which extensions, services, and outbound routes the phone may use.

A typical arrangement contains the following components:

A physical SIP hardphone connected by Ethernet.
A DHCP service that supplies network settings.
An Asterisk PBX that provides SIP registration and call routing.
Optionally, a provisioning server that delivers phone configuration files.
Other extensions, such as additional hardphones or softphones.

Choose a configuration approach

Most phones can be configured through their keypad and LCD screen, through an embedded web interface, or through centralized provisioning. Menu names vary by manufacturer and firmware, but the concepts are similar.

Method	How it works	Best use case	Advantages	Limitations
Phone keypad/LCD	Enter account and network values using the physical buttons and display.	One phone when no browser or network management access is available.	Works locally; useful for initial network inspection.	Slow, difficult to repeat, and prone to typing errors.
Phone web interface	Open the phone's IP address in a browser and edit its administration pages.	Initial setup of one phone or a small number of phones.	Convenient, readable, and usually exposes all SIP fields.	Still requires manual entry and should be protected from untrusted networks.
Centralized provisioning	A provisioning server supplies vendor-specific configuration files to phones.	Repeated deployment and management of many phones.	Scalable, repeatable, and easier to standardize.	Requires templates, a provisioning service, device identifiers, and careful credential protection.

For a first single-device setup, the phone web interface is usually the most practical approach. Provisioning becomes preferable when manually configuring each device would be error-prone or when settings must be changed consistently across an organization.

Prepare the network

Connect the phone

Connect the phone's network port to a working Ethernet switch port. Some phones can receive power through Power over Ethernet (PoE); otherwise, connect the approved power adapter. Confirm that the link indicators illuminate and that the phone reaches its normal startup screen.

The phone needs IP connectivity to the Asterisk host. The phone and PBX may be on the same subnet, or routing may connect separate voice VLANs. In either case, firewalls and network access rules must permit the required SIP signaling and RTP media traffic.

Understand DHCP

DHCP is a network service that automatically supplies an IP address and related settings. A DHCP lease commonly includes:

IP address: the phone's address on the network.
Subnet mask or prefix: identifies the local network.
Default gateway: the router used to reach other networks.
DNS servers: used when the phone is configured with hostnames.

DHCP and Asterisk are separate services, even if both happen to run on the same Linux host. A phone can receive an address from one DHCP server and register with an Asterisk server elsewhere on the network.

Find the phone's IP address

Use the phone's LCD menu, often under Status, Network, or Information, to view its current IP address. Some models show the address on an information screen or provide it through a menu such as Menu > Status > Network. You can also find the phone in the DHCP server's lease list by matching its MAC address or hostname.

Before opening the web interface, confirm basic reachability:

From the administration workstation, test whether the phone's IP address responds to a suitable local network check.
Confirm the workstation is on a VLAN or routed network that can reach the phone.
Confirm that the phone can reach the Asterisk IP address.
If using an Asterisk hostname, verify that the phone's DNS setting resolves that hostname correctly.

Open and secure the phone web interface

Determine the phone's current IP address.
Open a browser on a workstation that can reach the phone.
Enter the phone IP address in the browser's address field. This connects to the phone's local administration interface, not directly to Asterisk.
Choose HTTP or HTTPS according to the phone's supported management settings. Use HTTPS where the model supports it.
Authenticate with the current administrator credentials.
Change the factory-default administrator username or password immediately after first access.

Default credentials differ by manufacturer, model, and firmware, so use the vendor's current documentation or the credentials supplied by your organization. Do not assume that one default applies to every phone.

Configure the SIP account on the phone

Sign in to the phone's administration interface and locate a page named Account, Line, SIP Account, or something similar. A typical Yealink-style interface has account tabs such as Account 1 and fields for registration and authentication.

Enable the account or line by setting Account Active to enabled.
Set the Label to a useful name shown beside the line key, such as Desk 201.
Set the Display Name to the human-readable caller identity, such as George. Whether remote phones display this value depends on the PBX and call path.
Set Register Name, Authentication Name, or the equivalent to the registration identity expected by Asterisk.
Set User Name or SIP User ID to the SIP identity used by the phone. Some vendors use this field for the extension, while others distinguish it from the authentication username.
Enter the SIP password or shared secret exactly as configured on Asterisk.
Set SIP Server, Registrar Server, or Server Host to the Asterisk hostname or IP address. Include the server port only when the phone's field requires it or when the deployment uses a non-default port.
Save or apply the settings. Allow the phone time to send a new registration request.

Field names and behavior differ by vendor. In particular, the authentication username may differ from the extension number or registration name. Match the phone's actual SIP messages and the Asterisk configuration rather than assuming all fields are interchangeable.

Phone field	Purpose	Typical Asterisk-side equivalent	Example value	Notes
Account Active	Enables the line for registration and calls.	Enabled endpoint definition	Enabled	The account cannot register while disabled.
Label	Text shown on the phone beside the line key.	Usually no direct SIP equivalent	Desk 201	Primarily a local user-interface label.
Display Name	Human-readable caller identity presented by the phone.	Caller ID or From display value	George	PBX policy may replace or modify it.
Register Name	Identity used in the registration request.	Endpoint or address-of-record identity	201	May differ from the authentication username.
User Name	SIP user identity used for calls or authentication, depending on the vendor.	Peer name, auth username, or endpoint identifier	201	Check the phone's terminology and server configuration.
Password	Secret used to authenticate the phone.	`secret` in chan_sip or an auth object in PJSIP	Use a unique secret	It must match exactly and should not be reused.
SIP Server	Address of the registrar and proxy used by the phone.	Asterisk listen address and port	pbx.example.internal	Use a reachable hostname or IP and the accepted transport.

Define the endpoint in Asterisk

Asterisk must have a corresponding endpoint or account definition before it can accept the phone's registration. Current deployments generally use PJSIP, Asterisk's newer SIP stack. Older installations may use chan_sip, the legacy SIP channel driver configured primarily through sip.conf.

Legacy chan_sip example

The following example defines extension 201 as a dynamically registering endpoint:

[201]
type=friend
context=local
allow=ulaw,alaw
secret=replace-with-a-strong-unique-secret
host=dynamic

[201] is the peer or endpoint section name. In this example, it is also the identity expected by the phone, but a deployment may use another naming convention.
type=friend is a legacy chan_sip mode that allows the section to act as a peer and user. Follow the conventions of the existing deployment and review current security guidance before adding new legacy peers.
context=local places the endpoint in the local dialplan context. That context must exist and should provide only the calling permissions the device needs.
allow=ulaw,alaw permits G.711 mu-law and A-law. Asterisk calls these codecs ulaw and alaw.
secret=... is the shared secret that must match the phone password exactly. Use a strong, unique value.
host=dynamic tells chan_sip to learn the phone's current address from registration. This is appropriate when DHCP or another mechanism may change the phone's IP address.

G.711 mu-law is common in North America and Japan, while G.711 A-law is common in many other regions. At least one codec must be permitted by both the phone and Asterisk. Codec alignment alone does not solve every audio problem, but a lack of a mutually permitted codec can prevent a call from establishing or carrying audio.

PJSIP equivalent concepts

In PJSIP, the same logical configuration is normally divided into objects rather than one chan_sip peer section:

An endpoint object describes device behavior, allowed codecs, and the dialplan context.
An auth object stores the authentication username and password.
An address-of-record (AOR) object stores the contact information created by registration.
Matching identifiers connect the phone's registration identity to the endpoint, authentication object, and AOR.

Do not copy a chan_sip section directly into a PJSIP configuration. PJSIP requires the appropriate endpoint, authentication, and AOR relationships for the Asterisk version and configuration system in use.

Purpose	chan_sip concept	PJSIP concept	Notes
Endpoint identity	Section name such as `[201]`	Endpoint object and matching identifiers	The identity must match the phone's registration behavior.
Authentication	`secret` and peer/user fields	Auth object with username and password	Phone credentials must match exactly.
Dynamic registration/contact	`host=dynamic`	AOR object and registered contact	The contact records the phone's current address.
Allowed codecs	`allow=ulaw,alaw`	Endpoint codec settings	Configure overlapping codecs on both sides.
Dialplan context	`context=local`	Endpoint context setting	Use a restricted context appropriate to the device.
Status verification	`sip show peers`	`pjsip show endpoints` and `pjsip show contacts`	Check identity, address, reachability, and contact state.

Verify registration

A successfully registered phone normally shows a status such as Registered or a green account indicator in its web interface or LCD screen. The exact wording varies by model. The status should identify the active account and should remain registered after the initial save operation.

Open the Asterisk CLI with verbose output:

asterisk -rvvv

Check a chan_sip endpoint

sip show peers

Look for the endpoint name, its current IP address and port, and a status indicating reachability or registration. A dynamic peer that has not registered may show an unknown or unreachable address instead of the phone's current contact.

Check a PJSIP endpoint

pjsip show endpoints
pjsip show contacts

The endpoint listing helps confirm that the endpoint object is loaded. The contacts listing shows registered contact addresses and their state. Useful evidence includes the expected endpoint name, the phone's current network address, reachability, and an active registration or contact state.

Test calls after registration

Call a known internal extension from the new phone.
Confirm that the receiving phone displays the expected caller ID or display name.
Speak in both directions and verify two-way audio.
Confirm that the endpoint's intended dialplan context handles the call.
Test any permitted outbound route only after the internal call works.
Reboot the phone and confirm that it registers again.
Renew its DHCP lease or allow a lease renewal, then verify that registration returns with the current address.

A successful registration does not prove that dialing rules, caller ID, codecs, or RTP media are all correct. Test signaling, dialplan behavior, and audio separately.

Troubleshoot common problems

Symptom	Likely cause	Where to check	Corrective action
Registration failed	Wrong server address or port, mismatched identity or password, missing endpoint, blocked traffic, DNS failure, or unsupported SIP transport.	Phone account page, Asterisk endpoint configuration, DNS, firewall, VLAN, and SIP status.	Compare every account field, confirm address resolution and transport, and inspect Asterisk logs or status output.
Phone cannot reach the web interface	No DHCP lease, unexpected IP address, unreachable management network, disabled web service, or wrong HTTP/HTTPS choice.	Phone network screen, DHCP lease list, workstation routing, and phone management settings.	Find the current address, confirm reachability, use the vendor-supported protocol and port, and review VLAN and routing rules.
PBX sees endpoint as unreachable	The phone is offline, the contact is stale, the endpoint is not using dynamic registration, or network filtering blocks traffic.	`sip show peers`, `pjsip show contacts`, phone status, and network firewall.	Confirm power and link, use `host=dynamic` for the legacy example, save the phone settings, and check filtering.
Call connects with no audio	No common codec, blocked RTP ports, incorrect NAT settings, or incomplete routing between phone and PBX networks.	Phone codec settings, Asterisk codec policy, RTP firewall rules, NAT settings, and network routes.	Permit a common codec such as `ulaw` or `alaw`, review RTP access, check NAT, and test locally.
Phone registers but cannot dial expected numbers	Wrong dialplan context, missing extensions, or intentionally restricted outbound permissions.	Endpoint context, dialplan rules, and Asterisk call logs.	Review the context, verify the relevant dialplan rules, and make a controlled internal test call.

Registration failure checklist

Confirm the phone is actually using the intended Asterisk address rather than an old server address.
Compare the register name, user name, authentication username, and password with the server-side values.
Confirm the endpoint exists and is loaded by Asterisk.
For chan_sip, confirm dynamic phones use host=dynamic.
Check whether the phone uses UDP, TCP, or TLS and whether Asterisk accepts that transport.
Check routing, DNS, VLAN rules, and firewalls between the phone and PBX.
Save or apply the phone configuration and restart it if the firmware requires a restart before registration.

Security and operational practices

Use a strong, unique SIP secret for every endpoint.
Remove or change factory-default administrator credentials immediately.
Restrict SIP endpoint access to trusted network addresses or voice VLANs where practical.
Do not place the phone's administrator interface or SIP service directly on the public internet.
Use HTTPS for phone administration where supported.
Keep phone firmware current according to the manufacturer's guidance.
Use secure signaling and media options, such as TLS and SRTP, when the phone, Asterisk version, and deployment design support them.
For larger deployments, use centralized provisioning rather than manually entering every account.
Protect provisioning credentials and configuration files because they may contain SIP passwords.
Keep per-device credentials separate from common settings such as time servers, codec policy, and directory configuration.

Move from manual setup to provisioning

Provisioning is the automated delivery of phone settings, usually through vendor-specific configuration files served by a provisioning server. A phone can be directed to that service through its own provisioning settings or, where supported, DHCP options.

Manual entry is reasonable for one phone, but it becomes difficult to audit and repeat across many devices. A scalable process generally uses:

A common template for network-independent settings.
A per-device template or variable set containing the endpoint identity and unique SIP secret.
A provisioning server reachable from the voice network.
Device identifiers such as MAC addresses to select the correct configuration.
Protected configuration files and controlled administrator access.
A test process that verifies registration and calls after provisioning.

Provisioning improves consistency and repeatability, but it does not remove the need to secure the server or validate vendor-specific file formats.

Configuration workflow summary

Create the endpoint and authentication details in Asterisk using chan_sip or, preferably, PJSIP.
Assign a restricted dialplan context and compatible codecs.
Connect the hardphone and confirm Ethernet, power, and DHCP operation.
Find the phone's current IP address.
Open the phone's web interface from a trusted workstation and change default administrator credentials.
Enable an account or line and enter the label, display name, registration identity, authentication values, and SIP server.
Save the settings and wait for the phone to report registration.
Verify the endpoint from the Asterisk CLI.
Make an internal test call, verify caller ID and two-way audio, and test re-registration after reboot or lease renewal.

For related material, continue with SIP hardphone configuration as a reference point for endpoint setup and operational checks.