Outside Connectivity(Asterisk) II


Compared to the vast history of telecom, VoIP is still a relatively new concept. For the century or so prior to VoIP, the only way to connect your site to the PSTN was through the use of circuits provided for that purpose by your local telephone company. VoIP now allows for connections between endpoints without the PSTN having to be involved at all (although in most VoIP scenarios, there will still be a PSTN component at some point, especially if there is a traditional E.164 phone number involved).

Coping with Network Address Translation

If you are going to be using VoIP across any sort of wide-area network (such as the Internet), you will be dealing with firewalls and network address translation (NAT). 11 A basic understanding of how the SIP and RTP protocols work together to create a VoIP call can be helpful in understanding and debugging functional problems (such as the very common “one-way audio” issue, which NAT configuration issues will often create). NAT allows a single external IP address to be shared by multiple devices behind a router.

Since NAT is typically handled in the firewall, it also forms part of the security layer between a private network and the Internet.

A VoIP call using SIP doesn’t consist just of the signaling messages to set up the call (the SIP part of the connection). It also requires the RTP streams (the media), which carry the actual audio connection, as shown in Figure


The use of separate protocols to carry the audio is what can make NAT traversal troublesome for VoIP connections, especially if the remote phones are behind one NAT, and the PBX is behind a different NAT. The problem is caused by the fact that while the SIP
signaling will typically be allowed to pass through the firewalls at both ends, the RTP streams may not be recognized as part of the SIP session taking place, and thus will be ignored or blocked, as shown in Figure. The effect of one or both of the RTP streams
being blocked is that users will complain that they are seeing their calls happen, and can nswer them, but cannot hear (or cannot be heard).


In this section we will discuss some of the methods you may employ to alleviate issues caused by NAT. There are two different scenarios that need to be considered; each requiring you to define parameters within the sip.conf file. As long as you understand
which scenario you are dealing with, 13 most NAT issues become a thing of the past.

Devices behind NAT

First, let’s deal with devices behind a remote NAT connecting to your Asterisk box, as shown in Figure


