Hello, Asterisk!

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.

Advertisements

10 Responses to “Hello, Asterisk!”

  1. Alok Says:

    wow….Great Work…. Congratulation for the greatest achievement..!!
    Take break now :-)..

  2. Marc Abrams Says:

    Hi,

    You should look at David Rowe’s OSLEC. It is an open source echo canceler and works well with Asterisk.

    See: http://www.rowetel.com/ucasterisk/oslec.html

    Do you have plans to implement an FXO or ISDN BRI version for USB ?

    marc.

  3. Angelos Varvitsiotis Says:

    Thanks Alok!

    Yes, I ‘m going to take a short rest for the next few days. I think I both need and deserve it!

    Cheers,

    Angelos

  4. Angelos Varvitsiotis Says:

    Hi Marc,

    Thanks for pointing me to OSLEC. I am well aware of it (BTW, David Rowe who has (co-)authored OSLEC is the person who has inspired the whole Open USB FXS effort). I have plans to include it anyway into the driver, since from what I hear OSLEC outperforms by far Asterisk’s own echo canceller. However, the issue I am having is not exactly related to the choice of an echo canceller. Every echo canceller must be invoked with a consistent set of “taps” each of which is sampling data with a fixed time difference between the send and the receive streams. Due to the nature of USB I/O and to some details in my driver, I ‘m having some trouble in keeping this time consistency. Nothing that cannot be overcome, anyway, but it requires some more effort (more details are to follow in the blog).

    As to your questions: no, I am not planning to provide an ISDN interface. It looks very complicated to me, I fear that the PIC won’t have enough processing power to handle it, and I am not sure it is worth the trouble anyway. I am however considering the possibility to add an FXO port to Open USB FXS (after which it will be named something like “Open USB ATA” :-)). A cheaper alternative might be to include a “bypass” FXO port. This won’t be a true FXO port, so Asterisk won’t be able to talk to the telecom provider over the line. All that this board would do is use a bistable relay (in order to keep current consumption low) to switch the phone set between the Asterisk FXS port and the PTT line. The board could be also smart enough to pass some sort of a “busy” signaling (e.g., off-hook) to Asterisk while the FXS port is switched to the PTT line.

    Anyway, all the above are just thoughts and there is not any sort of commitment that I can (or am willing) to make at this point. Note however that Open USB FXS is an open hardware project. Everyone might take the schematic and the firmware (which I am going to publish shortly) and produce a dual FXS/FXO port or a “FXO bypass” board out of that.

    I would like to thank you once more for your suggestion and your interest in the project.

    Cheers,

    Angelos

  5. Federico Briata Says:

    Hi Angelos,

    that’s a grate work!!
    I’m wondering how would work on Gnu OpenWRT!!

    Are you selling a disassembled Kit?

    King regards,
    Federico

  6. Angelos Varvitsiotis Says:

    Hi Federico,

    Thanks for your kind words. I am not sure how well Open USB FXS is going to perform on any specific platform. I think that the best way is to try it out. Currently, I am not yet selling any form of the board, neither ready made boards, nor kits. Soon however, I am considering offering a limited number of boards and kits at the bare cost of materials. I will post details on the blog, as soon as I verify the latest Open USB FXS dongle design, especially w.r.t. some heat dissipation issues that the previous board showed.

    Cheers,

    Angelos

  7. sal Says:

    GREAT NEWS!!!! I am trying to find a spare time to recompile the basket from mouser…

  8. David Rowe Says:

    Hi Angelos,

    Hey, congratulations on that First Phone Call milestone. It’s a very special moment in the life of any telephony project. You have worked hard and overcome some very tricky bugs. What you have achieved with a PIC is pretty cool.

    I can think of lots of cool applications for an open hardware/software USB FXS device, for example hooking one up to a Wifi router would make a Mesh Potato like box.

    Yes with Oslec the key issue is getting precise time alignment between the TX and RX data streams. This is the number one problem I get on the Oslec mailing list when people try to use Oslec with their own drivers or hardware. Jitter in the arrival time of USB sample packets can be taken care of with some software FIFOs at the expense of a little delay.

    Congratulations 🙂

    Cheers,

    David

  9. Angelos Varvitsiotis Says:

    Hi Sal,

    Yes, this would be great! Thanks!

    Cheers,

    Angelos

  10. Angelos Varvitsiotis Says:

    Hi David,

    Thanks a lot for your comment and for your kind words. Indeed, there are a number of people interested in applications like the one you are describing. Nowadays, some DSL/Wireless router boxes based on Linux already come equipped with an on-board FXS port; however, it may be cheaper to use an inexpensive external USB device, and it sure adds lots of versatility if one already has a DSL/Wireless box with USB boxesports but no built-in FXS port. Mobility and field testing (e.g., test an already-installed Asterisk box without interrupting its normal operation by installing boards etc.) are two other important applications. People might think of others as well.

    Alignment of TX/RX streams is in fact a bit tricky. Here is an example detail: in dahdi, the channel driver and the device driver operate 100% asynchronously. In the absence of downstream TX data (PBX to device), the dahdi-base core feeds the device driver with PCM silence data (0x7F’s). This is transparent, i.e., the device driver cannot really tell if it is receiving genuine data or artificial silence. I am not quite sure what happens in case of delayed data or jitter: is delayed data delivered after a “silence” chunk is inserted (this would increase the user-perceived delay during the lifetime of a call), or does delayed data get overwritten by new data? Or both (which seems like the best choice: queue up to a bit and then overwrite to avoid increasing the delay over a limit)? In any case, my guess is that the thing requires much study and thought, and just a few lines of code. Because of the asynchronous nature of USB, the delay that you are talking about already exists: the driver already queues some samples to be submitted to the device, so no additional fifo is needed. One could just track older samples and use a simple counter to synchronize the two streams. Again, some thinking is required, but I have promised myself I would pass one mindless and worryless week off such activities. I am sure it will work in the end, and OSLEC will perform great!

    Thanks again for all your active support through the lifetime of the Open USB FXS project!

    Cheers,

    Angelos

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: