Issue Resolution: No audio on SIP-SIP gateway calls

The Problem

In certain instances, when using particular SIP trunks, we have found that there can be audio issues on gateway calls where an inbound call arrives on a SIP trunk, and is sent directly out of a SIP trunk again.

This could be in the case of a trunk to trunk gateway, or a Follow-me/Call forward setting that forwards the call to an external number.

The Cause

This issue is caused by the firewall on site, and the way it works with a PBX. Since the PBX is behind a firewall, network traffic has limited access to he device.

In traditional SIP calls, the firewall/router uses NAT to locate the PBX within the LAN network, and directs appropriate SIP traffic to it. When the PBX answers a SIP invite, the PBX initiates the opening of an RTP stream that pokes a hole in the firewall, allowing for return traffic.

In the gateway instance though, no audio is ever sourced from the PBX, with the call being sent straight out again without first being answered. This means that the PBX does not open a pinhole for the RTP stream to travel through the firewall, and so the audio stream sent by the provider is unable to reach the PBX, and the external device to which the call was forwarded.

The Solution

In order to rectify the no audio issue, we need to make sure that an RTP stream is initiated by the PBX, and that a pin hole is poked in the firewall to allow return traffic.

In some instances, this is as simple as adding an announcement or message before the call is sent out of the outbound route, encouraging the PBX to initiate the RTP stream, and allowing audio to flow.

Sometimes though, an announcement or message is either impractical or impossible.

In these instances, we need to make some changes in the dialplan in order to have the SIP trunk send all of the necessary messaging to create the audio stream.

Changes to the SIP trunk configuration

We can encourage the SIP trunk to initiate the RTP stream and open the pinhole by allowing it to send progress tones within the audio band. This means that an event like ringing will be sourced on the PBX and sent out of the trunk back to the provider, poking open a pinhole in the firewall as it does so.

In order to allow progress messages to be sent in band, we need to add the following line to /etc/asterisk/sip,conf, under the [general] tag.

progressinband=yes

Changes in the dialplan

Now that we have added a line allowing progress messages to be sent in the audio band, all we need to do is add some progress messages to the dialplan. The easiest way to do this, is to place the trunk into a flexpath, and then add a custom section for that flexpath in the /etc/asterisk/extensions_custom.conf file.

So first create a flexpath, with the appropriate routing (an include route, with the destination set to Inbound DID will direct all calls received to the inbound routes panel to try and find a match. I have elected to use an include route in this instance).

Above a flexpath named exampleFlexpath is created, with an include route to direct all calls to the list of inbound routes. Assign the SIP trunk to the flexpath context.

Now that the flexpath is created, custom dialplan can be inserted into the /etc/asterisk/extensions_additional.conf file and applied only to the flexpath context.

I know that the context for inbound routes is ext-did where the context for extensions is did-direct. I will need to send calls to these contexts in my custom routing.

So I edit /etc/asterisk/extensions_custom.conf and add lines to catch any calls in the flexpath, and have them run through dialplan that sends a SIP progress message, then a SIP ringing message, before directing the call to the inbound routes context. I do this by adding the following lines:

[flexpath-exampleFlexpath-custom]

exten => _X.,1,progress

exten => _X.,n,ringing

exten => _X.,n,Goto(ext-did,${EXTEN},1)

which look like this once saved:

The [flexpath-exampleFlexpath-custom] tag indicates that the dialplan beneath it applies only to the flexpath named exampleFlexpath (notice that this is case sensitive).

The next line catches calls for X. (which is a catch for any number), and as step 1, sends a progress message. The next line says to send a ringing message, and finally tells the call to go to the ext-did context, and ring the number that we received over the SIP trunk (which is stored in ${EXTEN})

After saving this file, access the Asterisk CLI and reload the dialplan using the command "dialplan reload". Finally, the SIP module needs to be reloaded in order for the progressinband=yes line to take effect. "module reload chan_sip.so". Both of these reloads could be substituted by an apply from the GUI, which reloads both modules.

You can confirm that your customisation is included in the dialplan by looking out for the ringing and progress lines in a call trace: