This post has a concise guide to SPA942 BLF configuration:

How to configure BLF with a Linksys SPA942 and Asterisk 1.4

I found that I didn’t have to change the PBX in a Flash (PiaF) setup of Asterisk at all. To monitor extension 203, I just made these changes to Phone tab of the phone used by extension 200:

Notes

• The Extension is Disabled and Shared Call Appearance is private.
• The extension being monitored does not need to be defined on an Ext tab on the “remote” phone. So if the admin is on 200 and is monitoring 203, the admin does not need 203 defined on an Ext tab.
• The Short Name appears next to the line key when the phone is on hook.
• The Extended Function looks like this:
  fnc=blf+sd+cp;sub=203@$PROXY;ext=203@$PROXY
  • blf = Busy Lamp Field
  • sd = Speed Dial
  • cp = Call Pickup

Issues

• The BLF function does work. However, when the line is off hook, the Short Names are not shown. So users would have to remember which line key is for whom, or use physical labels to identify the lines.
• A quick test of transferring a call with the button failed. It could be that that requires some of the Asterisk-side modifications. I didn’t pursue this.
• BLF subscriptions may not be supported by a hosted PBX solution, where you register each extensions directly with the external provider. Since most other functions are available in a hosted solution (e.g. voip.ms), it may come down to whether it is worth running an in-house Asterisk server just to have BLF.

G.729a requires that you purchase a license if you are converting (transcoding) the audio to another codec. Although the licenses are inexpensive, I preferred to avoid the overhead of transcoding by simply passing through the G.729a packets.

“Passing through” means that both legs of the call must use G.729a. At first I hoped to be able to use the standard ulaw (G.711u) codec for all calls except those going to my ITSP. However, I eventually found that if the first leg of a call prefers ulaw, and the second leg requires G.729a, Asterisk will not go back and reinvite the first leg using G.729a (see my comment in this thread). Bottom line:  we need to set up the PBX to use G.729a on all calls, internal and external.

Setting It Up

Once that was clear, the setup was fairly simple:

1. Download the current g729 sound files from Digium:
   asterisk-core-sounds-en-g729-current.tar.gz
asterisk-extra-sounds-en-g729-current.tar.gz
   These are required for the voicemail system to work after converting to G.729.
2. On the Asterisk machine, under /var/lib/asterisk/sounds, rename the en directory to en.gsm.
3. Create a new en directory and extract the new sounds there. Recursively change the group and Owner to asterisk and the permissions to 775 to match the original “en” directory.
4. In the FreePBX admin panel, go to Tools > Config Edit. Add the following lines to sip_general_custom.conf:
   disallow=all
allow=g729
allow=ulaw
allow=alaw
allow=gsm
   That puts g729 as the first priority for the whole system.
5. From the console, open the Asterisk CLI (asterisk –r). Make a call and type sip show channels. You should see the g729 codec on both legs of the call, whether you call internally or externally. Do try all combinations to make sure that G.729a is supported throughout. If not, the call will fail and you’ll see a corresponding message in the log (Tools > Asterisk Logfiles). (Or if you a the G.729a license, the call will succeed but will be transcoded.)

Update:  Still Need to Transcode

November 5, 2011: Alas, not as easy as I thought. The above did set up G.729a pass-through on outbound calls. However, some problems remained:

• Inbound calls through the SPA3102 were still in G.711u format. Since Asterisk tried to use G.729a for the second leg, the call failed without a transcoder. Changing the SPA3102’s Preferred Codec to G729a solved that problem.
• Voicemail greetings are not available in .g729 format. Converting from .WAV to .g729, or even creating new greetings in .g729, seems to require a transcoder.
• Voicemail messages are not stored in .g729. This can be remedied by adding g729 to the list of formats in voicemail.conf, but still seems to have trouble without a transcoder.
• Rod Montgomery, Directory of Services at Digium, writes in this thread that without a transcoder, Asterisk will not be able to process audio, e.g. DTMF codes for IVR and voicemail. I’m not sure about this one—it seemed to handle the DTMF when I called internally anyway.

Bottom line, it still makes sense to set up pass-through for actual phone calls, but there are so many places that audio conversion is needed that it makes sense to get the transcoder. As Mr. Montgomery says in the post linked above, you only need as many licenses as you have simultaneous channels doing transcoding. So if you are making all calls in pass-through mode, you only need a few licenses for receiving and accessing voicemail, and possibly for IVR.

Info on transcoder licensing is available here. For testing purposes, open-source binaries are available here.

