Taking the plunge with SIP Trunks – Part 3

Outbound calls; Matching a DDI/DID; Diagnosing problems; Internet bandwidth.

Configuration for Outbound calling

Part 2 looked only at the configuration for receiving inbound calls, but the SIP Trunk configuration form in Trixbox/FreePBX has to also include the settings for making outbound calls. It may not even work at all if you only use the inbound call settings shown in part 2.

You will need a peer definition in sip.conf that includes “type=peer” and has the user ID and password required by your VoIP service provider. I also recommend that you add the “insecure=” parameter because Asterisk can be annoyingly unpredictable about separation of inbound and outbound call handling. By including the “insecure=invite” parameter, it tells Asterisk to trust  inbound call requests from the specified remote host address. Usually, when a password has been specified by the “secret=” parameter, Asterisk will challenge inbound requests from the peer for authentication. However, we only specified the password because it is needed for outbound calls – the solution is the “insecure” parameter.

Outbound calls are authenticated with “username” and “secret” during call set up. Some service providers may also check that your PBX is registered, but this is usually unnecessary for outbound calls. Where the user ID assigned to you by the VoIP service provider is also your DID number, then you may need to assign that value both to the “username=” and the “fromuser=” as shown above. Otherwise, when using FreePBX, it is best to omit “fromuser” because the Caller ID is set using various rules in the Extensions, Outbound Routes or Trunks setup forms. Should you still find it necessary to specify a value here, try setting it to your primary DID number.

Many service providers prefer to receive the Caller ID within a P-Asserted-Identity header. Versions of Asterisk after about 1.6 support this through the addition of sendrpid=pai in the Peer Details box of FreePBX, as illustrated below.

The “host=” parameter tells Asterisk where to send the INVITE request when making a call. The “qualify=yes” parameter tells Asterisk to ping the service provider at frequent intervals – this allows Asterisk to monitor the connection and to maintain some measure of its latency (the time it takes for packets to get from one end of the connection to the other).

For those of you who prefer to use raw Asterisk instead of Trixbox or FreePBX, you will need to add a similar section in sip.conf to the one shown above for FreePBX:

[smartvox-out] type=peer
username=432112345
secret=mysecret
sendrpid=pai
fromdomain=mysipsp.com
qualify=yes
context=from-trunk
insecure=invite
host=mysipsp.com

In fact, the above peer definition (plus the registration) should be all you need for handling both inbound and outbound calls. Inbound calls are matched against known peers by checking the address given for “host=”. When there are two peers defined in sip.conf with the same host address, it used to be the last one that takes precedence. However, in the later releases of Asterisk (1.6.x onwards), this unwritten rule seems to have been reversed – the first matching peer is used or possibly they are sorted alphabetically. If you only have one peer definition capable of handling both inbound and outbound calls (as shown above) then there is less scope for confusion.

Cautionary note:

Never use “type=friend” in a SIP Trunk peer definition where you have used “insecure=invite” or where no “secret” has been specified. Doing so will make your Asterisk PBX much less secure and opens an easy route in for hackers.

Note about the username parameter:

The Asterisk developers keep threatening to remove the “username” parameter, saying that it is deprecated. I am sure their intention is to make things clearer, but frankly they first need to clear up the confusion over authentication for inbound/outbound requests, matching of peer definitions on inbound requests where more than one peer definition has the same value for the “host” parameter and the differences between static peers, dynamic peers and users. Anyway, if they ever do kill off username, the alternatives are: for inbound calls, set the name of the peer (the Trunk name in FreePBX) to the username. This may also work for outbound calls, but there is also an “auth” parameter and a “defaultuser” parameter, but they were poorly documented the last time I looked.

Matching the DDI/DID number for inbound calls

SIP trunks are likely to support multiple inbound DID numbers so your dial plan will have to be able to match each number and route the call correctly. However, different service providers use different techniques to send the dialled number to your PBX. It is very likely that you will have to add some special code to the Asterisk dial plan to extract the dialled number from the To header in the SIP INVITE. For this it is possible to use the CUT function in Asterisk to get the dialled number. In FreePBX they now provide a special context designed to get the DID from the To header. The context is called [from-pstn-toheader], but I couldn’t find a nice explanation of how you use it. It is referred to in the answers given in the FreePBX forums including one answer here.

Diagnosing problems and monitoring your connection
The following Asterisk CLI commands are extremely useful for checking if things are working:
To check it has registered with the VoIP service provider: sip show registry
To see information about defined sip peers: sip show peers
To see detailed information about one peer: sip show peer <peer_name>
To view all SIP packets sent to-from Asterisk: sip set debug on
To view SIP packets sent to-from one peer: sip set debug peer <peer_name>
To switch off sip debug: sip set debug off

I recommended you add the parameter “qualify=yes” in your peer definition. If you did, then the command “sip show peers” will be able to show you if the peer is reachable and what the approximate delay is for packets sent to that peer. This is shown in the last column, “Status”. Note that, if this status appears as “unreachable”, then Asterisk will not attempt to send any SIP requests to it – an outbound call via that peer will fail as soon as it is dialled.

If you are getting problems with one-way audio or simply with making or receiving calls over your SIP Trunk, then the chances are it will be because your Asterisk server is behind NAT. This is a very common problem and usually can be cleared by setting a couple of parameters in the general section of the sip.conf file (sip_general_custom.conf on Trixbox/FreePBX) and possibly setting some port forwarding on your firewall. Read my article here for details:

https://kb.smartvox.co.uk/asterisk/asterisk-nat

Internet Bandwidth
So you’ve got your SIP trunk working and in theory it can carry several simultaneous calls. One thing you must remember is that each call requires a significant amount of bandwidth on your broadband connection. If you are using one broadband connection for both data and voice, then there will probably be times when the voice quality suffers because there is too much contention for the bandwidth available. If possible (and if you want to carry several simultaneous calls) it is best to use a dedicated broadband connection for voice traffic. Remember that voice uses equal amounts of upload and download bandwidth whereas ADSL has much more download capacity then upload. Try one of the many free web based broadband speed comparison tests to see how your broadband connection is performing at different times of the day. Ideally, use SDSL or a leased line solution [2017 update: SDSL and leased line are now old technologies and in most urban areas the standard broadband connection from the usual providers is good enough for many simultaneous calls, but fibre to the cabinet (FTTC) or fibre to the premises would be ideal for businesses]. If you are using one Internet connection for voice and data, consider using QoS mechanisms to manage the bandwidth and prioritise voice over data. Also consider using the more compressed codecs such as GSM or G.729 instead of the uncompressed G.711 codecs (A-Law and u-Law), even if it does mean you’ll have to purchase some G.729 licenses for your Asterisk server.

The following links provide useful data about the bandwidth demands for various codecs:
http://www.bandcalc.com/
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml