Call quality issues over 100MB Internet connection
Submitted by nosborne on Tue, 03/27/2007 - 7:18pm.
I'm running Trixbox 2.0 on a Dell PE 2900 with a 3.0 GHz Dual core processor, 4 GB of RAM, and a 100MB Internet connection (up and down) in a pure VOIP environment (no Digium or Sangoma cards).
I seemingly have plenty of power and pipe, but I'm experiencing awful call quality on the receiving end of calls, outside the system. Calling from a SIP hard phone or IAX softphone from this system through a termination provider to the PSTN sounds great on our end, but the callee hears choppy audio and jitter. Ping times are good and my Internet connection is huge, so I wouldn't expect to have so many problems.
I've tried several termination providers, using both SIP and IAX, with ulaw, gsm, and g729a. Ulaw over SIP sounds by far the best of any combos, but the quality still is pretty far from acceptable.
I've tried some QoS traffic shaping using pfSense, but so far it hasn't seemed to help. I've read about issues on some Dell Servers, so I also tried setting up Trixbox on a Shuttle PC on the same network, but it had the same issues.
Does anyone have suggestions as to what to try next?
Have you considered putting
Tue, 03/27/2007 - 8:06pm
"PSTN sounds great on our
Tue, 03/27/2007 - 8:18pm
"PSTN sounds great on our end, but the callee hears choppy audio and jitter. Ping times are good and my Internet connection is huge, so I wouldn't expect to have so many problems."
This should stand out when you read it alone.
You are totally correct your end if fine, you have no control on the other persons inet connection, machine, itsp.
If my inet connection is poor then the conversation we establish will be choppy as I'm having lag time on my end. This is where.
remember most users (many companies included) are using the cheapest access they can get and then surfing while talking just makes it worse.
Here ATT charges 11.95 a month for their "home package" that same package once you have a DBA goes up to 55.00 month - well in both the bandwidth is the same and people are saving some bucks but I often ask - "hey stop browsing for a moment, will ya?" this is because I'll hear them say I hear echo and when they stop it goes away.
The other thing often is users having a laptop use a softphone and it just goes south real quick since I can hear me own voice from their speakers to their mic and back to me.
You like me cannot fix it when it's on their end.
Does your ITSP give you pots access if so use it for some calls and then on the ones where little to no problem exist go for the sip connection.
More details
Wed, 03/28/2007 - 7:57am
Thanks, I've got a TDM11B in it now, and the zttest results look good:
--- Results after 31 passes ---
Best: 100.000000 -- Worst: 99.987793 -- Average: 99.992518
However, call quality is still questionable--choppy, with jitter.
Some more detail:
I'm running Trixbox 2.0.0 with FreePBX 2.2.0rc3, asterisk 1.2.16. All updates are downloaded and installed. The server is connected to a NetGear FS524 10/100 switch, which is connected to the Firewall, an AMD Sempron with 512MB RAM running pfSense 1.0.1. Currently, traffic shaping on the firewall is disabled. CPU usage on the firewall stays < 5% and memory usage hovers around 27%. The firewall is connected 100 MB full duplex to a Metrobility Tx-Fx media converter, which brings in our fiber connection.
Ping times:
# ping outbound1.vitelity.net
PING outbound1.vitelity.net (64.2.142.18) 56(84) bytes of data.
64 bytes from 64.2.142.18.ptr.us.xo.net (64.2.142.18): icmp_seq=0 ttl=49 time=63.4 ms
64 bytes from 64.2.142.18.ptr.us.xo.net (64.2.142.18): icmp_seq=1 ttl=49 time=64.2 ms
64 bytes from 64.2.142.18.ptr.us.xo.net (64.2.142.18): icmp_seq=2 ttl=49 time=63.4 ms
64 bytes from 64.2.142.18.ptr.us.xo.net (64.2.142.18): icmp_seq=3 ttl=49 time=63.3 ms
I'm gonna try yet another ITSP now, to see if maybe I've had some bad luck there so far. Thanks for the input, more ideas are welcome!
Try running this ping test
Wed, 03/28/2007 - 7:57am
Try running this ping test towards your itsp:
ping -i 0.02 -c 500 connect01.voicepulse.com
where connect01.voicepulse.com is *your* itsp.
The main thing you want to look for is packet loss. Even 0% can be misleading because you may have lost packets - which is audibly noticeable.
Something does not add up.
Wed, 03/28/2007 - 8:08am
Something does not add up. I've got excellent sound quality, on both ends with far less horsepower.
The problem sounds like an issue with upload speed. But a 100MB connection is huge, are you sure that is the size of your inet pipe? Have you run a speed test to see what your actual throughput is?
http://www.speakeasy.net/speedtest/
What about a traceroute?
Do you have an outbound proxy that could be slowing down traffic? An outbound traffic monitor?
Ping test results
Wed, 03/28/2007 - 8:11am
Thanks, here are the results:
#ping -i 0.02 -c 500 outbound1.vitelity.net
64 bytes from 64.2.142.18.ptr.us.xo.net (64.2.142.18): icmp_seq=498 ttl=49 time=63.3 ms
64 bytes from 64.2.142.18.ptr.us.xo.net (64.2.142.18): icmp_seq=499 ttl=49 time=63.5 ms
[snip more of the same]
--- outbound1.vitelity.net ping statistics ---
500 packets transmitted, 500 received, 0% packet loss, time 10249ms
rtt min/avg/max/mdev = 63.311/64.014/67.298/0.715 ms, pipe 5
I'm placing test calls from a SPA-942 hard phone, jackenIAX on OS X and IDEfisk on Windows.
Bandwidth test results
Wed, 03/28/2007 - 8:33am
Using the dslreports java speed test, it looks like I get about 20-22 MB download and 15-18 upload for a single connection.
Running a bunch of simultaneous connections with iperf, I get about 85Mb/sec total throughput:
#iperf -c dca.iperf.cogentco.com -w 128k -P 10
------------------------------------------------------------
Client connecting to dca.iperf.cogentco.com, TCP port 5001
TCP window size: 128 KByte
------------------------------------------------------------
[1912] local 10.100.1.171 port 1068 connected with 38.99.216.150 port 5001
[1892] local 10.100.1.171 port 1069 connected with 38.99.216.150 port 5001
[1876] local 10.100.1.171 port 1070 connected with 38.99.216.150 port 5001
[1860] local 10.100.1.171 port 1071 connected with 38.99.216.150 port 5001
[1844] local 10.100.1.171 port 1072 connected with 38.99.216.150 port 5001
[1828] local 10.100.1.171 port 1073 connected with 38.99.216.150 port 5001
[1812] local 10.100.1.171 port 1074 connected with 38.99.216.150 port 5001
[1796] local 10.100.1.171 port 1075 connected with 38.99.216.150 port 5001
[1780] local 10.100.1.171 port 1076 connected with 38.99.216.150 port 5001
[1764] local 10.100.1.171 port 1077 connected with 38.99.216.150 port 5001
[ ID] Interval Transfer Bandwidth
[1912] 0.0-10.1 sec 10.2 MBytes 8.51 Mbits/sec
[1892] 0.0-10.1 sec 10.2 MBytes 8.50 Mbits/sec
[1876] 0.0-10.1 sec 10.2 MBytes 8.50 Mbits/sec
[1860] 0.0-10.1 sec 10.2 MBytes 8.50 Mbits/sec
[1844] 0.0-10.1 sec 10.2 MBytes 8.50 Mbits/sec
[1828] 0.0-10.1 sec 10.2 MBytes 8.50 Mbits/sec
[1812] 0.0-10.1 sec 10.2 MBytes 8.50 Mbits/sec
[1796] 0.0-10.1 sec 10.2 MBytes 8.50 Mbits/sec
[1780] 0.0-10.1 sec 10.2 MBytes 8.51 Mbits/sec
[1764] 0.0-10.1 sec 10.2 MBytes 8.51 Mbits/sec
[SUM] 0.0-10.1 sec 102 MBytes 85.0 Mbits/sec
Interesting. You've
Wed, 03/28/2007 - 8:59am
Interesting. You've definitely got the bandwidth. Are you the only one making calls, or do you have multiple concurrent calls?
Try this as well:
http://www.bandwidth.com/tools/voipTest
Are you using IAX for your
Wed, 03/28/2007 - 9:06am
Are you using IAX for your trunk to Vitelity? You need to use SIP.
-- James
"Running a bunch of
Wed, 03/28/2007 - 9:26am
"Running a bunch of simultaneous connections with iperf, I get about 85Mb/sec total throughput:
#iperf -c dca.iperf.cogentco.com -w 128k -P 10"
By reading that I'm assuming you are a Cogent customer. By running iperf tests only to Cogent, you are only testing their network speed. What speed you get to the Internet will differ greatly. The 20Mbitx20Mbit to the actual Internet seems about right for Cogent.
More test results
Wed, 03/28/2007 - 10:01am
Thanks for the info on my iperf test -- makes sense.
Here is the result from http://www.bandwidth.com/tools/voipTest :
Test Type Results
Bidirectional Transfer Rate 2,244.97 kbps
VoIP Phone Capacity 26 Concurrent Calls** (G711 Compression)
Latency 80.0 milliseconds ( Good )
SIP Port Test Blocked
MGCP Port Test Blocked
I'm testing outbound calls only at the moment, over SIP, so I don't think the SIP blocked message above matters, correct? I've tried both IAX and SIP to Vitelity--SIP does seem better, but only marginally so.
"What is the situation at the other end of these calls? What is the bandwidth and environment of the endpoint that hears the bad quality?"
I've placed test calls to a couple mobile phone numbers, also to a Vonage line connected to a home Comcast 8Mb/512k connection, also to another Asterisk server connected to the PSTN via a voice T1 and a Digium TDM 212P (it doesn't use VOIP for external calls).
All calls sound fine to me, but the recipients consistently hear choppiness, jitter, echo. For testing, I have an extension set up on the other (non-VOIP) Asterisk server where I can call in and record something and it plays back what I just said to hear the quality. When I count to ten on the recordings, I hear some jitter and it sometimes it misses a number in the playback ("...5,6,7,9,10").
During my testing, others are using the Internet connection (in an office with about 30 people), but I'm the only one placing calls. Thanks for all the suggestions--something doesn't add up, I've just gotta figure out what!
pathping
Wed, 03/28/2007 - 10:11am
One thing I would do is take a hardphone to another location (your house maybe) and test from there against your server. Usually users do all kind of things apart from using the voip, so is their limitations and not yours.
One thing I notice is that your pings are not impressive with a pipe like that, in my opinion. Where are you located?
To give you an idea, In DC with a 1.1 SDSL I got an average of 50ms to outbound1.vitelity.net , 7 users surfing internet and 3 voip calls right now.
Another thing you can try is pathping outbound1.vitelity.net from a windows machine. you can see the hop and time
I agree that 63 ms is not
Wed, 03/28/2007 - 11:46am
I agree that 63 ms is not that impressive ... but I have never experienced severe problems [like a dropped number when speaking a sequence of digits] on any call with latencies under 100 ms or even higher. To drop a number out of a spoken sequence when counting from 1 to 10, presumably in some reasonably paced voice stream, it means that thousands of samples have been lost which means a really substantial packet loss should show up.... maybe not in a ping test which uses tiny packets but using a test tool that can generate RTP packets and emulate SIP and IAX traffic.
Pathping results
Wed, 03/28/2007 - 12:38pm
I ran pathping to outbound1.vitelity.net. I'm in Atlanta, and it's 15 hops from here. Is it strange that in the bottom part that the second to last hop took longer than the last one? Pathping results:
C:\>pathping outbound1.vitelity.net
Tracing route to outbound1.vitelity.net [64.2.142.18] over a maximum of 30 hops:
0 [removed].com [10.100.1.171]
1 [removed].com [10.100.1.1]
2 [removed] [xxx.xxx.xxx.xxx]
3 g10-4-1.core01.atl01.atlas.cogentco.com [66.28.65.5]
4 p14-0.core01.jax01.atlas.cogentco.com [154.54.3.198]
5 p15-0.core01.mia01.atlas.cogentco.com [66.28.4.137]
6 p10-0.core01.mia03.atlas.cogentco.com [154.54.2.194]
7 xo.mia03.atlas.cogentco.com [154.54.11.154]
8 p4-0-0.rar1.miami-fl.us.xo.net [71.5.168.21]
9 p4-0-0.RAR1.Dallas-TX.us.xo.net [65.106.0.58]
10 p0-0-0d0.rar2.dallas-tx.us.xo.net [65.106.1.38]
11 p1-0-0.RAR2.Denver-CO.us.xo.net [65.106.0.41]
12 65.106.6.26.ptr.us.xo.net [65.106.6.26]
13 p15-0.CHR1.Englewood-CO.us.xo.net [207.88.83.14]
14 66.236.84.206.ptr.us.xo.net [66.236.84.206]
15 64.2.142.18.ptr.us.xo.net [64.2.142.18]
Computing statistics for 375 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 [removed].com [10.100.1.171]
0/ 100 = 0% |
1 2ms 0/ 100 = 0% 0/ 100 = 0% [removed].com [10.100.1.1]
0/ 100 = 0% |
2 3ms 0/ 100 = 0% 0/ 100 = 0% [xxx.xxx.xxx.xxx]
0/ 100 = 0% |
3 3ms 0/ 100 = 0% 0/ 100 = 0% g10-4-1.core01.atl01.atlas.cogentco.com [66.28.65.5]
0/ 100 = 0% |
4 9ms 0/ 100 = 0% 0/ 100 = 0% p14-0.core01.jax01.atlas.cogentco.com [154.54.3.198]
0/ 100 = 0% |
5 17ms 0/ 100 = 0% 0/ 100 = 0% p15-0.core01.mia01.atlas.cogentco.com [66.28.4.137]
0/ 100 = 0% |
6 16ms 0/ 100 = 0% 0/ 100 = 0% p10-0.core01.mia03.atlas.cogentco.com [154.54.2.194]
0/ 100 = 0% |
7 17ms 0/ 100 = 0% 0/ 100 = 0% xo.mia03.atlas.cogentco.com [154.54.11.154]
0/ 100 = 0% |
8 18ms 0/ 100 = 0% 0/ 100 = 0% p4-0-0.rar1.miami-fl.us.xo.net [71.5.168.21]
0/ 100 = 0% |
9 45ms 0/ 100 = 0% 0/ 100 = 0% p4-0-0.RAR1.Dallas-TX.us.xo.net [65.106.0.58]
0/ 100 = 0% |
10 46ms 0/ 100 = 0% 0/ 100 = 0% p0-0-0d0.rar2.dallas-tx.us.xo.net [65.106.1.38]
0/ 100 = 0% |
11 67ms 0/ 100 = 0% 0/ 100 = 0% p1-0-0.RAR2.Denver-CO.us.xo.net [65.106.0.41]
0/ 100 = 0% |
12 68ms 0/ 100 = 0% 0/ 100 = 0% 65.106.6.26.ptr.us.xo.net [65.106.6.26]
0/ 100 = 0% |
13 66ms 0/ 100 = 0% 0/ 100 = 0% p15-0.CHR1.Englewood-CO.us.xo.net [207.88.83.14]
0/ 100 = 0% |
14 68ms 0/ 100 = 0% 0/ 100 = 0% 66.236.84.206.ptr.us.xo.net [66.236.84.206]
0/ 100 = 0% |
15 65ms 0/ 100 = 0% 0/ 100 = 0% 64.2.142.18.ptr.us.xo.net [64.2.142.18]
Trace complete.
"Aside from your connection,
Wed, 03/28/2007 - 12:42pm
"Aside from your connection, have you changed any settings (echo cancellation) in freePBX?"
Yes, actually, I've tried quite a number of things, since the quality has been so bad. At one point I tried changing the echo canceler to MG2 in zaptel.h source. I also tried upgrading the zaptel driver to 1.2.15 and then 1.2.16, building from source each time to use my smp kernel. I'm actually not sure which one is in use currently -- is there an easy way to tell?
I don't know that zaptel changes had any effect just running ztdummy, but I am using a TDM11B now. I also added jitterbuffer=yes to IAX.conf, but I haven't changed any tos settings. I've installed a couple g729a licenses and have experimented with forcing my trunks to use g729, but that seems to make things much worse.
"a test tool that can generate RTP packets and emulate SIP and IAX traffic."
Any recommendations/pointers for tools that can do this?
Thanks for all the advice!
Issue is firewall related - any m0n0wall or pfSense experts?
Tue, 07/03/2007 - 7:49am
After a lot more troubleshooting, I've isolated the problem to be a firewall issue. It's not yet fixed though :(. I've tried several versions of pfSense and m0n0wall running on a full pc as the firewall. All exhibit very choppy call quality on the receiving end of calls only, outside the system. Inbound call quality is fine, regardless of which party initiated the call. When I replace my full PC running m0n0wall with the embedded version running on a WRAP board, however, call quality is good in both directions.
Also, when I moved the trixbox server to a different internet connection (DSL this time) behind a Netopia modem/router, the call quality is again fine in both directions.
This is now probably a question for the m0n0/pfSense forums, but I'll ask it here too. I've tried running the firewall on several different PCs with different models of NICs to try to isolate the issue. So far, whether or not I run pfSense or m0n0wall, using 3COM or Intel NICs, the problem is the same. Only when I switch to the embedded WRAP does it go away.
Any ideas what might be causing this? Or what might be the difference for VoIP routing between the embedded and PC versions of Monowall?
The trixbox is on a OPT1/DMZ network segment with a public IP. I've tried traffic shaping on and off, and both advanced outbound NAT and standard dynamic outbound NAT. I have no problem registering to my SIP provider, or placing/receiving calls, but the person on the PSTN end of the call hears very bad choppiness.
Thanks for any tips.
Also.. what codec are you
Tue, 07/03/2007 - 8:21pm
Also.. what codec are you running to your itsp? If your itsp supports ULAW, try that and see what happens. The problem could be the fact that your box is having trouble with the transcoding. How much RAM do you have in the system?
These are all things to check in addition to the network. Also.. what kind of switch are you using? Are you maxing out the backplane on the switch? Considering you have a 100 Mbps connection, the problem could easily be internal to your switch or the machine in general. What kind of CPU? and RAM? most important.
Having same issue while using SG-560
Sat, 10/06/2007 - 7:56am
I am running trixbox-1.2.3 behind a Snapgear SG-560 router and am experiencing the same issue. I have tried ping and speed tests with results similar to what has been previously posted. I have tried turning on tos in the router and playing with the tos parameter in sip.conf but it makes no difference. I have both Teliax and Vitelity as carriers and Teliax seems slightly better. Before I got the SG-560 I was running a netgear FVS-318 and had the same problem. This problem persists even when there is no other traffic on the LAN and seems to be random- some days it is worse than others. I am completely baffled by this problem and any suggestions would be greatly appreciated.
Internet-->cable modem-->SG-560--->5 port switch--->trixbox
Most answers skip an
Sat, 10/06/2007 - 9:13am
ifconfig showing zero errors
Sat, 10/06/2007 - 11:01am
Link encap:Ethernet HWaddr 00:20:78:1B:3D:5E
inet addr:192.168.254.3 Bcast:192.168.254.255 Mask:255.255.255.0
inet6 addr: fe80::220:78ff:fe1b:3d5e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:690646 errors:0 dropped:0 overruns:0 frame:0
TX packets:661424 errors:0 dropped:0 overruns:0 carrier:0
collisions:734 txqueuelen:1000
RX bytes:225545351 (215.0 MiB) TX bytes:158401431 (151.0 MiB)
Interrupt:5 Base address:0x1460
MTU issue?
Sat, 10/06/2007 - 12:58pm
I had similar problems and everything was fixed when moved the box outside of the firewall and protected it with IPtables. (Im not 100% happy with it but...)
But I had similar issues when i attempted to use IPtables as most people would and say, block everything and then open up the SIP UDP ports. I currently have a workable solution by keeping everything open, but only allow access to www,ssh,ftp,mysql etc from the outside address of my firewall.
Regardless of firewall settings, make sure that extensions are set to have canreinvite set to no. Otherwise phones will try to reach to remote party directly. I also set NAT=yes and qualify=1000.
This page also has a lot of information about SIP+NAT etc.
http://www.voip-info.org/wiki-Asterisk+SIP+NAT+solutions
My trials and tribulations are documented here
http://www.trixbox.org/forums/trixbox-forums/open-discussion/trix...
Another throught is what about packet MTU. If the 1500 byte MTU is to large, packets would fragment and would cause random choppyness???
This is controlled by the ISP and would explain why some people have problems with identical hardware and not others.
trixbox outside of firewall
Sat, 10/06/2007 - 5:07pm
"But I had similar issues when i attempted to use IPtables as most people would and say, block everything and then open up the SIP UDP ports. I currently have a workable solution by keeping everything open, but only allow access to www,ssh,ftp,mysql etc from the outside address of my firewall."
Is this with trixbox behind the firewall?? IP tables is turned off in my trixbox that is behind the SG-560. Has anyone tried the Draytek firewall as suggested in another thread?
VOIP quality oney perfect connection
Sun, 10/07/2007 - 8:48am
You have have QOS but it only go as far as your router and to you isp once it get there the Qos stop at there network. Any how please consider this we have stop using vitelity network on all of our client we have such a hard time with call quality to their network regard less of ping time. There may have server problems.
To insure that you have good call quality you would need a TDM card to use it as a timing device. much better then using ztdummy
After that you need to find a VOIP provider you use true TDM termination service and not VOIP termination service. This mean it cost a little more but call quality are so much better
Call quality 100% perfect
our server ---internet---VOIP provider----TELCO------call to end point
Our old setup (not as good) (non cisco call manager at the VOIP provider end)
our server ---internet---VOIP provider----Whole saler----TELCO------call to end point
Like they said you get what you paid for.
-paul
I am in a similar
Mon, 05/05/2008 - 9:47pm
I am in a similar predicament. I also have a Dell PowerEdge 2900 with 2.2 GHz Quad core processor, 2 GB of RAM. I have a Sangoma A200 with HEC, however its currently not being used with any FXO lines. Internet connection is 5/768 Time Warner business class cable modem service. Internet connection/speed is NOT the issue, as I have monitored it, and they are nowhere near full capacity.
Calls sound fine to internal users. However external users hear choppy audio and jitter often times. I have tried different codecs with no real solution. They use both Vitelity and VoicePulse Connect for their trunks.
If I call them from my Trixbox via ENUM (ALL IP call) the IVR can be choppy, but when the user answers it sounds fine (I think we are using the same codec). It seems to me like this is a mismatched kernel/codec problem? Even just listening to the IVR when I call in via my cell phone, the outgoing message can be choppy at times. However when I listen to the outgoing message wav file on my computer, its crystal clear. Could it be the transcoding is somehow not working properly?
Does anyone have a solution or idea what may be causing the poor audio quality?
I recently had problems with
Mon, 05/05/2008 - 9:58pm
I recently had problems with Voicepulse and this very issue. It's not on your end if it's a voicepulse DID you're calling into. (I'm assuming the DIDs are from VP). I went back and forth with them for 2 weeks and still, no dice. I eventually moved off their SIP trunks and went back to IAX (for now) and it seemed to solve the problem (although it's not really a fix). Their SIP service isn't working very well, but their IAX stuff seems to be pretty solid (and hopefully will stay that way).
-----------------------------------------------
Percy Kwong
www.swimminginthought.com
Congestion on your provider link
Mon, 05/05/2008 - 10:51pm
You did not provide any details on your 100Mbps connection however I would venture a guess that it is some sort of metro fiber type connection.
While these networks are being marketed as an alternative to traditional TDM based SONET (OC-3 and above) the truth is the networks are horribly over subscribed.
I also looked up and noticed that the OP is quite old. I did not read the entire thread. My comment on metro fiber stands.
This is just a guess.
Scott
--
Scott
aka "Skyking"
It could be network issue
Mon, 05/05/2008 - 11:49pm
When dealing with sound quality issue to a VOIP trunk carrier, there are couple common areas that may cause issue. For example, if your network is mapping like this.
VOIP Carrier <--> Internet <--> Local Internet Carrier <--> Router <--> L3 Switch <--> Firewall <--> L2 Switch <--> Trixbox.
The most common trouble areas are firewall and Router. When you have enough bandwith but get bad voice quality, mostly likely you have packet drop somewhere when the voice packet is transfering from the Trixbox to the Voip carrier. Packet dropping is not that easy to find. Alot of people simply use "Ping" to determin the packet drop. It's not very accurate when dealing with Voip. Becasue when you ping something, it will transmit about 30 to 50 bytes of data, if 2 or 10 bytes gets dropped, it will still resulting success. if this 50 bytes of data is carrying voice, it will result choppy. If you are using Ulaw as the voice Codec to your Voip carrier, if the packet gets dropped during the transfer, it will not get retransmited. Ulaw codec does not do assurence checking. The receiving end does not know there are packet got dropped. Incomplete transmission makes poor sound quality.
Inorder to find the drop packet area, you may need to go into each network device to check the interface activity. In Cisco equipment, you basicaly look for CRC error, collision error. If you see CRC error, that is related to hardwares such as cable, network interface. I've seem somebody accidently put a Cat5 cable between two switches on the Gigibit ports. The switch attempts to run Gigibit on a regular Cat5 cable and makes alot of CRC error. When switch detects CRC error, the packect is dropped. The other common problem is the duplex mismatch. Duplex mismatch will result alot of collision error on the network equipment. Collision means the packet gets killed. When a carrier is dropping you a 100MB connect, you need to make sure the duplex mode on your carrier side is matching on your equipment. Full duplex is preferred. Sometime you have to confirm with your carrir to see if there is any Fiber/Ethernet convertor in the path, becase alot of those convertors are set to half duplex by default.
Once you make sure no packet loss anywhere on the network, you may also need to define some QoS rules on your edge router to make sure Voice traffic takes higher priority with reserved bandwidth.
Quote:
If you are using Ulaw
Tue, 05/06/2008 - 12:34am
Quote:
If you are using Ulaw as the voice Codec to your Voip carrier, if the packet gets dropped during the transfer, it will not get retransmited. Ulaw codec does not do assurence checking. The receiving end does not know there are packet got dropped. Incomplete transmission makes poor sound quality.
It's not really a CODEC issue. SIP media uses RTP which relies on UDP as the transport. UDP does not support retransmission, which is essentially worthless in a media stream anyway.
Scott
--
Scott
aka "Skyking"
I don't believe the problem
Tue, 05/13/2008 - 12:23am
I don't believe the problem is due to my ITSP, but instead think its a timing issue. I have a Sangoma A200 card installed.
I found this thread by searching for other Dell PowerEdge 2900 users who were having similar issues with choppy sound, etc. I have a feeling there is something about the 2900 motherboard that is causing this, I just can't figure out what it is.
Anyone have an idea on where to look next? Maybe call Sangoma technical support?
i have the same issue - here's my story...
Fri, 05/16/2008 - 5:42am
At one point I suspected the problem was my network.
Here's my setup.. if you have the patience to read..
1) phase 1, I installed Trixbox 2.2x on a DELL PowerEdge 2950 with TONS of memory and HDD space with RAID configured, Network with Cisco gears (Cisco IP phones, Cisco 5500 catalyst switch, Cisco AS5300 gateway (so my calls does not even goes out the internet - all LAN), Nortel MICS bridge in to the VoIP network, CME from remote warehouse.
a. AS5300 has PRI port 0, 1 connected from VZ PRI (International, Long Distance, Local calls)
b. AS5300 has PRI port 2 connected to Nortel MICS PRI port (Inbound/Outbound)
(when I make calls from Nortel to outside world call is perfect both inbound and outbound - of course it's all TDM local) duhhh. I only use the AS5300 for my routings LCR, VoIP networks, Etc.
c. CME connected via VPN with 1.5MB my main site has DS3 to my colo and the colo has 100MB pipe.
(calls between the CME and the AS5300 to my Nortel has no problem I can have 20 calls no issues at all - all VoIP of course)
d. Trixbox on the other hand is configure on the local network where I have AS5300 and Nortel system installed.
(here we go.. calls from Nortel to Trixbox - echo like crazy the first 30 sec is good the rest of the call you cannot understand anymore - line is unsable. calls from PSTN to AS5300 --> pass VoIP to Trixbox using dial-peer same quality like Nortel to trixbox. calls from CME to trixbox is good quality though)
2) Phase 2, since I have issue on echo I figured to get a layer2/3 switch so I can control packets between voice and data. So I installed Cisco 3550 and configure the QoS to see if anything changed. oopppsss I forgot to mentioned my Voice and Data as on 2 different VLANs to protect collision on the network.
a. after 2 hours of moving everyone from C5500 to C3550 including the trixbox server as well as AS5300.
(user's are still complaining that they get echo from callers, no echo on extension to extension, no echo on extension to conference bridge, no echo from CME calls)
NOW I AM NOT SURE WHAT THE HELL TO DO EXCEPT THAT I HAVE TO THROW THIS TRIXBOX OUT OF THE WINDOW AND START FROM SCRATCH, JUST GOT CURIOUS ABOUT THE DELL POWEREDGE MAY BE THE PROBLEM IS THERE FROM THIS HARDWARE NOT FROM ANYTHING ELSE.
I will try to install from a non-Dell machine and see what happen.. see you next..
Have you considered using
Fri, 05/16/2008 - 7:19am
Have you considered using another network card? I heard the 2950s were having issues with their Network Cards. Try putting one into the machine and using that. (They're cheap enough)
-----------------------------------------------
Percy Kwong
www.swimminginthought.com
Quote:
oopppsss I forgot to
Fri, 05/16/2008 - 7:55am
Quote:
oopppsss I forgot to mentioned my Voice and Data as on 2 different VLANs to protect collision on the network.
Just a quick point you can't have collision on a switch! Have you made sure all the ports on the switch auto negotiated with the phones correctly at 100M Full Duplex? Do you have portfast turned on each interface (don't)?
How is the Dell peered with the Nortel? PRI card or an H.323 trunk?
I think we can get to the bottom of this, it is not normal behavior.
Quote:
THROW THIS TRIXBOX OUT OF THE WINDOW
I don't think we need to do that. Let's figure out what is wrong.
Scott
--
Scott
aka "Skyking"
I don't think its the NIC,
Sun, 05/18/2008 - 2:33pm
I don't think its the NIC, as I have installed on three machines with different NIC's.
1: Dell PowerEdge 2900 w/ Sangoma A200
2: Dell PowerEdge 400SC no hardware timing source
3: Dell Optiplex GX150 no hardware timing source
Here are my zttest results for the 400SC:
--- Results after 33 passes ---
Best: 99.983 -- Worst: 99.926 -- Average: 99.956968, Difference: 99.984205
Doesn't look too good does it? I would like to run ztclock, but its not installed on my systems, and I'm not sure how to get it.
I just installed 2.6.0.7 on the GX150, and got the same bad results. When I install 2.2.0.12 on the GX150 I get an average of 99.97... which is quite a bit better. However ztclock shows that I will drop a few frames every 6 seconds, which doesnt sound good.
As of right now, I only have 2 of 4 systems that sound good. Both are all voip with no hardware timing, an generic AMD box running Trixbox 2.2.0.12 and an ALIX running 2.6.0.7. My PowerEdge running 2.6.0.7 sounds like crap, as well as another generic AMD box running the same version of Trixbox.
I still believe this is a timing issue somehow, as everything else works ok. Its just the recording playback's that sound bad.
Here is cat /proc/interrupts from the 2900:
CPU0 CPU1 CPU2 CPU3
0: 485625033 0 0 0 XT-PIC timer
1: 2 0 0 0 XT-PIC i8042
2: 0 0 0 0 XT-PIC cascade
6: 485545338 0 0 0 XT-PIC wanpipe1
8: 1 0 0 0 XT-PIC rtc
10: 604457 0 0 0 XT-PIC megasas
11: 5326378 0 0 0 XT-PIC libata
12: 4 0 0 0 XT-PIC i8042
14: 118 0 0 0 XT-PIC uhci_hcd:usb2, uhci_hcd:usb4
15: 24 0 0 0 XT-PIC uhci_hcd:usb1, uhci_hcd:usb3, ehci_hcd:usb5
137: 10853101 0 0 0 PCI-MSI eth0
NMI: 0 0 0 0
LOC: 485456269 485456900 485479326 485479326
ERR: 4497
MIS: 0
While we are on the subject
Sun, 05/18/2008 - 5:56pm
I checked my machine with a timing card in it and see that it is using a virtual interrupt.
Other than moving the card to another slot and reseting the BIOS config registers is there another approach for assuring the Zap board is assigned a unique interrupt?
[####.net ~]# ztscan
[1]
active=yes
alarms=OK
description=Wildcard TDM400P REV E/F Board 1
name=WCTDM/0
manufacturer=Digium
devicetype=Wildcard TDM400P REV E/F
location=PCI Bus 04 Slot 10
basechan=1
totchans=4
irq=169
type=analog
port=1,FXS
port=2,FXS
port=3,none
port=4,none
[#####.net ~]# cat /proc/interrupts
CPU0 CPU1
0: 899926248 0 IO-APIC-edge timer
1: 23 499 IO-APIC-edge i8042
2: 0 0 XT-PIC cascade
8: 1 0 IO-APIC-edge rtc
12: 169 806 IO-APIC-edge i8042
14: 1853127 53395 IO-APIC-edge ide0
15: 2525191 5563064 IO-APIC-edge ide1
161: 5899662 493665 IO-APIC-level eth1
169: 260650505 640013704 IO-APIC-level uhci_hcd:usb1, wctdm
177: 1089151 6791735 IO-APIC-level eth0
NMI: 0 0
LOC: 900034661 900034660
ERR: 0
MIS: 0
[######.net ~]#
--
Scott
aka "Skyking"
Quote:
Turn off apic by
Sun, 05/18/2008 - 6:10pm
Quote:
Turn off apic by editing your grub.conf and adding "noapic" to the kernel paramaters.
I had seen and researched that variable. Some folks had stability problems when using that parameter.
Since I have not had any stability problems and it is a production system I was hesitant to try.
I will now though....Thanks
Scott
--
Scott
aka "Skyking"
Bandwidth is rarely the
Sun, 05/18/2008 - 11:38pm
Bandwidth is rarely the issue. What a lot of people don't realize is that the Cable modem or DSL modem's on these connections are not made to handle the speed and quantity of packets that VOIP requires. This is one of the main reasons T1's are standard for quality business VOIP. The chips used in T1 routers handle large quantities of packets better. One of tell tale signs is when you can make 1-2 simultaneous calls at the same time without issue, but 3-5 calls simultaneous sound like crap. This is not a bandwidth issue but an issue with the chipset in the DSL/Cable modems.
Quote:
The chips used in T1
Mon, 05/19/2008 - 6:14am
Quote:
The chips used in T1 routers handle large quantities of packets better. One of tell tale signs is when you can make 1-2 simultaneous calls at the same time without issue, but 3-5 calls simultaneous sound like crap
I have been saying this since the day I arrived in these forums. This is especially noticeable with DOCSIS (cable modem) devices. They can't handle the concurrent sessions. You can see the same problem with a bunch of Citrix sessions. It's not a bandwidth issue. PPPoE on DSL is marginally better.
With the advent of very high bandwidth business class cable in our area (2MB upstream!) we have had to find a solution. The answer is using a VPN to tunnel the traffic. Lightweight tunnels such as GRE work the best.
If you need to push 50% of your upload speed in concurrent voice calls find a local ITSP that will place a managed VPN device at the customer premise.
I like DD-WRT for small installs however it is important to point out that the platforms Tomato and DD-WRT run on are not powerful enough to manage that large a tunnel dropping packets.
We have had good luck with the devices from Edgewater Networks.
Scott
--
Scott
aka "Skyking"
It is NOT our cable modem,
Mon, 05/19/2008 - 10:06am
It is NOT our cable modem, as the poor audio quality happens when nobody is in the office or using the internet connection. I try to place 1 call inbound, and it sounds like crap.
I'm thinking about trying a new network card in the PowerEdge 2900. Not because I think the network card is the actual problem, but that it may be sharing interrupts with something, causing the skipping/poor audio quality.
Voice transmission breaking-up?
Sat, 05/31/2008 - 4:22am
Hello All
I am have done many installs of Trixbox CE over the the last 18 months and the only time I have experienced choppy calls are:
*Router/Firewall losing the plot
*Wireless 3G providers filtering/blocking RTP ports
*Consumer/low spec software virtual servers - noticeable on generic X86/64 hardware (not server specific)
*NAT settings (one way audio)
You might want to check your data center virtual server setup as cheaper data center virtual servers will queue the workload giving each client an allocation of processor time, this directly affects real-time RTP packets as there is not a consistent stream of information from your rented server!
If it is your own hardware, then perhaps another client is bursting the available bandwidth, maybe you need to change to another data center!
Most of the TB installs I have done are pure VoIP without any trunk cards and have never had any issues of "timing"
Codec issues are obvious...it initiates a call, the other phone rings but when you pick the up the call, it drops the call...basically both end points need to negotiate the codec to use. If you do not have a codec such as g.729 and it is the only codec requested then you will never complete a call. Normal Codec fallover looks like: g.729, u-law, a-law, gsm.
I personally run a standard DSL connection 8M/700K connection and can comfortably have 4 u-law codec conversations over the WAN without issues.
Try building another basic TB at home, test it with a SiP provider, add some external extensions over the WAN/DSL/CABLE and make some calls. If you have success, back-up your bigger TB and then overwrite with the basic setup removing any doubt or showing what went wrong.
This stuff can be really frustrating but keep it simple! If it is getting complicated, pay the money for someone to do it or go back to traditional PSTN...it just works and I'm sure with the amount of man hours on this issue the value of saving a few pennies is almost out the door!!
Regards
Luke
I just ran ztclock on this
Tue, 06/17/2008 - 11:15pm
I just ran ztclock on this PowerEdge 2900 and here are the results:
ztclock - clock source accuracy test (3 passes)
Flushing input buffer...
Flush Complete.
Test is approximately 3 minutes. Please wait...
483328 samples in 60.416112 sec. (483329 sample intervals) 99.999794%
483328 samples in 60.416116 sec. (483329 sample intervals) 99.999794%
483328 samples in 60.416108 sec. (483329 sample intervals) 99.999794%
Estimate 8 frame slips every 483.328003 seconds.
Here are the results from zttest:
Opened pseudo zap interface, measuring accuracy...
99.999123% 99.995308% 99.999031% 99.998825% 99.999901% 99.997169% 99.998734%
99.998825% 99.998245% 99.999413% 99.999710% 99.998146% 99.998924% 99.998924% 99.999222%
99.998833% 99.999809% 99.997360% 99.998817% 99.998924% 99.999031% 99.999405% 99.997467%
99.999023% 99.998642% 99.998924% 99.998924% 99.998825% 99.998924% 99.999023% 99.999123%
99.998634% 99.998726% 99.998924% 99.999115%
--- Results after 35 passes ---
Best: 100.000 -- Worst: 99.995 -- Average: 99.998742, Difference: 99.998787
Both tests show great numbers. However when I call in from the outside, the audio from the IVR does not sound clean. Its not necessarily choppy, like if it were running in a VM, but minute portions of words are missing, and its different every call.
I have a feeling this has something to do with the hardware on the PowerEdge 2900. Has anyone else run into this and found a solution?
Is it recordings that sound
Wed, 06/25/2008 - 8:10pm
Is it recordings that sound bad? Like hold music or an IVR? Are calls clear that are to people?
If so, I would look at your recording codec. This can be a major problem and cause all kinds of havoc. Really what you want to-do as much as possible is stick to a single codec through and through. That means if your phones connect to your Trixbox with g711u, then you should have g711u SIP trunks. Also, all your recordings should also be using g711u.
Is there anyone here using
Thu, 08/28/2008 - 7:43am
Is there anyone here using Hughes Net as their internet provider? I can't make the internet work on my Trixbox 2.0 and I believe I got some of the configuration details wrong.
G729a codec?
Thu, 08/28/2008 - 9:32am
This is a long shot, but I had all manner of problems after I experimented with G729a codecs. I decided against using G729a in the end, but I ended up in a situation where I'd inadvertantly left g729a enabled on some devices but without licenses. Lots of things almost sounded like they were working but the failure mode was a bit unpredictable, sometimes it was one-way audio, other times really poor quality choppy audio. Once I realised and turned off the G729a codecs everywhere, things suddenly improved.
** NB I'm not saying there is anything wrong with G729a per se, just that I had incorrectly installed (or rather uninstalled) it.
--Tim Long
I'm starting to think that
Sun, 08/31/2008 - 12:30pm
I'm starting to think that the glitches in our audio quality is being caused by Time Warners over subscribed network in our part of town.
I have replaced every piece of hardware and am still having problems. If I take the PBX to my house and use it on COX, it works perfectly. When I take it back to the customers and use it on Time Warner, it sounds like crap.
When I run tests at: http://www.testyourvoip.com/
Time Warner usually tests with bad results, while COX usually tests with great results.
Member Since:
2007-02-01