When a device attempts to initiate a session, it will construct a SIP message that contains its IP address and some additional information. When Asterisk sees this information, it uses it to determine where to respond to. Since the device is behind NAT, the SIP message will have a reply address that is not routable (e.g., However, we can tell Asterisk to ignore this SIP message address, and instead use what is supplied by he network stack. We enable this via the nat option in sip.conf.

lists the arguments we can set with the nat option.


RFC 3581 allows a device to use the rport parameter to signal to the far end that it should respond to the source IP and port the request originated from, rather than using the address supplied in the SIP header. Supplying the rport parameter can happen when
the device knows it is behind a NAT and can’t write the information that would be required to communicate bidirectionally in the SIP header. Asterisk will always honor the rport parameter if it is supplied, but since this isn’t as common as one would like,
we can force Asterisk to assume that the device would have supplied an rport parameter if it had known better. By doing this, we instruct Asterisk to always respond to the source IP and port from which it received the request. If no nat setting is explicitly defined, Asterisk will default to auto_force_rport as the nat parameter setting. You can force this behavior by setting nat=force_rport.

The comedia (connection-oriented media) option can be used to instruct Asterisk to send media (RTP) to the address and port that the far-end media came from. This is used when a device is behind NAT and can’t tell Asterisk the correct location to send media to.

You can also specify multiple options to the nat setting by separating arguments with a comma. For example, it is common to set both force_rport and comedia as the NAT handling method (which is what we recommend you start with):


Another trick when dealing with devices behind NAT is to enable the qualify option. In many NAT systems, if a dialog isn’t maintained periodically, then the device providing the NAT may close the connection. By using qualify, Asterisk will send a request to the far end, which should then be responded to. By default, if you use qualify=yes on a peer, then the time for these transactions is every 2,000 milliseconds (2 seconds). You can also specify the time in milliseconds instead of using yes :

qualifyfreq=60 ; probe far end peer every 60 seconds
qualify=120000 ; allow 10 seconds for a reply (qualify)

Important Point=

****************** Keeping a Remote Firewall Open ********************

Sometimes a problem with a SIP telephone will surface wherein the phone will register and function when it is first booted, but then it will suddenly become unreachable. What is often happening here is that the remote firewall, seeing no activity coming from the
set, will close the external connection to the telephone, and thus the PBX will lose the ability to send to the set. The effect is that if the PBX tries to send a call to the phone, it will fail to connect (the remote firewall will reject the connection). If, on the other hand,
the user makes a call out, for a few minutes the set will again be able to accept incoming calls. Naturally this can cause a lot of confusion for the users.

A relatively simple solution to this problem 14 involves setting the registration timer on the remote phone to a low enough value that it will stimulate the connection every minute or so, and thus convince the firewall that this connection can be allowed to exist
for a little while longer. It’s a bit of a hack, but it has proven successful. The challenge with proposing a universal solution is that there are many different models of firewalls, from inexpensive consumer-grade units to complex session border controllers, and this
is one of the few solutions that seems to address the problem reliably in almost all cases.

This approach is best on smaller systems (fewer than 100 telephones). A larger system with hundreds or thousands of phones will not be well served by this solution, as there will be an increased load on the system due to a near-constant flood of registrations
from remote phones. In such a case, some more careful thought will need to be given to the overall design (for example, a dedicated registrar server could be used in place of Asterisk to handle the registration traffic).

In a perfect world, you would be able to specify a particular model of firewall, and devise a configuration for those firewalls that would ensure your SIP traffic was properly han‐ dled. In reality, you will come up against not just different models of firewall, but even different firmware versions for the same model firewall.


Asterisk behind NAT

The second scenario is that Asterisk is behind NAT, as illustrated in Figure.


In this case, we have a couple of ways to write the SIP headers in a manner friendly to the other end.

There are two primary options when Asterisk is behind NAT: externip and extern host . Use of these options is a one-or-the-other decision, since they effectively perform the same functionality: compose the SIP header using the external interface address.
Since our Asterisk box will have a nonroutable IP address across the Internet (we’re behind NAT), we can tell Asterisk what its external routable address is, so that we can place that in the headers of our SIP message.

If our external IP address was something like, we could set externip like so:


We can also specify the port number that should be responded to:


If no port number is provided, then the port number specified with the udpbindaddr option will be used.

Alternatively, you can use the externhost option, which is similar to the externip , but the IP address will be resolved whenever chan_sip.so is loaded into memory (or on subsequent reloads).  The format is similar to externip except you use a hostname. You
can also specify a port number. For example:

If you want the external hostname to be refreshed periodically, you can use the externrefresh option. The value specified is in seconds:


If you have deployed your Asterisk server behind NAT, it is likely that you will also have local telephone sets attached to it. We don’t want to mangle the headers of SIP messages we’re sending to our local sets, so we can specify which IP addresses are considered part of our local network. That way Asterisk will respond simply with the headers as they would be on an internal network. We use the localnet option to specify which networks are considered local to our Asterisk system.

The localnet option takes the format of an IP address and subnet mask. You can eitheruse CIDR notation or dotted notation. Multiple entries are permitted:

Media (RTP) handling

In this section we’ll explore how Asterisk handles media and outline some options available to you. If you have a simple network topology where your Asterisk box is connected directly to the PSTN via traditional hardware (analog or digital connections)
and your peers are all on the same LAN as Asterisk, the default configuration is likely fine and you can move on to the next section. If you’re connecting to an Internet telephony service provider (ITSP) via SIP, you may want to start with setting directme dia=no in your sip.conf file. Unless you have a reason to direct media away from your Asterisk box, then use of directmedia=no typically makes the configuration a little easier to deal with:

• Asterisk will always use the symmetric RTP mode as defined in RFC 4961, 16 which means Asterisk will always send packets from the same port that it initially received the media on. The text in RFC 4961 is quite short and is a useful read about how Asterisk will handle the RTP media between endpoints. This knowledge should simplify your network design efforts should you expect to handle peers outside of your LAN environment at any point in the future.

• If you need to override the IP address used for media, you can do that with the media_address option. This option will allow you to ignore the media address supplied in the SDP 17 headers and direct the media somewhere else. Using the media_address option cannot be set per peer: it is a general (global) option only.

• By default Asterisk will attempt to re- INVITE the media between the endpoints directly. The redirecting of the media happens when Asterisk determines it doesn’t need to stay in the media path. (Times when Asterisk needs to be in the media path include call recording and listening for DTMF.) When Asterisk is on the outside of a network where the endpoints are behind a NAT, redirecting of the media doesn’t work very well (or at all). In this case you should use the directmedia=no option to prevent redirection of the media.

The default setting is directmedia=yes , so if you have endpoints behind a NAT that Asterisk is not a part of, you should set the option to directmedia=no .

There does exist an option that allows Asterisk to redirect media between endpoints on the same network as Asterisk, at least as best determined by the RTP core. Enabling redirection of media on the local LAN can be done with directme dia=nonat . If you want to perform an UPDATE instead of a re- INVITE when redi‐ recting the media, you can do that with directmedia=update . If you combine update with nonat (e.g., directmedia=nonat,update ), then you effectively are performing a directmedia=yes .

If you have a peer that you know is itself going to send Asterisk a re- INVITE upon an incoming call, you can set directmedia=outgoing in order to instruct Asterisk to not bother attempting a re- INVITE for media from this peer (since the far end is expected to attempt it). Setting this option can help avoid glare situations, where both ends simultaneously attempt to redirect the media after initial call setup.


figure-RTP without re-INVITE


figure-RTP with re-INVITE

The SIP protocol was designed to enable endpoints to negotiate media capabilities and subsequently make direct connections to each other. The concept was that servers would not need to handle the media load for clients that had the capability to exchange media directly with each other (such as two telephones engaged in a phone call). However, due to the challenges inherent in NAT-enabled firewalls and other complex network topologies, coupled with the incredible processing power of modern servers, it is often simpler to always pass all media through the server, rather than deal with the complexity of sorting out re-INVITE issues across all sorts of different networks and topologies.

• Asterisk can also attempt to set up media directly between peers without a re- INVITE by enabling directrtpsetup=yes . Usage of directrtpmedia comes with some caveats, though; it is considered experimental, and it will not work for video or cases where the callee sends RTP payloads and fmtp headers in the 200 OK that don’t match the caller’s INVITE . Additionally, this option can’t be used when the peers are behind NAT.

• You can control which endpoints can attempt to send directmedia to each other with directmediadeny and directmediapermit . This is useful in situations where your networking topology doesn’t allow certain networks to pass media to each other, instead requiring the media to flow through Asterisk. An example of the usage would be to deny all media flowing between networks, then explicitly permit certain networks to send directmedia :

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. What it means is that at some point a gateway connected to the PSTN needs to accept
calls from the VoIP network and connect them to the PSTN network. From the perspective of the PSTN, the call will appear to have originated at the termination point.

Asterisk can be used as a PSTN termination point. In fact, given that Asterisk handles protocol conversion with ease, this can be an excellent use for an Asterisk system.

In order to provide termination, an Asterisk box will need to be able to handle all of the protocols you wish to connect to the PSTN. In general, this means that your Asterisk box will need a PRI circuit to handle the PSTN connection, and SIP channels to handle
the calls coming from the VoIP network. The underlying principle is the same regardless of whether you’re running a small system providing PSTN trunks to an office full of VoIP telephones, or a complex network of gateway machines deployed in strategic lo‐
cations, offering termination to thousands of subscribers.

Calls from the VoIP network will arrive in the dialplan in whatever context you assigned to the incoming SIP channels, and the dialplan will relay the calls out through the PSTN interface. At its very simplest, a portion of a dialplan that supports termination could look like this:

exten => _X.,1,Verbose(2, Call from VoIP network to ${EXTEN})
same => n,Dial(DAHDI/g0/${EXTEN})

PSTN Origination

Obviously, if you want to pass calls from your VoIP network to the PSTN, 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.

In order to provide origination, a phone number is required. You will therefore need to obtain a circuit from your local phone company, which you will connect to your Asterisk system. Depending on where you are in the world, there are several different types of circuits that could provide this functionality, from a basic analog POTS line to a carrier grade SS7 circuit.

Since phone numbers are controlled by the traditional telecom industry, you will need to obtain the number either from a carrier directly, or from one of the many companies that purchase numbers in bulk and resell them in smaller blocks. If you obtain a circuitsuch as a PRI circuit, you will normally be able to order DID numbers to be delivered with that circuit.

In order to accept a call from a circuit you are using for origination, you will normally need to handle the passing of the phone number that was called. This is because PSTN trunks can typically handle more than one phone number, and thus the carrier needs
to identify which number was called so that your Asterisk system will know how to route the call. The number that was dialed is commonly referred to as the Dialed Number Identification Service (DNIS) number. The DNIS number and the DID do not have to
match, 18 but typically they will. If you are ordering a circuit from the carrier, you will want to ask that they send the DNIS (if they don’t understand that, you may want to consider another carrier).

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:

; This is the context that would be listed in the config file
; for the circuit (i.e. chan_dahdi.conf)
exten => _X.,1,Verbose(2,Incoming call to ${EXTEN})
same => n,Goto(number-mapping,${EXTEN},1)
; This context is not strictly required, but will make it easier
; to keep track of your DIDs in a single location in your dialplan.
; From here you can pass the call to another part of the dialplan
; where the actual dialplan work will take place.
exten => 4165551234,1,Dial(SIP/0000FFFF0001)
exten => 4165554321,1,Goto(autoattendant-context,start,1)
exten => 4165559876,1,VoiceMailMain() ; a handy back door for listening
; to voice messages
exten => i,1,Verbose(2,Incoming call to invalid number)

VoIP to VoIP

Eventually, the need for the PSTN will likely vanish, and most voice communications will take place over network connections.

The original thinking behind the SIP protocol was that it was to be a peer-to-peer protocol. Technically, this is still the case. However, issues such as security, privacy, corporate policies, integration, centralization, and so forth have made things a bit more
involved than simply putting a URI into a SIP phone and having a SIP phone somewhere else ring in response.

The SIP protocol has become bloated and complex. Implementing SIP-based systems and networks has arguably become even more complicated than implementing traditional phone PBXs and networks.

We are not going to get into the complexities of designing and implementing VoIP networks in this book, but we will discuss some of the ways you can configure Asterisk to support VoIP connectivity to other VoIP systems.

Configuring VoIP Trunks

In Asterisk, there is no need to explicitly install your VoIP modules (unless for some reason you did not compile Asterisk with the required modules). There are several VoIP protocols that you can choose to use with Asterisk, but we will focus on the two most
popular: SIP and IAX.

Configuring SIP trunks between Asterisk systems

SIP is far and away the most popular of the VoIP protocols—so much so that many people would consider other VoIP protocols to be obsolete (they are not, but it cannot be denied that SIP has dominated VoIP for several years now). The SIP protocol is peer-to-peer and does not really have a formal trunk specification. This means that whether you are connecting a single phone to your server or connecting two servers together, the SIP connections will be similar.

Connecting two Asterisk systems together with SIP. Being able to connect two Asterisk systems together to allow calls to be sent between them is a fairly common requirement. Perhaps you have a company with two physical locations and want to have a PBX at each location, or maybe you’re the administrator of the company PBX and you like Asterisk so much that you would also like to install it at home. This section provides a quick guide on configuring two Asterisk servers to be able to pass calls to each other over SIP. In our example, we will creatively refer to the two servers as serverA and serverB . The first file that must be modified is /etc/asterisk/sip.conf. This is the main configuration file for setting up SIP accounts. First, this entry must be added to sip.conf on serverA . It defines a SIP peer for the other server:

; Specify the SIP account type as ‘peer’. This means that incoming
; calls will be matched on IP address and port number. So, when Asterisk
; receives a call from and the standard SIP port of 5060,
; it will match this entry in sip.conf. It will then request authentication
; and expect the password to match the ‘secret’ specified here.
type = peer
; This is the IP address for the remote box (serverB). This option can also
; be provided a hostname.
host =
; When we send calls to this SIP peer and must provide authentication,
; we use ‘serverA’ as our default username.
defaultuser = serverA
; This is the shared secret with serverB. It will be used as the password
; when either receiving a call from serverB, or sending a call to serverB.

secret = apples
; When receiving a call from serverB, match it against extensions
; in the ‘incoming’ context of extensions.conf.
context = incoming
; Start by clearing out the list of allowed codecs.
disallow = all
; Only allow the ulaw codec.
allow = ulaw

Now put the following entry in /etc/asterisk/sip.conf on serverB . It is nearly identical to the contents of the entry we put on serverA , but the name of the peer and the IP address were changed:

type = peer
host =
defaultuser = serverB
secret = apples
context = incoming
disallow = all
allow = ulaw

At this point you should be able to verify that the configuration has been successfully loaded into Asterisk using some CLI commands. The first command to try is sip show peers. As the name implies, it will show all SIP peers that have been configured:

*CLI> sip show peers

Name/username                     Host              Dyn Forcerport   ACL Port                     Status

server B/server A                                   5060                Unmoniterd

1 sip peers [Monitored: 0 online, 0 offline Unmonitored: 1 online, 0 offline]

The last step in setting up SIP calls between two Asterisk servers is to modify the dialplan in /etc/asterisk/extensions.conf. For example, if you wanted any calls made on serverA to extensions 6000 through 6999 to be sent over to serverB , you would use this line in the dialplan:

exten => _6XXX,1,Dial(SIP/${EXTEN}@serverB)

Connecting an Asterisk system to a SIP provider. When you sign up for a SIP provider, you may have service for sending and/or receiving phone calls. The configuration will differ slightly depending on your usage of the SIP provider. Further, the configuration will differ between each provider. Ideally, the SIP provider that you sign up with will provide Asterisk configuration examples to help get you connected as quickly as possible. In case they do not, though, we will attempt to give you a common setup that will help you get started.

If you will be receiving calls from your service provider, the service provider will most likely require your server to register with one of its servers. To do so, you must add a registration line to the [general] section of /etc/asterisk/sip.conf:


register => username:password@your.provider.tld

Next, you will need to create a peer entry in sip.conf for your service provider. Here is a sample peer entry:

type = peer
host = your.provider.tld
defaultuser = username
secret = password
; Most providers won’t authenticate when they send calls to you,
; so you need this line to just accept their calls.
insecure = invite
dtmfmode = rfc2833
disallow = all
allow = ulaw

Now that the account has been defined, you must add some extensions in the dialplan to allow you to send calls to your service provider:

exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@myprovider)

