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

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:


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:

4 thoughts on “Taking the plunge with SIP Trunks – Part 3”

  1. Muy buena explicación estimado:
    Un par de preguntas:
    1.-¿Cuál es la diferencia entre el “username” y “fromuser”?
    2.-En un: “type=peer”, (SIP.CONF)

    …En el “Status” me sale “desconocido”(UNKNOWN), porqué puede ser?….Gracias por su respuesta

    • perdón, descarto: “estado=desconocido”….en el “estado” lo que me sale es: “Unmonitored”

    • Peers in SIP.CONF are used for more than one job:
      (a) to define SIP trunks and remote end points such as carriers or other Asterisk servers
      (b) to create local accounts on Asterisk that can be used to register an IP phone or softphone

      “username” is an old parameter, now deprecated, that could be used when authentication credentials were needed: i.e. username and password (secret). Such credentials are not normally used on a SIP trunk because SIP trunks are mostly authenticated by the source IP address only.
      “fromuser” does a very specific task. Along with another parameter, “fromdomain”, it sets the value that will be used in the From header. SIP messages contain a number of headers. The From header is important because some VoIP Service Providers will only accept your calls if the From header contains the right values – it may be used as additional security to confirm you are a legitimate user and/or it may be used to set the Caller ID on outbound calls from Asterisk. It normally shows the caller’s number in the username and the address of their main SIP server in the fromdomain. e.g.

      From: “Roberto Beraun” <sip:+44123456789@>

      In that example, fromuser is +44123456789

      The status “Unmonitored” just shows that you did not set “qualify=yes”. If you are having trouble with a SIP trunk, it can be useful to set qualify=yes so you can see if there is a valid network connection from Asterisk to the VoIP service provider.

Comments are closed.