In my original PBX in a Flash setup, Asterisk is set to “listen in” on calls. One advantage of this is that it can then respond to commands sent from a phone keypad during the call, e.g. to transfer or record the call. However, it does add processing overhead. If your devices support it, you can tell Asterisk to butt out of your conversations, allowing connections to “bridge” directly between endpoints and avoid going through Asterisk. Here’s how.

Set Up General Settings

Log in to the FreePBX administration page and make the following changes:

1. In the left column under Basic, click on General Settings.
2. At the top of the page, under Dialing Options, set these values:
   – Asterisk Dial command options:  r
   – Asterisk Outbound Dial command options:  leave blank
3. Click on Submit.

You have now told Asterisk not to listen for DTMF commands to transfer or record calls. Note that this means you will not be able to do any transfers from an analog phone connected to an FXS port. However, a SIP phone can “break in” to a call to do a transfer, put the call on hold, etc.

Set Up Extensions

Log in to the FreePBX administration page and make the following changes:

1. In the left column under Basic, click on Extensions.
2. From the list at the right side of the page, click on each extension that is connected to a device that supports the “reinvite” command. (I’m using a Linksys SPA3102 and a Polycom IP430, both of which support reinvites.) Under Device Options, set this value:
   canreinvite=nonat
3. Click on Submit after changing each extension.

This tells Asterisk that the device can handle a reinvite as long as the device is not behind a NAT.

Set Up Trunks

Log in to the FreePBX administration page and make the following changes:

1. In the left column under Basic, click on Trunks.
2. From the list at the right side of the page, click on each trunk is connected to a device that supports the “reinvite” command. (The Linksys SPA3102 also supports reinvites on the trunk or PSTN side.) In the PEER Details box, add this line:
   canreinvite=nonat

This tells Asterisk that the trunk can handle a reinvite as long as the device is not behind a NAT.

Apply Your Changes

Once you have updated the General Settings, Extensions, and Trunks, click on the orange bar at the top of the FreePBX administration page, then confirm. That’s it! Asterisk will now get out of the way whenever possible.

Testing

If you know how to use a packet sniffer, you should be able to see the difference in how the RTP (audio) packets are routed:  the source and destination will no longer include the Asterisk server.

A simpler method:  once the dial plans have been updated as described above, start the Asterisk Command Line Interface (CLI) with a verbosity of 3 (asterisk -r -vvv). Call in from an outside line and answer the internal extension. Right after you answer, you should see a message like this:

Native bridging SIP/Personal-12345678 and SIP/20-abcdefgh

If instead you see this:

Packet2Packet bridging SIP/Personal-12345678 and SIP/20-abcdefgh

then Asterisk is still “in” the media stream, but the RTP packets are not going through the Asterisk core.

Tip:  to reduce the level of verbosity, while still in the Asterisk CLI, type

core set verbose 0

That makes it easier to use the sip show commands described below.

References

Voip-Info has a long and informative article titled Asterisk sip canreinvite. It even includes instructions on how to use the tcpdump packet sniffer from the Linux command line.

The default sip.conf from Digium explains the canreinvite=nonat option, new in Asterisk 1.4:

An additional option is to allow media path redirection (reinvite) but only when the peer where the media is being sent is known to not be behind a NAT (as the RTP core can determine it based on the apparent IP address the media arrives from).

From Joshua Colp, Software Developer at Digium, comes this explanation of bridging:

Packet2Packet Bridging = Audio is not going through the Asterisk core, it comes into the RTP stack and goes directly out. This decreases the amount of memory allocation that happens, and things require less processing.

Native Bridging = Audio was reinvited between the two endpoints so it (should) go direct.

as well as this helpful note on checking for how Asterisk is handling audio:

During the call, run sip show channel xxxyyzz and check “Audio IP”. If the audio IP doesn’t belong to your Asterisk server, media is handled through the native bridge.

To get the channel name for that command, while in a call, type sip show channels. Both commands are executed from the Asterisk CLI.