Encrypting SIP calls. Asterisk supports TLS for encryption of the SIP signaling and Secure Realtime Transport Protocol (SRTP) for encryption of the media streams of a phone call. In this section we will set up calls using SIP TLS and SRTP between two Asterisk servers. The first step is to ensure the proper dependencies have been installed. Ensure that you have both OpenSSL and LibSRTP installed. If either one of these was not installed, reinstall Asterisk after installing these dependencies to ensure that support for TLS and SRTP are included. Once complete, make sure that the res_srtp module was compiled and installed. To install OpenSSL, the package is openssl-devel on RHEL and libssl-dev on Ubuntu. To install LibSRTP, the package is libsrtp-devel on RHEL and libsrtp0-dev on Ubuntu.

Next, we will configure SIP TLS. You must enable TLS using the global tlsenable option in the [general] section of /etc/asterisk/sip.conf on both servers. You can optionally specify an address to bind to if you would like to limit listening for TLS connections to a single IP address on the system. In this example, we have the IPv6 wildcard address specified to allow TLS connections on all IPv4 and IPv6 addresses on the system:

tlsenable = yes
tlsbindaddr = ::

The next step is to get certificates in place. For the purposes of demonstrating the con‐ figuration and functionality, we are going to generate self-signed certificates using a helper script distributed with Asterisk. If you were setting this up in a production environment, you might not want to use self-signed certificates. However, if you do, there are a number of applications out there that help make it easier to manage your own certificate authority (CA), such as TinyCA.
The script that we are going to use is ast_tls_cert, which is in the /contrib/scripts directory of the Asterisk source tree. We need to generate a CA certificate and two server certificates. The first invocation of ast_tls_cert will generate the CA cert and the server cert
for serverA . The second invocation of ast_tls_cert will generate the server cert for serverB :

