Support for G.729 is a part of trixbox Pro by default, however it is not activated (does not show up in the Admin CP) until a G.729 license has been activated.

G.729 is a codec designed by Digium that can get calls down to around 8kbps (up and down) per call. It is a great alternative to G.711 ULAW which can be up around 80kbps (up and down) per call. G.729 costs $10.00 per license (per active channel), and is available from Digium. (more…)

I have been going through the process of beefing up the trixbox Reseller wiki lately, and I have just added a new article entitled ‘DHCP 101′ which details the configuration of DHCP services on the trixbox Pro.

If you are a trixbox Pro Reseller, but don’t have a logon to the new wiki, please let me know! Based on your permissions, the reseller section will appear or not. http://help.trixbox.com.

Ok, so I’ve been a big fan of both Amazon S3 and JungleDisk for a long time now, and it struck me as the perfect solution to backing up trixbox Pro. By default, only system configuration files are backed up by Fonality’s Hybrid-Hosted model…but what about system recordings, ACD recordings, and voicemails? By utilizing the power of Amazon S3, you can safely and securely back up your trixbox Pro (and with very little cost).

Here’s how it’s done: http://sureteq.com/asterisk/jungledisk.htm

Enjoy!
-Schwood

Hey everyone,

I have just finished a new document detailing the installation and configuration of trixbox Pro v2.0. You can see the new document here: http://sureteq.com/asterisk/trixbox_pro_v2.0.htm

Enjoy! Comments/suggestions are always appreciated!

-Schw00d

Hey everyone,

I just spent the last 3 days at Fonality’s FtOCC Tech certification course right here in sunny Los Angeles. I was pretty excited about this course as I knew that it dealt mainly with trixbox Pro, which I have had next to no experience with so far. I am mainly experienced with the stand-alone CE version of the trixbox product, so it was great to get a good inside view of the other trixbox. (more…)

Ok, so one of the most common requests I get is people complaining about echo. This problem has plagued Asterisk since the beginning, and is one of those annoying types of problems that is intermittant and not the easiest thing to track down.

First things first, if you want to try to completely eliminate echo cancellation from the git-go, do yourself a favor and spend a few extra bucks on a hardware card with a built-in echo cancellation chip. Digium and Sangoma both have models available with a chip from Octasic onboard. Rhino has an echo cancellation daughterboard that can be placed on their T1 cards.

If you already have a hardware card, there are also echo cancellation software modules availabe from Octasic (and others as far as I know…I haven’t heard of any though). These run about $10 bucks USD per channel, and are pretty easy to install (see my other blog post on this topic).

Ok, so what if you already have a card and don’t want to spend any money on software modules, but still want to try to reduce echo? Here’s a few troubleshooting tips.

The first thing I usually do when faced with this problem is try to gauge the extent of the echo problems. I usually try to have the client give me an estimate of how many calls have bad echo in terms of the percentage of total calls. The echo troubleshooting at 10% is much different than it is at 90% echo. At above 50% echo, you most likely have a hardware issue…the primary culprit would be the computer Asterisk/Trixbox is running on. Not enough RAM? CPU too slow for the volume of calls? It’s probably something like that. That’s not the type of echo problem I’m talking about.

I’m talking about the 10-20% type of intermittant echo problem in this blog…this can usually be fine tuned to less than 5% with some adjustment to the Zaptel settings.

The first (and easiest) thing to run is fxotune. This utility analyzes the TDM characteristics of your device and fine tunes them. This is also known as ‘balancing the hybrid.’ I don’t know why.

To run fxotune, do the folloing in the Linux CLI (with Asterisk/Trixbox STOPPED):

fxotune -i 4

This takes 4-5 minutes per Zaptel channel, so be prepared for a little bit of downtime.

