Troubleshooting trixbox CE
From TroubleshootingWiki
| Official Page |
| Project Documentation |
| Download |
|
One of the most important skills you can develop if you are going to install and manage trixbox CE systems is good troubleshooting.
Although this tutorial will give you a basic background in troubleshooting common problems, you should still take the time to become familiar with general troubleshooting of common Linux problems such as networking, hard disk maintenance, command-line tools, and package management. With the information in this tutorial, you should be able to work through the most common problems that you are likely to encounter.
Contents |
Getting to know Asterisk
Since Asterisk is the engine under the hood, you need to know how to get under the hood and see what it's doing and use Asterisk's CLI (Command Line Interface) to help troubleshoot connections to devices and service providers. To access the Asterisk CLI, we need to log in to the console or SSH into the system using a tool like Putty. Once logged in, we access the Asterisk CLI with the asterisk r command.
When we do this, we should get a screen like the following example:
[trixbox1.localdomain ~]# asterisk -r Asterisk 1.4.21.2-2 RPM by vc-rpms@voipconsulting.nl, Copyright (C) 1999 - 2008 Digium,Inc. and others. Created by '''Mark Spencer''' <markster@digium.com> Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details. This is free software, with components licensed under the GNU. General Public License version 2 and other licenses; you are welcome to redistribute it under certain conditions. Type 'core show license' for details. Connected to Asterisk 1.4.21.2-2 RPM by vc-rpms@voipconsulting.nl currently running on trixbox1 (pid = 2755) Verbosity is at least 3 trixbox1*CLI>
Once in the CLI, we can always type help for a list of available commands. While this list is quite long, we don't need to understand each and every command, but there are quite a few that will help us to diagnose and troubleshoot problems. This section will break down the commands by category so we can get to know when we will need specific sets of commands.
Stopping, restarting, and reloading Asterisk
Often we need to stop or restart asterisk or to tell Asterisk that we want it to reload its configurations. The main thing is to understand how to do this properly so that you don't cause even more problems for yourself. With trixbox CE, Asterisk runs as the user 'asterisk', so if you simply try to start Asterisk from the Linux command line, it will run as the root user, and all kinds of things will get funky and not work properly. To avoid these issues, make sure to always start and stop Asterisk using the information listed below.
To stop, start, or restart Asterisk, we want to be at the Linux command prompt to issue the following commands:
- amportal stop: This command will stop Asterisk immediately
- amportal start: This command will attempt to start up Asterisk properly
- amportal restart: This command will stop and restart Asterisk properly
If we are in the Asterisk CLI, there are a few commands that we can use depending upon what we are trying to accomplish; these commands are:
- reload: Using the reload command will tell Asterisk to reload all of its configuration files
- restart gracefully: This command will stop any new calls from being processed and will restart Asterisk when any current calls complete
- restart now: All calls will be immediately dropped and Asterisk will restart immediately
- restart when convenient: Asterisk will wait until there is no call volume before restarting
- stop gracefully: This command will stop any new calls from being processed and will stop Asterisk when any current calls complete.
- stop now: All current calls will be terminated and Asterisk will shut down immediately
- stop when convenient***: Asterisk will wait until there is no call volume before stopping
After issuing any of the stop commands, you will need to run amportal start to properly start Asterisk back up again.
General channel information
We often need to see if there are any calls in progress and what the status of those calls is. For this, we use the core show channels and core show channel commands. Let's take a look at what these commands will show us. The core show channels command will list all of the current channels that are in use on the system. The following is an example of the output from this command:
Channel (Context Extension Pri) State Appl. Data SIP/vitelity-081c0498 (incoming 1) Up Bridged Call SIP/300-b7300470 SIP/300-b7300470 (internal 913108614300 5) Up Dial SIP/vitelity/13108614300 2 active channels 1 active call
In this example, we have one channel going to our VoIP service provider and another channel connected to extension 300. Once we have this information, we can use the core show channel command to get information specific to a channel. The following example shows how we can do this:
trixbox1*CLI> core show channel SIP/300-b7300470
General
| Name: | SIP/300-b7300470 |
| Type: | SIP |
| UniqueID: | 1223299945.196 |
| Caller ID: | 9495557819 |
| Caller ID Name: | Kerry Garrison |
| DNID Digits: | 913108614300 |
| State: | Up (6) |
| Rings: | 0 |
| NativeFormat: | 4 |
| WriteFormat: | 4 |
| ReadFormat: | 4 |
| 1st File Descriptor: | 33 |
| Frames in: | 1022 |
| Frames out: | 1028 |
| Time to Hangup: | 0 |
| Elapsed Time: | 0h0m23s |
| Direct Bridge: | SIP/vitelity-081c0498 |
| Indirect Bridge: | SIP/vitelity-081c0498 |
PBX
| Context: | internal |
| Extension: | 913108614300 |
| Priority: | 5 |
| Call Group: | 2 |
| Pickup Group: | 2 |
| Application: | Dial |
| Data: | SIP/vitelity/13108614300 |
| Blocking in: | ast_waitfor_nandfds |
Variables
| BRIDGEPEER= | SIP/vitelity-081c0498 |
| DIALEDPEERNUMBER= | vitelity/13108614300 |
| DIALEDPEERNAME= | SIP/vitelity-081c0498 |
| EXTENSION= | 200 |
| SIPCALLID= | 6fa08e69300ef9c6 |
| SIPUSERAGENT= | Aastra 35iCT/2.1.0.2145 |
| SIPDOMAIN= | 10.10.20.200 |
| SIPURI= | sip:00085D10BD1A@192.168.5.159:5060 |
CDR Variables:
| level 1: | clid="Kerry Garrison" <9495557819> |
| level 1: | src=9495557819 |
| level 1: | dst=913108614300 |
| level 1: | dcontext=internal |
| level 1: | channel=SIP/00085D10BD1A-b7300470 |
| level 1: | dstchannel=SIP/vitelity-081c0498 |
| level 1: | lastapp=Dial |
| level 1: | lastdata=SIP/vitelity/13108614300 |
| level 1: | start=2008-10-06 06:32:25 |
| level 1: | answer=2008-10-06 06:32:28 |
| level 1: | end=2008-10-06 06:32:28 |
| level 1: | duration=0 |
| level 1: | billsec=0 |
| level 1: | disposition=ANSWERED |
| level 1: | amaflags=DOCUMENTATION |
| level 1: | uniqueid=1223299945.196 |
Troubleshooting SIP extensions and trunks
In most cases, you will be using SIP devices as your endpoints, and knowing how to use Asterisk to provide information on your extensions is one of the most valuable tools available. For SIP trunks to VoIP service providers, a similar set of tools will help troubleshoot those connections. The following is a list of SIP-related Asterisk CLI commands:
| sip set debug | enable SIP debugging |
| sip set debug ip | enable SIP debugging on IP |
| sip set debug off | disable SIP debugging |
| sip show channels | list active SIP channels |
| sip show channel | show detailed SIP channel info |
| sip show peers | list defined SIP peers |
| sip show peer | show details on specific SIP peer |
| sip show registry | list SIP registration status |
SIP extensions are referred to as 'peers', so these are the commands we will use to look at the status of our extensions. The sip show peers command will give us a list of these peers and some additional information that we can use. Let's take a look at this command to see what it does.
| Name/username | Host | Dyn | Nat | ACL Port | Status |
|---|---|---|---|---|---|
| 301 | (Unspecified) | D | N | 0 | UNKNOWN |
| 300 | (Unspecified) | D | N | 0 | UNKNOWN |
| 204/204 | 192.168.5.248 | D | N | 5060 | OK (10 ms) |
| 203/203 | 192.168.5.145 | D | N | 5060 | OK (21 ms) |
| 202 | (Unspecified) | D | N | 0 | UNKNOWN |
| 200/200 | 192.168.5.244 | D | N | 5060 | OK (61 ms) |
6 sip peers [Monitored: 3 online, 3 offline Unmonitored: 0 online, 0 offline]
In the first column we see the name of the peer and the username that was used to authenticate into the peer; with extensions, this should show the extension number for both name and username. In the second column we see the IP address that the connection came from. The third column tells us if the IP address was dynamic or not. The fourth column tells us if Nat was enabled or not. The next column gives us the UDP port that was used to connect to the peer. The final column gives us a status of the peer; if the status is OK, then it gives us a report on the connection speed to that peer. Anything above about 150ms is most likely going to cause you problems with poor call quality.
If you have SIP trunks then you will also see entries in there for these connections as well; the following is an example of what a SIP trunk will look like:
| Name/username | Host | Dyn Nat | ACL Port | Status |
|---|---|---|---|---|
| vitelity/kerryg_demo | 64.2.142.28 | N | 5060 | OK (98 ms) |
1 sip peers [Monitored: 1 online, 0 offline Unmonitored: 0 online, 0 offline]
Here we see much of the same information, but because the name is not an extension number, we know that this is a trunk instead of an extension. Using the sip show peers command, we can quickly see if an extension or trunk is connected or not. If we are expecting the device or trunk to be connected and it is not, we need to take further troubleshooting steps.
For most SIP trunks (ones that require a registration), we use the sip show registry command to see the registration status. An example of this command in use is as follows:
| Host | Username | Refresh | State |
|---|---|---|---|
| inbound3.vitelity.net:5060 | kerryg_demo | 45 | Registered |
| proxy01.sipphone.com:5060 | 17476060900 | 105 | Registered |
| beta.teliax.com:5060 | kerry_test | 105 | Auth Sent |
This shows us the host we are trying to connect to along with the port we are trying to connect on, the username we are trying to use to register with, the registration interval time, and the current state of the registration attempt. Anything other than Registered indicates a problem somewhere. This could be as simple as a typo in the host name, username, or password.
If we need to start troubleshooting an extension or trunk, the next command we will want to get to know is the sip set debug command. In order to filter out clutter, it is best to issue the command to look only at messages to/from a specific IP address. If we are having problems with a particular device, this will let us only see messages that are relevant. If we wanted to only look at messages related to IP address 192.168.5.5, we would use the following command:
sip set debug ip 192.168.5.5
When everything is working properly, and an extension attempts to register and does so successfully, we should see several pages of information that will tell us what is happening. A typical registration attempt will start with a registration request like the following:
<--- SIP read from 192.168.5.5:5060 ---> REGISTER sip:192.168.5.135;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 192.168.5.5:5060;branch=z9hG4bK-d8754z-d9aeed14276a5752-1---d8754z-;rport Max-Forwards: 70 Contact: <sip:200@192.168.5.5:5060;rinstance=8cb51e856b641bf9>;transport=UDP To: <sip:200@192.168.5.135>;transport=UDP From: <sip:200@192.168.5.135>;transport=UDP;tag=89156d04 Call-ID: ODY1NjllMWYyNjc2NTZhY2JiZDMwZDYzMTkyODg2Y2Q. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO User-Agent: Zoiper for Windows rev.1105 Allow-Events: presence Content-Length: 0
If all goes well, it should end with a success message that looks like the following example:
<--- SIP read from 192.168.5.5:5060 ---> SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.5.135:5060;branch=z9hG4bK784cfde1;rport=5060 Contact: <sip:200@192.168.5.5:5060> To: <sip:sip:200@192.168.5.5:5060>;tag=e568af7d From: "Unknown"<sip:Unknown@192.168.5.135>;tag=as166248a0 Call-ID: MTgyZTVlYzhkMzZjNTQ3YWU3ZTllMGQzNDE0NDJlMjY. CSeq: 102 NOTIFY User-Agent: Zoiper for Windows rev.1105 Content-Length: 0
One of the most typical problems with an extension or trunk not registering properly is a bad username or password. We can tell that we have a problem such as that if we get a Forbidden (Bad auth) message; an example of a bad password message is shown here:
<--- Transmitting (NAT) to 192.168.5.5:5060 ---> SIP/2.0 403 Forbidden (Bad auth) Via: SIP/2.0/UDP 192.168.5.5:5060; branch=z9hG4bK-d8754z-b12d43225da8e917-1---d8754z-; received=192.168.5.5; rport=5060 From: <sip:200@192.168.5.135>;transport=UDP;tag=ff4c6533 To: <sip:200@192.168.5.135>;transport=UDP;tag=as716b551a Call-ID: NWEwNWM1MmI5MzlmZjhmZTQ5ZGMxMGNlNzMzNGUyYmM. CSeq: 2 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0
By being able to analyze our sip debug messages, we can begin to figure out what kind of problem we are having and take steps to correct it.
Troubleshooting IAX2 extensions and trunks
If you are using IAX2 extensions, there are also commands for looking at these types of connections. The iax2 show peers command is similar to the sip show peers command with just a few minor differences. The following is an example showing an inbound and outbound IAX2 trunk as well as an IAX2 extension connected:
| Name/Username | Host | Mask | Port | Status |
|---|---|---|---|---|
| vitel-outbound/ | 64.2.142.18 | (S) 255.255.255.255 | 4569 | OK (130 ms) |
|- |vitel-inbound/t |64.2.142.28 |(S) 255.255.255.255 |4569 |OK (138 ms) |- |303 |192.168.5.5 |(D) 255.255.255.255 |4569 |OK (72 ms)
3 iax2 peers [3 online, 0 offline, 0 unmonitored]
We can see the name/username as before, the trunk that has a static IP unlike the extension, which is dynamic, the netmask of the IP address, the UDP port that was used to connect, and the status and connection speed.
We can also look at the registration of IAX2 trunks using the iax2 show registry command. An example of this is shown as follows:
| Host | dnsmgr | Username | Perceived | Refresh | State |
|---|---|---|---|---|---|
| 64.2.142.28:4569 | N | tech_demo | <Unregistered> | 60 | Rejected |
In this case we can see that the trunk is not registered because the registration was rejected. Debugging IAX2 connections is a little trickier than SIP connections due to the type of information that is outputted. If we issue the iax2 set debug command to turn on IAX2 debugging, we can force a re-registration attempt by reloading the IAX2 configurations with the iax2 reload command. What we get in the case of this particular failure is shown here:
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: REGREQ Timestamp: 00008ms SCall: 05520 DCall: 00000 [64.2.142.28:4569] USERNAME : tech_demo REFRESH : 60 Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: POKE Timestamp: 00008ms SCall: 02609 DCall: 00000 [64.2.142.18:4569] Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: POKE Timestamp: 00008ms SCall: 03170 DCall: 00000 [64.2.142.28:4569] Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: PONG Timestamp: 00008ms SCall: 00023 DCall: 02609 [64.2.142.18:4569] Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: REGREJ Timestamp: 00007ms SCall: 00020 DCall: 05520 [64.2.142.28:4569] CAUSE : Registration Refused CAUSE CODE : 29
The Cause Code of 29 indicates that this is a 'Facility Rejected' error meaning we probably have something wrong with our login or password. Although it isn't easy to figure out what the cause codes are, the cause text is usually going to put you on the right track to figure out your issue.
Troubleshooting zap channels
Zap channels are used when dealing with TDM cards (analog lines or PRI circuits) and are always active, unlike a SIP trunk, which is only available when it is actually in use. If we use the zap show channels command, we can see all of the channels that are currently available. This example shows the output from a Digium TDM400 with two FXO modules and one FXS module configured:
| Chan Extension | Context | Language | MOH Interpret |
|---|---|---|---|
| pseudo | default | en | default |
| 1 | from-zaptel | en | default |
| 2 | from-zaptel | en | default |
| 3 | from-internal | en | default |
Whether a call is in progress or not, we can use the zap show channel command to look at a specific channel. If we have a call in progress on zap channel 1, we can use zap show channel 1 to see detailed information about the channel. The following example shows the typical information available during a call:
Channel: 1 File Descriptor: 13 Span: 1 Extension: Dialing: no Context: from-zaptel Caller ID: Calling TON: 0 Caller ID name: Destroy: 0 InAlarm: 0 Signalling Type: FXS Kewlstart Radio: 0 Owner: Zap/1-1 Real: Zap/1-1 Callwait: <None> Threeway: <None> Confno: -1 Propagated Conference: -1 Real in conference: 0 DSP: yes Relax DTMF: no Dialing/CallwaitCAS: 0/0 Default law: ulaw Fax Handled: no Pulse phone: no Echo Cancellation: 128 taps unless TDM bridged, currently ON Actual Confinfo: Num/0, Mode/0x0000 Actual Confmute: No Hookstate (FXS only): Offhook
To get a quick look at the status of the TDM boards you have installed in your system, you can use the zap show status command. On the same TDM400, here is the output from this command:
| Description | Alarms | IRQ | bpviol | CRC4 |
| Wildcard TDM400P REV E/F Board 1 | OK | 0 | 0 | 0 |
Troubleshooting VoIP problems
There are several common problems you are most likely to run into, especially when dealing with extensions that are off-site from the main location or dealing with VoIP service providers.
The two most common issues are phones losing registration and users getting one-way audio. Some people will say that the only way to solve this is to use IAX2 for extensions, but a proper setup of your system and network will get regular SIP devices working properly virtually every time.
The first thing we need to know is that SIP extensions and trunks use specific UDP ports, so you will need to make sure that your firewall is not blocking or modifying these ports. The table below shows the different ports that need to be available:
| Protocol | Type | Port Range |
|---|---|---|
| SIP | UDP | 5060 - 5061 |
| RTP (for SIP calls) | UDP | 10,000 20,000 |
| IAX2 | UDP | 4569 |
To make sure our trixbox CE system is set up properly, we need to edit the /etc/asterisk/sip_nat.conf file and make sure we have it set up properly for our network.
From the Linux command line,type nano /etc/asterisk/sip_general_custom.conf.
We need to have an externip setting that correlates to the public IP address that we are using (go to http://whatismyip.com, or look on the System Status page on your trixbox CE system, for your public IP address), a nat setting if we are using network address translation (setting to yes is just a safe default), and a localnet setting that describes the local network the trixbox CE system is on. A typical configuration may look like the following example:
- externip=10.10.1.170 edit to match your public IP address
- nat=yes
- localnet=192.168.2.0/255.255.255.0 edit to match your local network
If you are having issues with inbound calls not coming into your system, or you have remote phones that are losing registration at times, you will want to use the port forwarding feature of your firewall to route the ports listed in the previous table to your phone system or remote endpoint.
With VoIP trunks, we may often come across call quality issues that we need to figure out; this will typically manifest itself as jitter, pops, dropped speech, and sometimes as echo. Before even setting up a VoIP circuit you can determine if your internet access is likely to even support VoIP calls, by using the same techniques.
To begin, we can use the Linux ping command to simulate the same type of traffic that a typical voice call would use. To do this, we can use the following parameters:
ping i 0.02 s 270 c 500 <hostname>
We can also create multiple instances of the command running at the same time by stringing the commands together with an & symbol. If we wanted to simulate five simultaneous calls to Vitelity, we would use the following command:
ping -i 0.02 -s 270 -c 500 inbound3.vitelity.net&ping -i 0.02 -s 270 -c 500 inbound3.vitelity.net&ping -i 0.02 -s 270 -c 500 inbound3.vitelity.net&ping -i 0.02 -s 270 -c 500 inbound3.vitelity.net&ping -i 0.02 -s 270 -c 500 inbound3.vitelity.net
While this is running, we will be seeing data flow down the screen that looks like the following example:
278 bytes from 64.2.142.28.ptr.us.xo.net (64.2.142.28): icmp_seq=498 ttl=52 time=54.6 ms 278 bytes from 64.2.142.28.ptr.us.xo.net (64.2.142.28): icmp_seq=499 ttl=52 time=53.9 ms 278 bytes from 64.2.142.28.ptr.us.xo.net (64.2.142.28): icmp_seq=500 ttl=52 time=59.7 ms
What we are looking for is the last item on the line (time=...) not to vary very much; strange spikes in the time number can indicate a potential problem.
Once the command completes, you will get a summary of the information like this:
500 packets transmitted, 499 received, 0% packet loss, time 11062ms rtt min/avg/max/mdev = 51.606/56.385/69.116/3.261 ms, pipe 4
On the first row we are looking to see if we are getting any packet loss; even a single packet loss during a phone call can be heard and any constant packet loss will make the call quality basically intolerable. On the second line we want to look at the second and third number in the sequence. The second number is the average ping time, which we want to be nice and low, while the third number is the maximum ping time, which we not only want to be low, but to be fairly close to the average so that we know we are not getting wild swings in the numbers.
If you are experiencing issues, it can be helpful to figure out where those issues may be coming from. One of the best tools for this is mtr (Matt's traceroute), which will give us a look at the path between us and the remote connection and tell us what it thinks is happening along the way.
We can use mtr the same way as we used the ping command. Let's take a look at the output from a typical mtr command:
mtr -i 0.02 -s 270 -c 500 inbound3.vitelity.net My traceroute [v0.72] trixbox1.localdomain (0.0.0.0) Mon Oct 6 08:31:29 2008 Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
| Host | Loss% | Snt | Last | Avg | Best | Wrst | StDev |
|---|---|---|---|---|---|---|---|
| 1. 10.71.128.1 | 0.0% | 19 | 7.4 | 8.4 | 7.1 | 13.8 | 1.8 |
| 2. ip68.oc.oc.cox.net | 0.0% | 19 | 9.8 | 8.3 | 6.2 | 11.8 | 1.4 |
| 3. ip68.oc.oc.cox.net | 0.0% | 19 | 8.5 | 9.9 | 7.3 | 19.0 | 3.1 |
| 4. ip68.oc.oc.cox.net | 0.0% | 19 | 10.1 | 9.4 | 7.7 | 13.4 | 1.7 |
| 5. ip68.oc.oc.cox.net | 0.0% | 19 | 9.5 | 10.4 | 6.6 | 18.7 | 4.0 |
| 6. langbbr01la.cox.net | 0.0% | 19 | 12.2 | 10.8 | 8.2 | 15.8 | 2.1 |
| 7. cr1.lay.savvis.net | 5.3% | 19 | 9.0 | 11.9 | 9.0 | 16.9 | 2.0 |
| 8. cr2.dv.savvis.net | 0.0% | 19 | 66.7 | 52.9 | 49.8 | 66.7 | 3.9 |
| 9. dcr2.Denver.savvis.net | 0.0% | 19 | 50.2 | 52.3 | 50.0 | 57.4 | 2.2 |
| 10. 208.172.161.178 | 0.0% | 19 | 42.0 | 42.7 | 40.4 | 45.3 | 1.1 |
| 11. border8.den.pnap.net | 0.0% | 19 | 44.6 | 44.2 | 41.2 | 54.9 | 3.1 |
| 12. 69.25.215.226 | 0.0% | 19 | 58.9 | 55.2 | 52.0 | 64.2 | 3.5 |
| 13. 64.2.142.28. us.xo.net | 0.0% | 19 | 53.7 | 55.2 | 53.1 | 64.5 | 3.1 |
From this example, we can see that hop #7 looks to be dropping packets. If this was my connection, I would call Cox and report a problem between its connect and Savvis. It may not get it resolved right away, but continually opening tickets with a provider when you see a problem like this is often the only way to get these types of issues resolved.
Troubleshooting echo problems
Echo issues are actually such a complex problem that an entire tutorial could be written on the topic. Since it is not normal to have echo on a SIP or IAX2 trunk, you can almost always rule out an issue with the trunk or provider, although there are some very rare situations where echo over a VoIP trunk can occur it's almost always caused somewhere else in the system.
Beginning with trixbox CE 2.4, the OSLEC (open source line echo canceller) has been included by default and almost instantly the complaints about echo on analog lines went away. There are times though that there may still be an echo being heard by one of the parties on a call.
The first step is to determine if the issue is caused by acoustic echo. This happens often with cheaper phones if the mic gain on a handset is set to high. Acoustic echo will also happen on an extension to extension call, as well as a call to a remote person, whereas other types of echo will only happen on calls outside the system. If you are getting acoustic echo, try to talk softer to see if that makes the echo go away; if it does, then go into the settings for the phone and look for a mic/microphone or handset gain and adjust it down to solve the problem.
Hybrid echo occurs between the trixbox system and the telephone company and is much harder to solve. The first step is to call the phone company and see if it will come out and test the lines; often a bad line or poor voltage will be the root cause of an echo problem.
Sometimes echo can be removed by adjusting the gains within Asterisk. Using the ztmonitor command, we can look at the audio levels in real time to see if we are getting large audio spikes. If we have a phone line on zap channel 1, then we can use the following command:
ztmonitor 1 v
The resulting output will look like the following output:
Visual Audio Levels. -------------------- Use zapata.conf file to adjust the gains if needed. ( # = Audio Level * = Max Audio Hit ) <--------------(RX)--------------> <--------------(TX)------------->############# * ########## *
As you are talking, you will see the graphs move left and right. What we want to do is to make sure that the spikes aren't much past the halfway point on either graph. If they are well past halfway, then we need to make some adjustments in order to correct that.
This is best done using two Putty windows open, one running ztmonitor and the other open to edit the files and reload Asterisk.
In the window you will use for editing files, run the following command:
nano /etc/asterisk/zapata.conf
In this file you will find the following lines:
rxgain=0.0 txgain=0.0
If the graph is showing that the TX is spiking too high, then start by editing the txgain to -1; if you need to make further adjustments, only increment or decrement the value by 1 each time, as it may not take much to get to the point that the calls are sounding good. When you have made the change, type Ctrl+O to save and Ctrl+X to exist. Next we need to tell Asterisk to reload the configuration we just made; we can do this quickly from the command line with the following command:
asterisk rx "reload"
Continue testing and you should see the graph not spike as hard anymore. Keep making these adjustments to either the RX or TX gain based on the ztmonitor graph until you have tuned out all the echo.
Hardware troubleshooting
In most cases, installing a new card is going to work; however, there are some systems that will end up with IRQ conflicts that can result in the card not being detected or not initializing properly. There are a number of things to try to avoid any conflicts like this.
Clean up the BIOS
The very first thing you should do is disable any unused hardware in your system's BIOS. This would include disabling the serial port, parallel port, floppy controller, on-board audio card, and USB ports this will free up IRQ's for your add-in cards.
Checking for conflicts
If cleaning up the BIOS didn't help, then the next step is to check the system to see if your cards are detected and have been handed an IRQ properly.
The first command to be typically used is cat /proc/interrupts as this will show us a list of equipment installed into a system and the IRQ numbers that are assigned. The following output is from a typical system with a Sangoma analog card installed: CPU0
0: 852014312 IO-APIC-edge timer 2: 0 XT-PIC cascade 8: 1 IO-APIC-edge rtc 137: 44 IO-APIC-level eth1 145: 851809694 IO-APIC-level wanpipe1 153: 59824592 IO-APIC-level ehci_hcd, ohci_hcd, ohci_hcd 161: 6225357 IO-APIC-level eth0 169: 5911306 IO-APIC-level libata 177: 0 IO-APIC-level libata NMI: 0 LOC: 851363216 ERR: 0 MIS: 0
The Sangoma card used a driver called wanpipe, and we can see that the wanpipe driver is on its own IRQ and should not be having any issues.
Another useful command is lspci, which is another command to list the installed devices. The output from the same machine as above is shown as follows:
00:00.0 Host bridge : ATI Technologies Inc Radeon Xpress 200 Host Bridge (rev 01) 00:01.0 PCI bridge : ATI Technologies Inc RS480 PCI Bridge 00:11.0 IDE interface : ATI Technologies Inc 437A Serial ATA Controller (rev 80) 00:12.0 IDE interface : ATI Technologies Inc 4379 Serial ATA Controller (rev 80) 00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80) 00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80) 00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller (rev 80) 00:14.0 SMBus : ATI Technologies Inc IXP SB400 SMBus Controller (rev 82) 00:14.1 IDE interface : ATI Technologies Inc Standard Dual Channel PCI IDE Controller (rev 80) 00:14.3 ISA bridge : ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) 00:14.4 PCI bridge : ATI Technologies Inc IXP SB400 PCI-PCI Bridge (rev 80) 01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200] 02:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL- 8139/8139C/8139C+ (rev 10) 02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL- 8139/8139C/8139C+ (rev 10) 02:04.0 Network controller : Sangoma Technologies Corp. A200/Remora FXO/FXS Analog AFT card
With this information, we can see that the system properly detected the Sangoma A200 card. If these commands do not show your installed card, or if you are getting IRQ conflicts, the next thing to try is moving the card to a different slot. Fonality has a list of approved hardware available at http://trixbox.org.
Additional References
- For instructions on Installing Trixbox, click here
- For instructions on Installing trixbox CE 2.6 click here
Source
The source of this content is Chapter 3: Installing trixbox CE 2.6 of trixbox CE 2.6 by Kerry Garrison (Packt Publishing, 2009).