$ cd contrib/scripts
$ mkdir certs
$ ./ast_tls_cert -d certs -C serverA -o serverA
$ ./ast_tls_cert -d certs -C serverB -o serverB -c certs/ca.crt -k certs/ca.key
$ ls certs

ca.cfg ca.crt ca.key serverA.crt serverA.csr serverA.key serverA.pem
serverB.crt serverB.csr serverB.key serverB.pem tmp.cfg

Now that the certificates have been created, they need to be moved to the appropriate locations on serverA and serverB . We will use the /var/lib/asterisk/keys directory to hold the certificates. Move the following files to serverA :

• ca.crt
• serverA.pem

And move these files to serverB :
• ca.crt
• serverB.pem

With the certificates in place, we can complete the Asterisk configuration. We need to point Asterisk to the server certificate that we just created. Since we’re using self-signed certificates, we also need to point to the CA certificate. In the [general] section of /etc/
asterisk/sip.conf on serverA , add these options:

tlscertfile = /var/lib/asterisk/keys/serverA.pem
tlscafile = /var/lib/asterisk/keys/ca.crt
Make the same changes to sip.conf on serverB :
tlscertfile = /var/lib/asterisk/keys/serverB.pem
tlscafile = /var/lib/asterisk/keys/ca.crt

In “Connecting two Asterisk systems together with SIP” on page 174, we created the configuration necessary to pass calls between serverA and serverB . We are now going to modify that configuration so that Asterisk knows that the calls between the two servers should be encrypted. The only change required is to add the transport =tls option to the peer entry for the other server.

