Taking the plunge with SIP Trunks - part 3

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

We're moving! Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at: http://kb.smartvox.co.uk/. To read the latest revision of this article on SIP trunks in Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/index.php/asterisk/telephony-connections/sip-trunks-telephony-connections/taking-the-plunge-with-sip-trunks-part-3/

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 duplicate the settings for "context=" and "insecure=" that were described in part 2 because Asterisk can be annoyingly unpredictable about separation of inbound and outbound call handling.


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 assign that value both to the "username=" and the "fromuser=" as shown above. Otherwise, set "fromuser" as your DID number. 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
fromuser=43212345
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 is usually the last one that takes precedence. However, in the latest release 1.6 of Asterisk, this unwritten rule seems to have been reversed - the first matching peer is used. 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.

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. There is no point re-inventing the wheel, so I recommend you check out this link for details of how to use the CUT function in Asterisk to get the dialled number:
http://www.freepbx.org/support/documentation/howtos/how-to-get-the-did-of-a-sip-trunk-when-the-provider-doesnt-send-it-and-

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 sectio 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:
http://www.smartvox.co.uk/astfaq_configbehindnat.htm

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. 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.ozvoip.com/voip-codecs/
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml

Taking the plunge with SIP Trunks - part 2

Recap
In part 1, I explained how a SIP Trunk is really just a virtual connection between your Asterisk PBX and the VoIP service provider. Standard SIP signalling is used on the trunk, but more than one simultaneous call is allowed and you may have more than one DDI number.

We're moving! Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at: http://kb.smartvox.co.uk/. To read the latest revision of this article on SIP trunks in Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/index.php/asterisk/telephony-connections/sip-trunks-telephony-connections/taking-the-plunge-with-sip-trunks-part-2/

Basic requirements to enable your SIP trunk
A SIP Trunk may be used for both inbound and outbound call traffic. To make outbound calls, your Asterisk or other PBX has to send a SIP INVITE request to the VoIP service provider's equipment; when you receive an inbound call, the service provider is sending an INVITE to your PBX. While there are some subtle differences between the delivery of outbound calls and receipt of inbound calls, both share the following basic requirements:

1. Location - knowing the address of the far-end equipment
2. Authentication - the ability to confirm the identity of the sender

Authentication is especially important for outbound calls because these will generally incur service provider charges.

Resolving equipment location
The address of the VoIP service provider's equipment is very predictable and unlikely to change over time. But how does the VoIP service provider know the address of your PBX? Some users will have a static IP address, but this is not universal and NAT can add further complications. For this reason, most VoIP service providers will require that your PBX registers itself on their equipment.

Your PBX does this by sending a SIP REGISTER request to the service provider at regular intervals (typically every 30 to 60 minutes). In so doing it provides up-to-date information about the location of your PBX. Keep-alive messages may also be sent to keep the route open through a NAT device or firewall.

Registration for Asterisk or Trixbox
In Asterisk, registration information is provided in a single line placed in the general section of sip.conf. Using Trixbox, this line appears at the end of the trunk definition form. Here is an example of the register line:

register => 43212345:mysecret@mysipsp.com/1234

The register line includes a host name (mysipsp.com) which tells Asterisk where to send the registration request; the number at the beginning of the line (43212345) is the user ID and mysecret is the password; finally, the number 1234 shown at the end of the line - after a forward slash - is an optional parameter that tells the service provider to use this number when sending INVITE requests to Asterisk.

Authentication
The user ID and password included in the registration line above are used to provide authentication during registration - to identify to the provider that you are the correct account holder. However, take note that inbound calls do not use password authentication at the time the call is delivered - instead, Asterisk knows the request is coming from your service provider by matching the sending IP address with the host parameter stored in sip.conf.

Some examples of Asterisk configuration
In Trixbox or FreePBX, the sections for dealing with inbound calls and registration are found at the end of the SIP trunk configuation form:



If you are using raw Asterisk, the register string will look the same and the equivalent peer section in sip.conf would look like this:

[smartvox-in]
type=user
context=from-trunk
insecure=invite
host=mysipsp.com

The use of the insecure parameter as shown above is simply a way of telling Asterisk that it should not challenge for user ID and password when a new inbound call INVITE arrives. Omitting this parameter can break delivery of inbound calls.

More on dealing with inbound calls in part 3.

Taking the plunge with SIP Trunks

We're moving! Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at: http://kb.smartvox.co.uk/. To read the latest revision of this article on SIP trunks in Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/index.php/asterisk/telephony-connections/sip-trunks-telephony-connections/taking-the-plunge-with-sip-trunks-part-1/

