Analog telephony

The first telephone networks were all analog. The audio signal that you generated with your voice was used to generate an electrical signal, which was carried to the other end. The electrical signal had the same characteristics as the sound being produced.

Analog circuits have several characteristics that differentiate them from other circuits you might wish to connect to Asterisk:

• No signaling channel exists—line state signaling is electromechanical, and addressing is done using in-band audio tones.

• Disconnect supervision is usually delayed by several seconds, and is not completely reliable.

• Far-end supervision is minimal (for example, answer supervision is lacking).

• Differences in circuits mean that audio characteristics will vary from circuit to circuit and will require tuning.

Incoming analog circuits that you wish to connect to your Asterisk system will need to connect to a Foreign eXchange Office (FXO) port. Since there is no such thing as an FXO port in any standard computer, an FXO port of some sort must be provided to the system before you can connect traditional analog lines. Companies such as Digium and Sangoma offer such cards, but you can also purchase a SIP device that provides such ports.

We do not recommend the use of analog trunks in an Asterisk system. Their configuration and use is outside of the scope of this book.⁴

Endpoints behind NAT

If your telephone sets are behind a remote NAT, there may be options in the ps_endpoints table of your database that should be adjusted from the default settings. You will need to experiment with changing the following values between 'yes' and 'no'. There may be many different combinations possible.

MySQL> update ps_endpoints set rtp_symmetric='yes',force_rport='yes',rewrite_contact='yes' 

Other parameters you may wish to look at include media_address and direct_media.

Keep in mind the defaults when you are making changes. If in doubt, set the value of a field you’ve changed to NULL, as that will effectively set it back to the default.

Asterisk behind NAT

First up, we need to tell you that putting your PBX behind a NAT is not recommended. It’s far better to ensure it is firewalled without a NAT layer (especially if you have endpoints that are not on the same network as the PBX).

If you are stuck working with a PBX behind a NAT, you will need to work with your network team to ensure that the NAT components of the network are being correctly handled by your NAT device (typically your firewall). If they do not have sufficient skill in this regard, you may require the services of an outside consultant who is skilled in NAT traversal for SIP/RTP traffic. As we said, having your PBX behind NAT is not recommended.

Typically, the endpoints will also be behind NAT, and thus you will have a double-NAT scenario, which is likely to require a few hours of wrangling with various settings, not only in Asterisk but also in the firewall, in order to achieve success. Remember that it is vital that you test audio in both directions; it’s not enough to simply verify that calls can be dialed and answered.

In a scenario where there is no choice but to use a double-NAT, we would recommend finding out whether a VPN can be used between the PBX and the remote endpoints. In many cases this will end up being easier to configure.

We wish we could say there’s a simple, reliable way to ensure NAT works in all cases, but unfortunately there is not.

You could also look into using NAT assisting technologies such as STUN, TURN, and ICE. The details of these are beyond the scope of this book, since they require external servers, but many folks have had success with those protocols where other methods failed.

PSTN termination

Until VoIP totally replaces the PSTN, there will be a need to connect calls from VoIP networks to the public telephone network. This process is referred to as termination (Figure 7-4).

Figure 7-4. PSTN termination

Although you can engineer an Asterisk system to act as a termination gateway (using some sort of PSTN interfaces), in practice you’re more likely to use an Internet Telephony Service Provider (ITSP, also sometimes called a VoIP carrier) to terminate your phone calls. ITSPs typically have a massive investment in infrastructure, and you’d be hard-pressed to do better without spending a ton of money. ITSPs have made termination inexpensive, so it’s tough to make a business case for doing it yourself.

In order to send your calls to an ITSP, your dialplan needs to look something like this:

; NANP-based systems
[to-pstn] ; Yes, we're going through an ITSP, but the PSTN is our destination
exten => _1NXXNXXXXXX.,1,Dial(${TOLL}/${EXTEN})  ; Country code plus phone number

; Add a '1' and send
exten => _NXXNXXXXXX.,1,Dial(${LOCAL}/1${EXTEN}) ; Country code plus phone number 

; Strip off the '011' and send
exten => _011X.,1,Dial(${TOLL}/${EXTEN:3})       ; Country code plus phone number

; Emergency dialing
exten => 911,1,Dial(${LOCAL}/911) ; Defining this will require info from your carrier

; Most of the rest of the world
[to-pstn]
; Strip off NDD prefix, add country code, and send 
exten => _0X.,1,Dial(${TOLL}/<add your country code here>${EXTEN:1})  

; Strip off IDD prefix and send 
exten => _00X,1,Dial(${LOCAL}/${EXTEN:2}) ; Country code plus phone number 

; Emergency dialing (and other services)
exten => 11X,1,Dial(${LOCAL}/${EXTEN}) ; Defining this will require info from your carrier

Termination will tend to be more complex than we’ve outlined here—even if you’re using an ITSP as your carrier—but the basic concept is fairly straightforward: match a pattern that your users might dial, prepare it for the carrier by removing or adding necessary digits, and send the call out the appropriate PJSIP endpoint (trunk). We’ve only discussed the dialplan here; in a later section we’ll discuss how to configure the SIP trunks to carry this traffic.

PSTN origination

You might also want to be able to accept calls from the PSTN into your VoIP network. The process of doing this is commonly referred to as origination. This simply means that the call originated in the PSTN (Figure 7-5).

Figure 7-5. PSTN origination

In order to provide origination, a phone number is required.