On serverA :
type = peer
host =
defaultuser = serverA
secret = apples
context = incoming
disallow = all

allow = ulaw
transport = tls
On serverB :
type = peer
host =
defaultuser = serverB
secret = apples
context = incoming
disallow = all
allow = ulaw
transport = tls
Now when you make a call using Dial(SIP/serverA) or Dial(SIP/serverB) , the SIP signaling will be encrypted. You can modify the dialplan to force outgoing calls to have encrypted signaling by setting the CHANNEL(secure_bridge_signaling) function to 1 :
exten => 1234,1,Set(CHANNEL(secure_bridge_signaling)=1)
same => n,Dial(SIP/1234@serverB)

On the side receiving the call, you can check whether the signaling on an incoming call is encrypted using the CHANNEL(secure_signaling) dialplan function. Consider the following example dialplan:


Exten => _X.,1,Answer()
same => n,GotoIf($[“${CHANNEL(secure_signaling)}” = “1”]?secure:insecure)
same=> n(secure),NoOp(Signaling is encrypted.)
same=> n,Hangup()
same=> n(insecure),NoOp(Signaling is not encrypted.)
same=> n,Hangup()

When a call is sent from serverA to serverB using this configuration, you can see from the output on the Asterisk console that the dialplan determines that the signaling of the incoming call is encrypted:

