Asterisk course

Register SIP Phones to an Asterisk Server

Learn how to configure Ekiga as a SIP endpoint, register it with Asterisk, verify peers from the CLI, and prepare the dialplan for calls.

A SIP phone or softphone must register with Asterisk before the PBX can normally reach it. This lesson uses Ekiga as the client and the legacy chan_sip configuration model as the server-side example.

Registration is only one part of a working phone system. It tells Asterisk where an endpoint is currently located, but the dialplan must separately define what happens when a user dials a number.

What SIP registration does

SIP, or Session Initiation Protocol, is used for signaling tasks such as registering an endpoint and starting a call. A SIP phone can be a hardware device or an application. A softphone is a SIP phone implemented in software on a computer or mobile device.

During registration, the endpoint authenticates to Asterisk and reports a current contact address. This address usually contains an IP address and port where Asterisk can send signaling. Asterisk stores the contact temporarily, until the registration expires or the endpoint registers again.

• Endpoint identity: The account name that identifies the phone, such as bob.
• Credentials: The authentication username and secret used to prove that the endpoint may use the account.
• Contact address: The current network address supplied by the phone.
• Registration state: Whether Asterisk currently has a valid contact for that account.

The SIP server accepting registrations is called the registrar. In this setup, Asterisk is the registrar. A successful registration means that Asterisk knows how to attempt to reach the endpoint; it does not automatically create an extension, a calling permission, or a route to another phone.

Prerequisites

Before configuring Ekiga, confirm the following:

• Asterisk is installed, running, and reachable from the computer running Ekiga.
• A SIP account or peer already exists in the Asterisk SIP configuration.
• You know the Asterisk server's IP address or hostname.
• You know the SIP extension or account name, authentication username, and password.
• Ekiga is installed and started. See Install Ekiga on Ubuntu if needed.
• Network connectivity and firewall rules permit SIP signaling and the media traffic negotiated for calls.

You should also understand basic IP addresses, hostnames, terminal commands, Asterisk configuration files, and the Asterisk architecture. Registration may work while audio fails if media ports, NAT, or firewalls are configured incorrectly.

Define SIP accounts in Asterisk

In the legacy chan_sip model, SIP peers are stored in sip.conf. A peer is a configured SIP endpoint or remote SIP entity known to Asterisk. The bracketed section name is the account identifier. For a basic setup, that name is entered as the phone's SIP username.

For example, two independently authenticated accounts might look like this:

[bob]
type=friend
host=dynamic
secret=<strong-unique-bob-password>
context=<internal-context>

[alice]
type=friend
host=dynamic
secret=<strong-unique-alice-password>
context=<internal-context>

These are configuration patterns, not passwords to copy. Replace the placeholders with strong, unique secrets and an actual dialplan context.

• type=friend is a legacy chan_sip peer behavior that permits the account to be used for both matching and making calls in common configurations.
• host=dynamic tells Asterisk that the endpoint's network address is supplied when it registers. This is appropriate for phones whose address can change, such as clients using DHCP.
• secret is the SIP password. The same value must be entered in the client.
• context assigns the peer to a dialplan context. That context controls which call-routing rules the endpoint can access.
• Codec settings can also be specified where required by the deployment. Both sides must have a compatible codec for media negotiation.

After editing sip.conf, reload chan_sip where supported:

sip reload

That command is entered at the Asterisk CLI, not at the ordinary Linux shell. Configuration changes should be checked carefully, especially when the server is handling active calls.

Configure an Ekiga SIP account

Use the following workflow for the bob account. Menu wording can vary slightly between Ekiga releases.

1. Launch Ekiga. Use ordinary desktop privileges unless your environment specifically requires otherwise. An elevated command such as sudo ekiga should not be the normal choice.
2. Open the account management interface through Edit, then Accounts.
3. Choose the action to add a SIP account.
4. Enter the Asterisk server address and the account credentials.
5. Save or enable the account, then wait for Ekiga to display a registered state.

The User field identifies the SIP account. The Authentication user is the identity used during the authentication exchange. In a simple Asterisk configuration, both are bob. They can differ in more advanced environments, so use the values supplied by the administrator.

The registration timeout, also called the expiry, is the period for which the server treats the contact as valid. Before it expires, Ekiga normally sends another registration. Retaining a reasonable default is suitable for a basic LAN setup.

After saving the account, look for a visual status such as Registered, an enabled account indicator, or a green status icon. A disabled, offline, or failed status means the client has not completed registration.

Verify registration from the Asterisk CLI

Attach to a running Asterisk instance from a system terminal:

asterisk -rvvv

