Jan. 18, 2012

Well that was a frustrating few weeks. I had planned to do what should have been a straight forward install of an IPv6 enabled Asterisk PBX system, but what sounded simple turned out to be unnecessarily complex, even with the definitive O’Reilly Asterisk book in hand. Some of the complexity was certainly due to installing on a nonstandard hardware configuration, but most of it was due to inconsistent and incomplete implementations by a collection of open-source software packages, combined with incomplete and antiquated examples that simply don't work on current code.

Given that there was a Linksys E3000 sitting here with dd-wrt and optware already installed on it, turning off the Asterisk version included with dd-wrt and putting something more current from optware would appear to be a simple task. Oh if that were only true ... While I wanted to go with the most current Asterisk 10.0, it appears that version has not been built for optware. Taking the most current optware version of Asterisk I could find in mid-December (1.8.7), it turns out that one would crash every time a call connected. After a few days of searching I stumbled across a stray comment on a dd-wrt forum thread stating that res_timing_pthread.so needed to be prevented from loading to resolve that specific crash. That fix seemed to go ok, but after turning that off and trying the web gui configuration interface (which itself hung and required rebooting the box to get control back) there was another strange crash whenever sip.conf would load. Suspecting a corrupted file, I tried to force a clean set of files by selecting -force-overwrite along with -force-reinstall, but despite the time consuming process, half-a-dozen different incantations made no difference. Finally I gave up; uninstalled Asterisk, then manually deleted the associated directories, and did a clean fresh install. While I was stumbling over the res_timing_pthread issue though the available version had changed to 1.8.8 and the old one was removed from the download point, so I was forced to do an 'ipkg-opt update' to get there.

Once loaded that would seem like a point of progress, but once again it was not that simple. Before I tried turning on the web configuration interface again I watched the console during startup and noticed a critical missing link; res_http_post.so was a file that is nowhere to be found in this build. This would seem to make the web gui useless, so I ended up removing the attempt to load it and wrote off all the instructions that required one of the web gui configuration tools (turns out that is most of them). At the same time I noticed that res_srtp.so is also missing from that build, which means I will have to find another way to secure the voice channels. Several threads recommended turning off the module auto-load and using a specific list of modules, but those lists turned out to be incomplete sets, as the first thing that failed was a CUT operation I had in the extensions.conf file, along with a few other functions that really didn’t matter enough for me to remember, as I was going to turn auto-load back on rather than fight with figuring out what was needed to get everything back to where it was again.

Complicating this process on a non-standard hardware configuration was the inclusion of a Linksys 3102 as an FXS/FXO interface to the system. There were lots of examples for integrating Asterisk & the 3102 out there, but I found that none were complete, and most were so old that they were almost useless given the syntax changes in Asterisk, and the updates to the 3102. Stumbling through the dial plans and sorting out which side was parsing what, and how the different logical devices related took a few days. In the end I just wanted the FXS port to act as a simple phone connecting to the pstn, but have the FXO port forward to Asterisk to handle auto-attendant functions and replicate the incoming call across the possible set of SIP clients I might be running, as well as handle outbound calls.

That brings us back to the IPv6 part of the saga. Virtually all of the posts I could find said the only client that had IPv6 implemented was linphone, so that was the place to start. For whatever reason I couldn’t get it to install on OS-X Lion, so I gave up and put that on the W7 VM. Sure enough it was doing IPv6, so one small step ... I put xlite on OS-X Lion to have a second endpoint to call, and to my surprise there were IPv6 packets flying around from it. In fact calls from both clients to user@[2001:local:prefix:1234:56ff:fe78:9abcd] worked without issue. I did try ekiga on W7, but decided it was not worth the time and effort, so that got uninstalled to reduce the clutter.

I had planned to add Skype for Asterisk, but unfortunately Skype dropped that channel last July. There are instructions for alternate access out there, but given the dependencies for those approaches and the limited success in getting the basic functionality working on this box, that is an exercise left for another day, and likely on another box.

With a working set of SIP clients and a pots phone on the FXS port, it was time to add the Google-voice connection. Again there were lots of instructions available, but none were particularly accurate for either the current version at Google or the 1.8.8 implementation of Asterisk. Starting out by creating a Google voice account first rather than a Gmail account just compounded the problems because the Jabber channel appears to require a Gmail address, but setting up a Google-voice account first requires a non-Gmail address. They end up related, but the forward-to function didn't offer the Gmail one when it was the second address. This would further compounded by an inaccuracy in the O’Reilly Asterisk book which stated that the ${EXTEN} variable contains what the user typed, which couldn't be further from the truth. On that point, experimentation shows that ${EXTEN} actually contains the output of the pattern matcher for the current context, which in cases of the goto application or the Google channel, it has nothing to do what the user actually typed. Never mind the inconsistency where the SIP channel parses at and drops the @, while the Google-voice channel passes the string with the @ and domain name included into ${EXTEN}. With enough trial and error though, Google voice does finally work both inbound and outbound for numeric addresses. I haven't had time to test alpha strings, but the config appears to be passing them to Google.

On the 'it would be nice' front; the same capability for other Jabber/XMPP communities would seem to be useful. On the surface it would appear that a channel driver similar to gtalk that connected via something like pidgin would provide a broad array of connectivity for minimal effort. While there are lots of discussions about configuring pidgin as an Asterisk client, there is nothing about using it as a channel. Hopefully someone will find this post and figure out how to add that.

I tried to add the ability to do text-to-speech via a Google API to make the auto-attendant a little less choppy, but Google shut down that service due to abuse shortly before I started this adventure. Microsoft does have a similar service API but the steps necessary to use it are non-trivial so that will have to wait for another day. There are stand-alone TTS options for Asterisk, but they are not available for the optware environment.

There were several times where it seemed it would have been faster to just build directly from source, but given all the headaches involved in configuring existing binaries, the thought of setting up a proper build environment for a cross compile to a Broadcom processor running dd-wrt and figuring out the dependencies was just one more task on a list of things should have been easier to start with. Maybe someday, but setting up the simple auto attendant function has already chewed up the available time.

Along the way, other missing functionality became apparent as the netstat in dd-wrt, optware, and net-tools were all missing IPv6. The only good news is that the current version of netstat in the Busybox (1.10.3) with optware does include IPv6 functionality, as well as its ifconfig implementation. Looking around, many of the components in optware have not been updated for 5 to 10 years, making it a less than viable platform for an up-to-date network.

For anyone that might care, I will include my redacted 3102 & Asterisk configuration files here. Hopefully they will prevent someone else from wasting as much time as I did :::::