— Executing [1234@incoming:1] Answer(“SIP/serverA-00000000”, “”)
in new stack
— Executing [1234@incoming:2] GotoIf(“SIP/serverA-00000000”,
“1?secure:insecure”) in new stack
— Goto (incoming,1234,3)
— Executing [1234@incoming:3] NoOp(“SIP/serverA-00000000”,
“Signaling is encrypted.”) in new stack
— Executing [1234@incoming:4] Hangup(“SIP/serverA-00000000”, “”)
in new stack

Now that SIP TLS has been set up for calls between serverA and serverB , we will set up SRTP so that the media streams associated with the call are encrypted as well. Luckily, it is quite easy to configure, compared with what was required to get SIP TLS working. First, make sure that you have the res_srtp module loaded in Asterisk:

*CLI> module show like res_srtp.so

Module                                                 Description                                   Use Count

res_srtp.so                                             Secure RTP                                                0

1 module loaded

To enable SRTP, set the CHANNEL(secure_bridge_media) function to 1 :

exten => 1234,1,Set(CHANNEL(secure_bridge_signaling)=1)
same => n,Set(CHANNEL(secure_bridge_media)=1)
same => n,Dial(SIP/1234@serverB)

This indicates that encrypted media is required for an outbound call. When the call is sent out via SIP, Asterisk will require that SRTP be used, or the call will fail. With all of these tools in place, you can ensure that calls between two Asterisk servers
are fully encrypted. The same techniques should be applied for encrypting calls between Asterisk and a SIP phone.
The dialplan functions provide a mechanism for verifying the encryption status of an incoming call and forcing encryption on an outgoing call. However, keep in mind that these tools only provide the means for controlling encryption for one hop of the call
path. If the call goes through multiple servers, these tools do not guarantee that the call is encrypted through the entire call path. It is important to carefully consider what your requirements are for secure calls and take all of the necessary steps to ensure that those
requirements are respected throughout the entire call path. Security is complicated, hard work.

