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 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.
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!).
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.
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.
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.
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()
Get Asterisk: The Future of Telephony now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.