Yes, you guessed right: this post is about Open USB FXS interworking with Asterisk. And it does work indeed! After a setup of half an hour, I was able to get Asterisk to recognize the board (the respective Dahdi channel, to be exact), to dial from a phone set attached to the board and to listen some Asterisk voice prompts. Not bad at all, is it?
The environment on which I tested was a Debian lenny system, with some packages installed from sid (the latest unstable Debian version). The main such packages were Asterisk v1.6 and Dahdi v2.2. All related .deb packages were built from the respective source packages. I don’t know if other Asterisk versions work with the dahdi drivers. Maybe not, and the driver needs porting to zaptel as well (if so, it’s not a problem anyway, porting should be trivial).
Of course, there is a list of several serious caveats. To begin with, the voice quality on VMWare is horrible. Probably this is due to the insufficient CPU and I/O resources that the VMWare environment can offer to Asterisk and the driver, which require both real-time priority to work. I haven’t yet tried to run the whole thing under a native Linux. I trust things will be better there, but I promise to report any uncurable issues that I will run into.
The second serious caveat is the plug-and-play nature of a USB device as opposed to the relatively fixed nature of Asterisk and its configuration. When I configured my device under the [phones] section of /etc/asterisk/chan_dahdi.conf (the location may vary in your system) and started Asterisk without the dongle board being plugged in yet, Asterisk managed to get itself a majestic SIGSEGV (or was it SIGABORT? I forget). It does not make sense for the channel driver to insist in working if a configured device does not even have an associated device file on the system (this is exactly the case here). So this segmentation fault is probably a bug, which needs further investigation.
Another issue is that, depending on the order in which more than one Open USB FXS devices are plugged in the system, they may be assigned different channel numbers each time. This will in turn mean that, depending on the order in which a phone is plugged in the system, it may get a different extension number (this is for sure a great feature, don’t you agree? Imagine yourself being a VoiP provider and mixing up customers’ extension numbers each time a device is plugged or removed from the system; wow!…).
An additional yet unresolved caveat is the echo canceller. I have not yet built one into the oufxs driver; that’s not an issue in itself, but it turns out that it is not very easy to write the actual code, because the IN and OUT completion callbacks are asynchronous. So, the event sequence IN(n), OUT(n), OUT(n+1), IN(n+1) is perfectly valid. OK, but now if you think about how to submit the samples of such a sequence to the echo canceller, you ‘ll see that it gets to be a bit tricky.
Believe me or not, none of the above sounds anymore like a real problem to me. The next few days will show, however my project’s biggest goal from its first conception has now been achieved. I am really moved and excited about it, though my writing style probably does not reveal too many emotions. I believe I ‘ll offer myself a few days off the project now (plus the necessary quantity of beer to celebrate it). I am also thinking about writing a dedications page, where I will make sure not to forget that person who, one year from now or so, mailed me asking my phone number, and then called me in order to try to convince me that it was not going to work — “you are not going to get yourself anywhere with the PIC”, was his final argument.