The Asterisk CLI is the interactive console used to inspect status and administer Asterisk. At the Asterisk prompt, list chan_sip peers:

sip show peers

Find bob in the results. The exact columns vary by Asterisk version, but useful information commonly includes:

• The peer name, such as bob.
• The current address or contact recorded by Asterisk.
• The SIP port, commonly a UDP port selected by the endpoint.
• Reachability or qualify information.
• A status indicating whether the peer is reachable, registered, or unavailable.

A configured peer with no current address often means that it has not registered, its registration expired, or Asterisk could not use the supplied contact. A peer marked unavailable may also indicate a firewall, NAT, or network path problem.

To test a second endpoint, configure another Ekiga installation or another SIP client with:

• Registrar: the same Asterisk address.
• User: alice.
• Authentication user: alice for the basic example.
• Password: the secret configured in the [alice] section.

When both clients have registered, run sip show peers again. The server-side list should contain both alice and bob, each with a current contact and an acceptable status.

Registration does not create calling rules

Two phones can both be registered and still be unable to call one another. Registration provides endpoint authentication and current reachability. The dialplan provides call-routing logic: it matches what a user dials and selects the actions Asterisk should perform.

Each SIP account has a context. A context is a named section of the dialplan that determines which rules the endpoint may use. The context must contain appropriate extensions or route to a context that does.

The next configuration step is therefore to create dialplan extensions for the numbers users will dial and route those destinations to the corresponding SIP endpoints. For example, an administrator might choose numeric extensions such as 601 for Bob and 602 for Alice, then create rules that call the bob and alice SIP channels. The account names and dialable numbers do not have to be identical, but the mapping must be explicit.

After adding or changing dialplan rules, apply the dialplan configuration, then place a test call while watching the Asterisk CLI. Learn more about contexts, extensions, and what a dialplan is.

Registration verification checklist

Troubleshoot registration failures

Ekiga never shows Registered

• Verify the registrar hostname or IP address and test basic connectivity.
• Confirm that Asterisk is running and listening for SIP signaling.
• Compare the User, Authentication user, and password with the peer definition.
• Confirm that the peer permits dynamic registration and that the configuration was loaded.
• Check firewall and NAT behavior. A signaling request may reach the server while the response is blocked.
• Watch the Asterisk CLI while attempting registration; authentication and address errors often appear there.

The peer has no contact or is unreachable

• Restart or re-register the softphone in case its registration expired.
• Review the address, port, and status shown by sip show peers.
• Check whether the endpoint is behind NAT and whether the recorded contact is usable from the server.
• Confirm that the client registered to the intended server and account.
• Use SIP debugging cautiously and only in a controlled environment, because verbose signaling output can expose credentials or private network details.

Both phones register but calls fail

• Confirm registration first; a dialplan problem is different from an authentication problem.
• Check that each account's context contains or can reach the intended dialplan rules.
• Verify that the dialed string matches an extension or pattern.
• Confirm that the route sends the call to the intended SIP endpoint.
• Reload the dialplan after changes and monitor the CLI during a test call.

Authentication repeatedly fails

• Re-enter the password exactly as configured.
• Verify whether the authentication username differs from the displayed SIP user.
• Disable or remove stale duplicate accounts in the client.
• Confirm that the requested account section exists on Asterisk.
• Replace potentially exposed credentials with a newly generated strong secret.

Security and deployment practices

• Use long, random, unique SIP secrets for every endpoint. Do not use simple tutorial passwords in production.
• Never reuse one SIP credential across multiple phones. Separate credentials make revocation and auditing possible.
• Avoid exposing unauthenticated SIP services directly to the public internet.
• Restrict permitted source networks with appropriate access controls where possible.
• Protect the Asterisk management interface and limit administrative access.
• Use TLS for SIP signaling and secure RTP for media when supported and required by the deployment.
• Review NAT, firewall, codec, and media-port settings as a complete design rather than assuming that successful registration proves audio will work.

Key points

1. Registration authenticates a SIP endpoint and gives Asterisk its current contact address.
2. The peer name, credentials, contact, and registration state describe different parts of the endpoint relationship.
3. In the legacy chan_sip model, accounts are commonly defined in sip.conf with settings such as host=dynamic, secret, and context.
4. Ekiga's registrar is the Asterisk server address; User and Authentication user commonly match the peer name in a basic setup.
5. asterisk -rvvv opens the CLI, and sip show peers displays chan_sip peer status.
6. Registered phones still require dialplan rules before users can place calls between them.
7. Strong credentials, network restrictions, protected management access, and encrypted signaling and media are important deployment safeguards.