Asterisk: The Future of Telephony

Configuring SIP

The Session Initiation Protocol (SIP), often used in VoIP phones (either hard phones or soft phones), takes care of the setup and teardown of calls, along with any renegotiations during a call. Basically, it helps two endpoints talk to each other (if possible, directly to each other). SIP does not carry media; rather, it uses the Real-time Transport Protocol (RTP) to transfer the media^[34] directly between phone A and phone B once the call has been set up.

SIP and RTP

SIP is an application-layer signaling protocol that uses the well-known port 5060 for communications. SIP can be transported with either the UDP or TCP transport-layer protocols. Asterisk does not currently have a TCP implementation for transporting SIP messages, but it is possible that future versions may support it (and patches to the code base are gladly accepted). SIP is used to “establish, modify, and terminate multimedia sessions such as Internet telephony calls.”^[35] SIP does not transport media between endpoints.

RTP is used to transmit media (i.e., voice) between endpoints. RTP uses high-numbered, unprivileged ports in Asterisk (10,000 through 20,000, by default).

A common topology to illustrate SIP and RTP, commonly referred to as the “SIP trapezoid,” is shown in Figure 4-2. When Alice wants to call Bob, Alice’s phone contacts her proxy server, and the proxy tries to find Bob (often connecting through his proxy). Once the phones have started the call, they communicate directly with each other (if possible), so that the data doesn’t have to tie up the resources of the proxy.

Figure 4-2. The SIP trapezoid

SIP was not the first, and is not the only, VoIP protocol in use today (others include H.323, MGCP, IAX, and so on), but currently it seems to have the most momentum with hardware vendors. The advantages of the SIP protocol lie in its wide acceptance and architectural flexibility (and, we used to say, simplicity!).

SIP Configuration

Here is a basic sip.conf file:

    [general]
    context=default
    srvlookup=yes

    [john]
    type=friend
    secret=welcome
    qualify=yes                     ; Qualify peer is no more than 2000 ms away
    nat=no                          ; This phone is not natted
    host=dynamic                    ; This device registers with us
    canreinvite=no                  ; Asterisk by default tries to redirect
    context=internal                ; the internal context controls what we can do

The sip.conf file starts with a [general] section, which contains the channel settings and default options for all users and peers defined within sip.conf. You can override the default settings on a per-user/peer basis by configuring them within the user/peer definition.

Domain Name System Service records (DNS SRV records) are a way of setting up a logical, resolvable address where you can be reached. This allows calls to be forwarded to different locations without the need to change the logical address. By using SRV records, you gain many of the advantages of DNS, whereas disabling them breaks the SIP RFC and removes the ability to place SIP calls based on domain names. (Note that if multiple records are returned, Asterisk will use only the first.) DNS SRV record lookups are disabled by default in Asterisk, but it’s highly recommended that you turn them on. To enable them, set srvlookup=yes in the [general] section of sip.conf.

Each connection is defined as a user, peer, or friend. A user type is used to authenticate incoming calls, a peer type is used for outgoing calls, and a friend type is used for both. The extension name is defined within square brackets ([]). In this case, we have defined the extension john as a friend.

A secret is a password used for authentication. Our secret is defined as welcome. We can monitor the latency between our Asterisk server and the phone with qualify=yes, thereby determining whether the remote device is reachable. qualify=yes can be used to monitor any end device, including other Asterisk servers. By default, Asterisk will consider an extension reachable if the latency is less than 2,000 ms (2 seconds). You can configure the time Asterisk should use when determining whether or not a peer is reachable by replacing yes with the number of milliseconds.

If an extension is behind a device performing Network Address Translation (NAT), such as a router or firewall, configure nat=yes to force Asterisk to ignore the contact information for the extension and use the address from which the packets are being received. Setting host=dynamic will require the extension to register so that Asterisk knows how to reach the phone. To limit an endpoint to a single IP address or fully qualified domain name (FQDN) , replace dynamic with the IP address or domain name. Note that this limits only where you place calls to, as the user is allowed to place calls from anywhere (assuming she has authenticated successfully). If you set host=static, the end device is not required to register.