In the good old days, when VoIP and Asterisk were new, it was quite common for people to handle the circuit connection to the PSTN themselves, using analog or digital trunks provided by the local phone company. For the most part this type of connection is now handled by ITSPs, and you simply need to connect your system to your VoIP carrier across a SIP trunk.

Phone numbers—when used for the purpose of origination—are commonly called DIDs (Direct Inward Dialing numbers). Your carrier will send a call down the circuit to your system, and pass the DID (or special received digits in some cases¹⁴), which the Asterisk dialplan will interpret. In other words, you will need a dialplan context that accepts incoming calls from your carrier, with extensions or patterns that will correlate to your DIDs.

In order to accept a call from a VoIP circuit, you will need to handle the digits the carrier will send you (the DID or phone number). The DNIS number and the DID do not have to match, but typically they will. In days gone by, the carrier would usually ask you in what format you wish to receive the digits. Nowadays, a VoIP carrier will typically tell you what format they will send, and you are expected to accommodate. Two common formats are: DNIS (which is essentially the digits of the DID that was called) or E.164, which means that they’ll be including the country code with the number.

In the dialplan, you associate the incoming circuit with a context that will know how to handle the incoming digits. As an example, it could look something like this:

[from-pstn] 

exten => 4165550100,1,Goto(sets,100,1)
exten => 4165550101,1,Goto(sets,101,1)
exten => 4165550102,1,Goto(sets,102,1)
exten => 4165550103,1,Goto(sets,103,1)
exten => 4165554321,1,Goto(main-menu,${EXTEN},1)
exten => 4165559876,1,VoiceMailMain() ; a handy back door for listening
                                      ; to voice messages

exten => i,1,Verbose(2,Incoming call to invalid number)

In the number-mapping context, you explicitly list all of the DIDs that you expect to handle, plus an invalid handler for any DIDs that are not listed (you could send invalid numbers to reception, or to an automated attendant, or to some context that plays an invalid prompt).

Now we’re ready to discuss how to configure trunks to carry your external traffic.

Connecting an Asterisk system to a SIP provider

It is quite common to use the same ITSP carrier for termination and origination, but be aware that the two processes are unrelated to each other. If calls going in one direction pass your testing, that doesn’t mean calls in the other direction are OK. If you change configuration, test routing both in and out, every time.

Many carriers will provide sample configurations for Asterisk. Unfortunately, these documents generally refer to the older chan_sip driver, which has been deprecated. Digium has designed a PJSIP wizard that is intended to greatly simplify carrier configuration. You can still configure ITSP trunks using the exact same methods we’ve shown before for configuring other endpoints (creating records in ps_endpoint, ps_aors, ps_auths, and so forth), but rather than hash over all that again, we are going to take a look at the wizard, since it consolidates several components into a single configuration file. We have found that since user endpoints change often, and carrier endpoints seldom do, it’s often useful to configure carriers in a configuration file rather than in the database.

Before any config can be created, however, it’s important to determine how the carrier will interact with your system. There are two fundamental models we have seen:

Password-based authentication, including registration¹⁵

This is common in smaller carriers focused on the small-business market. This is also the type of service you would get if you were simply registering a SIP phone directly to a service.

IP-based authentication

No password; no registration. This is more common with carriers that provide bulk trunking services to larger enterprises and resellers. (Typically these will also come with some sort of minimum commitment in terms of volume.) You will be expected to have solid SIP and networking skills.

These are not hard-and-fast rules, but they are the most common in our experience.

So there are two ways we might configure an ITSP in the /etc/asterisk/pjsip_wizard.conf file.

First, if the carrier uses an IP address–based authentication, they will expect you to send your traffic from a static IP address (and should your address change, you will need to inform them so they can reconfigure their equipment). Your pjsip_wizard.conf file could then look something like this:

; ITSP uses IP address-based authentication
[itsp-no-auth]
type=wizard
remote_hosts=itsp.example.com
endpoint/context=pstn-in 
endpoint/allow = !all,ulaw,g722
sends_registrations=no
accepts_registrations=no
sends_auth=no
accepts_auth=no

Alternatively, if your IP address changes frequently (or your carrier requires this method), you can have your system register to the carrier (which will require you to send authentication credentials to prove it’s really you). Your calls will typically also be required to authenticate:

[itsp-with-auth]
type=wizard
remote_hosts=itsp.example.com
endpoint/context=pstn-in
endpoint/allow = !all,ulaw,g722
sends_registration=yes
accepts_registrations=no
sends_auth=yes
accepts_auth=no
outbound_auth/username=itsp_provided_username
outbound_auth/password= itsp_provided_password

Note that the names [itsp-no-auth] and [itsp-with-auth] have no built-in meaning to Asterisk. They become the PJSIP channel names to which you send your calls.

[globals]
UserA_DeskPhone=PJSIP/0000f30A0A01
UserA_SoftPhone=PJSIP/SOFTPHONE_A
UserB_DeskPhone=PJSIP/0000f30B0B02
UserB_SoftPhone=PJSIP/SOFTPHONE_B

TOLL=PJSIP/itsp-no-auth
LOCAL=${TOLL}
;OR
;TOLL=PJSIP/itsp-with-auth
;LOCAL=${TOLL}

TOLL=PJSIP/itsp-no-auth
LOCAL=${TOLL}
;OR
;TOLL=PJSIP/itsp-with-auth
;LOCAL=${TOLL}

[pstn-in]
exten => 4169671111,1,Dial(sets,100,1)
exten => 4167363636,1,Dial(sets,101,1)

[sets]
exten => 100,1,Dial(${UserA_DeskPhone})