Configuring IAX trunks between Asterisk systems

The Inter-Asterisk eXchange protocol, version 2 (most commonly known as IAX), is Asterisk’s own VoIP protocol. It is different from SIP in that the signaling and media are carried in the same connection. This difference is one of the advantages of the IAX
protocol, as it makes getting IAX to work across NAT connections much simpler.

IAX trunking. One of the more unique features of the IAX protocol is IAX trunking. Trunking an IAX connection could be useful on any network link that will often be carrying multiple simultaneous VoIP calls between two systems. By encapsulating multiple audio streams in one packet, IAX trunking cuts down on the overhead on the data connection, which can save bandwidth on a heavily used network link.

IAX encryption. The principal advantage of IAX encryption is that it requires one simple change to the /etc/asterisk/iax.conf file:
encryption = yes
For extra protection, you can set the following option to ensure that no IAX connection can happen without encryption:
forceencryption = yes
Both of these options can be specified in the [general] section, as well as in peer / user / friend sections in iax.conf.

Emergency Dialing

In North America, people are used to being able to dial 911 in order to reach emergency services. Outside of North America, well-known emergency numbers are 112 and 999. If you make your Asterisk system available to people, you are obligated (in many cases regulated) to ensure that calls can be made to emergency services from any telephone connected to the system (even from phones that otherwise are restricted from making calls).

One of the essential pieces of information the emergency response organization needs to know is where the emergency is (i.e., where to send the fire trucks). In a traditional PSTN trunk, this information is already known by the carrier and is subsequently passed along to the Public Safety Answering Point (PSAP). With VoIP circuits things can get a bit more complicated, by virtue of the fact that VoIP circuits are not physically tied to any geographical location.

You need to ensure that your system will properly handle 911 calls from any phone connected to it, and you need to communicate what is available to your users. As an example, if you allow users to register to the system from softphones on their laptops,
what happens if they are in a hotel room in another country, and they dial 911?

The dialplan for handling emergency calls does not need to be complicated. In fact, it’s far better to keep it simple. People are often tempted to implement all sorts of fancy functionality in the emergency services portions of their dialplans, but if a bug in one of your fancy features causes an emergency call to fail, lives could be at risk. This is no place for playing around. The [emergency-services] section of your dialplan might look something like this:

exten => 911,1,Goto(dialpsap,1)
exten => 9911,1,Goto(dialpsap,1) ; some people will dial ‘9’ because
; they’re used to doing that from the PBX
exten => 999,1,Goto(dialpsap,1)
exten => 112,1,Goto(dialpsap,1)
exten => dialpsap,1,Verbose(1,Call initiated to PSAP!)
same => n,Dial(${LOCAL}/911) ; REPLACE 911 HERE WITH WHATEVER

include => emergency-services  ; you have to have this in any context
; that has users in it

In contexts where you know the users are not onsite (for example, remote users with their laptops), something like this might be best instead:

exten => 911,1,Goto(nopsap,1)
exten => 9911,1,Goto(nopsap,1) ; for people who dial ‘9’ before external calls
exten => 999,1,Goto(nopsap,1)
exten => 112,1,Goto(nopsap,1)

exten => nopsap,1,Verbose(1,Call initiated to PSAP!)
same => n,Playback(no-emerg-service) ; you’ll need to record this prompt

include => no-emergency-services

In North America, regulations have obligated many VoIP carriers to offer what is popularly known as E911.  When you sign up for their services, they will require address information for each DID that you wish to associate with outgoing calls. This address information will then be sent to the PSAP appropriate to that address, and your emergency calls should be handled the same way they would be if they were dialed on a traditional PSTN circuit.

The bottom line is that you need to make sure that the phone system you create allows emergency calls.

For any query or issue, feel free to discuss on http://discuss.eduguru.in