We’ve also set canreinvite=no. In SIP, invites are used to set up calls and to redirect media. Any invite issued after the initial invite in the same dialog is referred to as a reinvite. For example, suppose two parties are exchanging media traffic. If one client goes on hold and Asterisk is configured to play Music on Hold (MoH), Asterisk will issue a reinvite to the secondary client, telling it to redirect its media stream toward the PBX. Asterisk is then able to stream music or an announcement to the on-hold client.

The primary client then issues an off-hold command in a reinvite to the PBX, which in turn issues a reinvite to the secondary party requesting that it redirect its media stream toward the primary party, thereby ending the on-hold music and reconnecting the clients.

Normally, when two endpoints set up a call they pass their media directly from one to the other. Asterisk generally breaks this rule by staying within the media path, allowing it to listen for digits dialed on the phone’s keypad. This is necessary because if Asterisk cannot determine the call length, inaccurate billing can occur. Configuring canreinvite=no forces Asterisk to stay in the media path, not allowing RTP messages to be exchanged directly between the endpoints.

Asterisk will not issue a reinvite in any of the following situations:

• If either of the clients is configured with canreinvite=no

• If the clients cannot agree on a common set of codecs and Asterisk needs to perform codec conversion

• If either of the clients is configured with nat=yes

• If Asterisk needs to listen to Dual Tone Multi-Frequency (DTMF) tones during the call (for transfers or any other features)

Lastly, context=internal specifies the location of the instructions used to control what the phone is allowed to do, and what to do with incoming calls for this extension. The context name configured in sip.conf matches the name of the context in extensions.conf, which contains the instructions. More information about contexts and dialplans will be presented in the following chapter.

If you are configuring a number of clients with similar configurations, you can place like commands under the [general] heading. Asterisk will use the defaults specified in the [general] section unless they are explicitly changed within a client’s configuration block.

Client Configuration

While it would be impossible to show all the possible configurations for all the end devices that can communicate with Asterisk, we feel it beneficial to provide the configuration for at least one free soft phone, which you can use in determining if Asterisk is right for your organization. We’ve chosen to use X-ten’s X-Lite client , which you can download from their web site (http://www.xten.com).

The configuration of the client is generally straightforward. The most important parts are the username and password for registration, plus the address of the Asterisk server with which you wish to register. Figure 4-3 shows a sample configuration for the X-Lite client. Be sure to modify the values of the fields to reflect your configuration.

Figure 4-3. X-Lite soft phone configuration screen

The display name is the string that will be used for Caller ID. The username and authorization user are used for authentication, along with the password. The domain/realm should be the IP address or FQDN of your Asterisk server. The SIP proxy is the same as the one entered for the domain/realm, but with :5060 appended (this specifies the port number to use for SIP signaling—be sure it matches the port you have configured in sip.conf).

After entering all this information, verify that Enabled is set to Yes, and then close the configuration menu. X-Lite will then register to Asterisk. If X-Lite doesn’t appear to register, simply restart the client. Because X-Lite is minimized to the task tray when you close the application with the X button, you will need to exit the program by right-clicking on the icon in the tray and then clicking “Exit” in the pop-up menu before restarting.

Dialplan Configuration

Many SIP phones, both soft and hard, are multi-line phones. This means they can accept multiple incoming calls at the same time. Thus, to test your X-Lite soft phone you can simply call yourself, and the call will loop back from the Asterisk server and onto line two of the client. To call yourself, dial extension 100. If your preferred client doesn’t support multi-line functionality, you can use extension 611 to enter the Echo() test application.

    [internal]
    exten => 100,1,Dial(SIP/john)
    exten => 611,1,Echo()

---

^[34] We use the term media to refer to the data transferred between endpoints and used to reconstruct your voice at the other end. It may also refer to music or prompts from the PBX.

^[35] RFC 3261, SIP: Session Initiation Protocol, p. 9, Section 2.