SIP Trunks are often talked about on the Asterisk wiki and forum pages; Many VoIP service providers offer them as a standard product; But just what is a SIP trunk and what can you use it for and how do you make it work with Asterisk? I will attempt to answer these questions in what I anticipate will be a 3 part blog, starting with the basics.

What is a SIP Trunk?
A SIP trunk uses standard SIP signalling, but the endpoints of the trunk are fixed - typically one end point is the ITSP - Internet Telephony Service Provider - and the other is your PBX (e.g. Asterisk).


The SIP Trunk will usually just be one segment in the entire end-to-end pathway of a call. It may be used for inbound/outbound or both types of call and a number of different calls can be active at the same time, all using the same SIP Trunk connection. However, to truly qualify as a SIP Trunk, it should be possible to associate more than one incoming number (DDI or DID) with the same account.

What do you connect to a SIP Trunk?
Normally, the equipment at the customer's premises will be some kind of SIP-enabled PBX. An Asterisk PBX is ideal for this role.

Although possible, it would be unusual and probably impractical to connect an IP Phone or softphone directly to a SIP Trunk. However, there is just about no difference in terms of the SIP signalling. The Asterisk configuration to connect to a personal VoIP account - the type normally used for a single IP phone or softphone - is almost identical to that used for a SIP Trunk account. The differences between personal SIP accounts and SIP Trunks are as much commercial as they are technical - greater capacity for simultaneous calls and greater provision of inbound numbers managed through a single SIP connection. The main technical difference is the ability of a PBX to extract the target DDI number and use it to correctly route inbound calls.

How do you connect to a SIP Trunk?
Sometimes it is necessary for the PBX to register with the ITSP, primarily because this allows the service provider to know where the PBX is located - its IP address. The service provider then knows to send your inbound calls to that IP address. Sometimes the connection is achieved without registration, simply using a pre-defined IP address. This latter option is more likely to be used for direct connections to carriers or for other high-end connections involving wholesale services.

Making and receiving calls over a SIP Trunk
Inbound calls delivered by the ITSP to your PBX will contain the DDI number that was called. This must be interpreted by the PBX to determine the routing of the call to a device - typically a phone, but could be to a ring group or ACD queue. More about the setup for inbound calls in part 2.

Outbound calls are sent to the ITSP by the PBX and, in response to an authentication challenge, it will also need to send credentials for authentication/authorisation. The challenge authentication/authorisation is required even if the PBX has registered. Again, there will be some more on this later.

Just passing through

We're moving! Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at: http://kb.smartvox.co.uk/. To read the latest revision of this article on Asterisk Codec selection and pass-through mode at the new site, follow this link: http://kb.smartvox.co.uk/asterisk/how-it-works/rtp-pass-through-mode-in-asterisk/

The Pika Appliance for Asterisk (affectionately known as the Warp Appliance) is a great little device to use as a small office telephone system connecting to SIP trunks and conventional analogue or Basic Rate ISDN lines. It does, however, have one potentially annoying weakness - no support for transcoding to or from the G.729 codec.

G.729 compressed speech uses less bandwidth than uncompressed G.711. Ok, there is a trade-off in so far as the speech quality is not quite as good, but if you need to deliver multiple simultaneous calls over an ADSL broadband link, then it has to be considered.

In theory, Asterisk supports so-called "pass-through" mode - this is where the encoded/compressed speech passes through unchanged from the SIP trunk to an IP extension phone. Transcoding is not required, so the Pika's lack of support for G.729 is irrelevant. The question is "Can the Pika Appliance be configured as a basic PBX feeding G.729 encoded calls from a SIP trunk to local extensions?". The answer is yes, but setting up the list of allowed codecs in the sip.conf file is not altogether straightforward.

My research showed that Asterisk is not very clever when it is matching up codecs on the inbound and outbound legs of a SIP-to-SIP call. The rules seem to be this: the 1st preferred codec of the calling peer is always used and, provided the called peer also supports this codec, then pass-through is activated. If the calling peer's 1st codec is not allowed by the called peer, then Asterisk attempts transcoding using the 1st codec of each peer. If it is unable to transcode (e.g. when G.729 is the 1st codec for one peer on the Pika Warp) then the call fails with a "not supported here" message. This is quite unsophisticated because it never looks at the options for pass-through using the 2nd, 3rd or other codecs listed for the calling peer.

Pass-through mode may provide a useful solution for direct peer to peer calling, but if you want Asterisk to play a sound file then you may be faced with a similar problem. In theory you could record all the prompts in a G.729 encoded format thus avoiding the need for transcoding. If you have tried this or have any other comments, please post your comments back here.