I’m setting up a new PBX in a Flash (PiaF) machine running Asterisk 1.4.21.2. I’m testing it by calling in with SJPhone across a VPN (the PiaF machine is at a client site). When I dial 7777, I get my top-level IVR, but when I press a number, nothing happens. If I dial into a voicemail box, the * and # keys have no effect. It seems PiaF is not hearing my DTMF tones at all.

Unexpected Public Traffic

I ran Ethereal to make sure the DTMF digits were being generated, and sure enough, they were. But what’s this? In spite of using a VPN, the RTP traffic was re-routed to the public Internet address, i.e. to 180.12.12.12. Since the hardware firewall in front of the PiaF machine does not allow inbound RTP traffic from the public Internet, no tones were getting through. But how does it even know to re-route the traffic to the external IP?

I remembered that, based on the Part 2 of the setup instructions, the section “Getting Rid of One-Way Audio” calls for the following modification to /etc/asterisk/sip_custom.conf:

externip=180.12.12.12

I don’t really need that now, since I’m only using analog lines. Commenting out the “externip” line does solve the DTMF problem, but what if I want to use a VoIP provider in the future?

Keep It Inside the VPN

A glance at Voip-Info’s Asterisk SIP externip article gave me the clue I needed:  all that is required is to add a second localnet line identifying the IP range of the computers at the other end of the VPN. That allows the RTP traffic to stay inside the VPN, and PiaF was again able to “hear” DTMF digits. So my sip_custom.conf now looks like this:

externip=180.12.12.12
localnet=192.168.1.0/255.255.255.0 ; address range of local computers
localnet=192.168.2.0/255.255.255.0 ; address range of VPN-connected computers

If I decide to add VoIP providers in the future, “all” I’ll have to do is to get the firewall set up to allow external (encrypted?) VoIP traffic.

The system would generate an occasional message “TSC appears to be running slowly. Marking it as unstable.” This issue did not keep the PBX from running.

Voice quality was sometimes jittery. In a call, it would sometimes “cut out” (like a bad cell connection). In voicemail, even listening to the pre-recorded prompts, there was frequently some garbled-sounding audio.

Workarounds

The jittery voice seemed to be a horsepower issue. It’s like it couldn’t read the virtual disk fast enough and/or it couldn’t process the audio stream fast enough.

I was running PiaF under Microsoft Virtual Server 2005. The host was an old Dell Optiplex GX260, a Pentium 4 2GHz with 1GB of RAM. I dedicated 512MB of RAM to the virtual machine.

I found that if I moved the virtual machine to my IBM T60p laptop (T5300 Dual Core), still with 512MB of RAM, the jittery voice problem went away. I still got the “TSC” message, though.

Another workaround is to get Asterisk out of the audio stream altogether. I blogged this here. That solves the problem when two endpoints are talking, but it doesn’t solve the voicemail problem, and it does limit some of Asterisk’s features (call recording and transfer, for example).

Getting Physical

I concluded that I needed to convert to a physical setup to see if I could permanently solve these issues.

I hated to convert my fully-configured Windows XP machine to a dedicated PiaF box. I noticed in the PiaF status window that it was consistently using less than 40% of the 512MB RAM. Could it possibly run on the old Dell PowerEdge 2400 that has been sitting in the garage collecting dust? That’s a Pentium III 733 MHz with a whopping 256MB of RAM. Well, doesn’t hurt to try.

Following the instructions in my earlier posts, skipping the parts relating to virtual machines, I was able to get PiaF installed on the PE 2400 in a little over an hour (it took quite a while to compile Asterisk!). Transferring my setup from the virtual to the physical machine using the FreePBX Backup & Restore functionality was a snap. I forgot the tftp setup at first, but was able to quickly add that, simply copying the contents of /tftpboot from the virtual to the physical machine.

Somewhat to my astonishment, it works great! This old clunker, destined for the free Dell recycling at Staples, now has new life. Even without bridging the audio, the jittery voice is gone. I wouldn’t try this in a large office, but for a home office, it seems fine. In fact, my Kill A Watt tells me that this old PowerEdge only uses about 75 – 90 watts of power, not much more than the Optiplex workstation (53 – 80 watts).

Conclusions

I still love the idea of using a virtual machine for a PBX, and with a strong enough host, it’s probably a viable alternative for production. It’s definitely a great way to test various configurations and features. And if my physical machine fails, I can boot the virtual machine and have phone service again in about three minutes. But based on the hardware I already have and the Asterisk features I like, it looks like I’ll be running physical for now.

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.