The next thing you want to do is run the ztmonitor tool. This can be done at the Linux CLI by running ‘ztmonitor [channel number] -v’. So if you wanted to run it on channel 1 of a T1 card, the command would be ‘ztmonitor 1 -v’. You will see a graph on the screen which shows the Tx and Rx (transmit and receive) volume of a call.

It should look something like this:

Visual Audio Levels.
——————–
Use zapata.conf file to adjust the gains if needed.

( # = Audio Level * = Max Audio Hit )
<----------------(RX)----------------> <----------------(TX)---------------->
* ########### *

The level of the audio (while a call is in progress…if the line is on the hook, you’re not gonna get any levels…drrrr) is marked by the pound signs (###). The peak level is marked by an asterisk (*). There can be two problems here that lead to echo. The gain (volume) is too high, or too low. If you are watching a call in progress, and the peak is all the way to the right, you need to reduce your gain. If the levels are barely registering, you need to boost your volume. In general, you want the level to be right in the middle (on average)…I use the (RX) and (TX) labels on the graph as my desired average point.

The Zaptel echo and gain settings are in /etc/asterisk/zapata.conf. By default, they look like this:

echocancel=yes
echocancelwhenbridged=no
echotraining=800
rxgain=0.0
txgain=0.0

First, let’s deal with the gain. If you’re too low on Rx or Tx, try to boost it by 2.0db like this:

echocancel=yes
echocancelwhenbridged=no
echotraining=800
rxgain=2.0
txgain=2.0

The rxgain and txgain settings go from -100.0 to 100.0…but you never want to adjust them more than 10.0db either direction (usually no more than 5.0db). So make a call, run ztmonitor, and then watch the levels again. They should be a little bit higher. You can keep adjusting the Rx and Tx levels until they are at the midpoint average of the graph. Keep in mind that not ALL calls are gonna be perfect, but this should give you a good general idea. Also, keep in mind that the Rx and Tx levels can be adjusted individually. Let’s say that you feel your Rx (receive) volume is too low, but your Tx (transmit) volume is too high…your settings may look like this:

echocancel=yes
echocancelwhenbridged=no
echotraining=800
rxgain=3.0
txgain=-2.0

(Note that the Tx gain is set to -2.0. Sometimes the minus sign is hard to see).

Having the appropriate gain levels will usually do the trick when it comes to echo cancellation, but you may want to adjust the echo settings as well…here is what they do:

echocancel=(yes/no) – This turns on/off the Zaptel echo cancellation.
echocancelwhenbridged=(yes/no) – This turns on/off the echo cancellation when on a bridged call. It is best to keep this off.
echotraining – this is the amount of time Asterisk uses to try to ‘learn’ echo on a line. I usually set this to 128 instead of the default 800.

If you still have echo…buy a legacy PBX.

-Schw00d

It seems that a2billing is no longer a part of Trixbox. It is not installed by default, and I wasn’t able to locate it in the package manager. I have now released instructions for manually installing a2billing v1.2.3 in Trixbox v2.2. I will be updating my configuration instructions for the latest Trixbox version shortly.

Click here for installation instructions.

-Schw00d

Hey everyone,

I have updated my documentation to the latest version of Trixbox.

Trixbox v2.2 Complete Setup Guide

Enjoy!

-Schw00d

One thing that I have found with the default voicemail configuration is that the sound files delivered to my email address have a very low volume level. If you are receiving voice mails via email to a cell phone, you can’t even hear it. To fix this and boost the voicemail to email attachment volume, do the following:

First, let’s boost the gain by going to Setup –> General Settings in FreePBX. Under the Voicemail section, change ‘Use gain when recording the voicemail message (optional)’ to 6.0. Click ‘Submit’ followed by the red bar to apply changes.
The next thing we can do is change the voicemail to email attachment format. There are two flavors of attachment…WAV and WAV49. It defaults to WAV49 to save file size, but let’s change it to WAV. From the Linux CLI, do the following:

cd /etc/asterisk
nano vm_general.inc

Change

format=wav49|wav

to

format=wav|wav49

CTRL+X to exit and then Y when asked to save.

Also note in the same file the ’serveremail=’ field…this is the ‘from’ address of the voicemail emails. Change it to something that matches your organization or domain.

If you have worked with Asterisk/Trixbox for any length of time, you have dealt with codecs. You’ve seen terms thrown around such as ulaw, alaw, G711, G729, and on and on and one. But what are these? And what are the differences between them? When should use use G726 instead of ulaw? What codecs are even possible in Trixbox? I’ll try to clear some of this up.

For VoIP communication, you need to start with a protocol. The three big protocols are SIP, IAX2, and H323. SIP and IAX2 are natively supported in Trixbox’s version of Asterisk (v1.2), so I’m going to assume that you’re using one of these. Once you have your protocol in place, a codec tells the system what format to send the calls across the protocol.

Codecs are used to convert an analog voice signal to digital. They vary in sound quality and bandwidth consumption. Typically, the better the sound quality, the more bandwidth consumed…the less bandwidth consumed, the worse the sound quality. Here are the codecs currently supported in Asterisk v1.2:

ulaw – AKA G.711 – 64Kbps – ulaw is the standard US codec for uncompressed voice. For internal extension to extension calls, this is the preferred codec. Notice the 64Kbps? This is how much bandwidth is consumed by this codec. When thinking about bandwidth consumption, I like to think in terms of phone lines…a typical phone line (or T1 channel) is 56Kbps (remember the days of modems??). ulaw is just a little higher than that. If your Internet connection is a modem, you would want a more compressed codec. If you have 768Kbps up/down DSL, you should be able to run 12 ulaw calls across the connection (768Kbps / 64Kbps = 12). That is typically not recommended however, and with other Internet stuff going on, that number gets reduced significantly. If a client told me they had a 768Kbps connection, I would tell them not to expect good voice quality on more than 3-4 simultaneous calls with ulaw and that connection.

alaw – AKA G.711 – 64Kbps – alaw is the same as ulaw, but it is the European standard codec.

G.723.1 – 6.3Kbps or 5.3Kbps – This is the standard codec used by H323. Since I’m not talking about H323, I’ll skip this one.

G.726 – 32 Kbps – G726 is a good alternative to ulaw when you need to save some bandwidth. It consumes 1/2 the amount of bandwidth of ulaw, and the voice quality isn’t degraded much.

G.729 – 8Kbps – The G729 codec is excellent, but there is a trade-off. It has very low bandwidth consumption and decent voice quality, however it also has a dark side in that it isn’t free. G.729 licenses are available from Digium at the cost of $10.00 per channel. They also take a significant amount of CPU power to process the compression. Installation requires a purchased license from Digium, and you have to download and run their registration program…it is pretty easy to do, but is still an additional step. Plus, it bases the registration on the MAC address of the computer it was installed on, and is only transferrable once (and you have to contact Digium to do it). This is a good codec, but try G.726 or GSM first.

GSM – 13Kbps – GSM is a codec that comes from cell phone technology. It has pretty low bandwidth consumption, but you will notice lower voice quality than a standard PSTN line.

iLBC – 13.33Kbps – iLBC is another low-bandwidth codec. They claim better quality than G729, but I haven’t had much experience with them…I don’t know if that is a true statement or not.

Speex – configurable 4-48Kbps – Speex is another less-known codec. It’s advantage is that it is flexible (4Kbps to 48Kbps) in terms of bandwidth consumption, but it takes up more CPU than even G.729. Again, I have never used this codec, so I don’t know much more about it.

I hope that helps clear codecs up a bit. My general rule of thumb is to use ulaw if there aren’t any bandwidth constraints. If bandwidth is a consideration, I then try G.726 and GSM in that order. If a customer is jazzed about G.729, I have no problem using that as well (although I don’t think it offers enough advantage over G.726 or GSM to be worth $10 bucks).

-Schw00d