Home » Forums » Community Edition » Help

Call quality issues over 100MB Internet connection

nosborne
Posts: 9
 Member Since:
2007-02-01
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?

‹ Calls going into a loop - CPU lockup TB website error in admin mode after update ›

&nbsp

apohl
Posts: 16
 Member Since:
2006-09-14
Have you considered putting
Tue, 03/27/2007 - 8:06pm

Have you considered putting a Digium card in your box to use as a timeing source? I believe that a box with out a digium card uses USB for timeing which is not always reliable. I could be wrong but I swear I read that some where a long time ago.


&nbsp

mnail
Posts: 240
 Member Since:
2006-06-30
"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.


&nbsp

cosmicwombat
Posts: 1173
 Member Since:
2006-05-31
How close is the trixbox...
Tue, 03/27/2007 - 8:28pm

How close is the trixbox to the edge? What kind of firewall? And you make no mention of versions you are running?

Incidentally, what are the ping times to your ITSP?

Robert

--

Robert Keller - Chief Technologist at large
The VoIP Experience
Open Telephony Training Seminar


&nbsp

nosborne
Posts: 9
 Member Since:
2007-02-01
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

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!


&nbsp

RexP
Posts: 162
 Member Since:
2007-02-09
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.


&nbsp

pkaplan
Posts: 209
 Member Since:
2007-02-28
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?


&nbsp

nosborne
Posts: 9
 Member Since:
2007-02-01
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.


&nbsp

nosborne
Posts: 9
 Member Since:
2007-02-01
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


&nbsp

RexP
Posts: 162
 Member Since:
2007-02-09
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


&nbsp

JamesDW
Posts: 518
 Member Since:
2006-06-01
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

www.rosevillelovelyhomes.com

--

***
James
http://www.jameswillis.info


&nbsp

eoo
Posts: 448
 Member Since:
2006-10-30
What is the situation at the
Wed, 03/28/2007 - 9:07am

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?


&nbsp

agit8or
Posts: 302
 Member Since:
2006-05-31
"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.


&nbsp

nosborne
Posts: 9
 Member Since:
2007-02-01
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!


&nbsp

gogousa
Posts: 85
 Member Since:
2006-12-11
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


&nbsp

RexP
Posts: 162
 Member Since:
2007-02-09
Aside from your connection,
Wed, 03/28/2007 - 11:14am

Aside from your connection, have you changed any settings (echo cancellation) in freePBX?


&nbsp

eoo
Posts: 448
 Member Since:
2006-10-30
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.


&nbsp

nosborne
Posts: 9
 Member Since:
2007-02-01
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.


&nbsp

nosborne
Posts: 9
 Member Since:
2007-02-01
"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!


&nbsp

nosborne
Posts: 9
 Member Since:
2007-02-01
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.


&nbsp

percykwong
Posts: 758
 Member Since:
2007-04-30
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.

--

-----------------------------------------------
Percy Kwong
Trixbox Tech Support - 202.600.3884

Swimminginthought.com


&nbsp

wolf
Posts: 28
 Member Since:
2007-03-09
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


&nbsp

16again
Posts: 370
 Member Since:
2007-03-04
Most answers skip an
Sat, 10/06/2007 - 9:13am

Most answers skip an important step
Check your ethernet ports for errors! A full/half/auto duplex mismatch setting might cause problems like these.
On linux systems, error counters shown in ifconfig should be zero
Also review these counters on managable switches


&nbsp

mbrevda
Posts: 209
 Member Since:
2006-06-21
also, try double checking
Sat, 10/06/2007 - 10:18am

also, try double checking that dma is enabled. hdpram -i /dev/up hard drive here

--

Moshe Brevda, FreePBX/Schmooze Com Development Team


&nbsp

wolf
Posts: 28
 Member Since:
2007-03-09
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


&nbsp

mbalsam
Posts: 56
 Member Since:
2007-08-08
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.


&nbsp

mbalsam
Posts: 56
 Member Since:
2007-08-08
Forget MTU
Sat, 10/06/2007 - 1:22pm

Just realized VOIP packets are going to be very small, so MTU NOT going to be an issue.


&nbsp

wolf
Posts: 28
 Member Since:
2007-03-09
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?


&nbsp

percykwong
Posts: 758
 Member Since:
2007-04-30
There's one thing that will
Sat, 10/06/2007 - 7:59pm

There's one thing that will easily cause this problem on a pfsense box.. (Cheap NICS).. Get some intel nics and replace the existing ones. I bet you the problem goes away.

--

-----------------------------------------------
Percy Kwong
Trixbox Tech Support - 202.600.3884

Swimminginthought.com


&nbsp

mbalsam
Posts: 56
 Member Since:
2007-08-08
behind firewall
Sat, 10/06/2007 - 10:46pm

My problem was when trixbox was behind SG-565 with IPtables off. I moved in front of firewall and turned on IPtables and things started working.


&nbsp

paulhuynh
Posts: 64
 Member Since:
2006-06-01
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


&nbsp

lagreca
Posts: 123
 Member Since:
2007-03-09
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?


&nbsp

percykwong
Posts: 758
 Member Since:
2007-04-30
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

--

-----------------------------------------------
Percy Kwong
Trixbox Tech Support - 202.600.3884

Swimminginthought.com


&nbsp

SkykingOH
Posts: 9675
 Member Since:
2007-12-17
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"


&nbsp

jingxi02
Posts: 136
 Member Since:
2007-05-19
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.


&nbsp

SkykingOH
Posts: 9675
 Member Since:
2007-12-17
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"


&nbsp

lagreca
Posts: 123
 Member Since:
2007-03-09
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?


&nbsp

jmallari
Posts: 2
 Member Since:
2007-05-25
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..


&nbsp

percykwong
Posts: 758
 Member Since:
2007-04-30
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

--

-----------------------------------------------
Percy Kwong
Trixbox Tech Support - 202.600.3884

Swimminginthought.com


&nbsp

SkykingOH
Posts: 9675
 Member Since:
2007-12-17
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"


&nbsp

KodaK
Posts: 1885
 Member Since:
2006-06-14
Quote: I don't think we need
Fri, 05/16/2008 - 8:39am
Quote:
I don't think we need to do that. Let's figure out what is wrong.

But if you do, record it and post it on youtube.

--

WARNING: I no longer actively participate in these forums. My thoughts on trixbox in a nutshell: http://www.youtube.com/watch?v=q4xBMkWu1pE Use AsteriskNOW instead.


&nbsp

lagreca
Posts: 123
 Member Since:
2007-03-09
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


&nbsp

SkykingOH
Posts: 9675
 Member Since:
2007-12-17
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"


&nbsp

KodaK
Posts: 1885
 Member Since:
2006-06-14
Turn off apic by editing
Sun, 05/18/2008 - 6:06pm

Turn off apic by editing your grub.conf and adding "noapic" to the kernel paramaters.

--

WARNING: I no longer actively participate in these forums. My thoughts on trixbox in a nutshell: http://www.youtube.com/watch?v=q4xBMkWu1pE Use AsteriskNOW instead.


&nbsp

SkykingOH
Posts: 9675
 Member Since:
2007-12-17
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"


&nbsp

KodaK
Posts: 1885
 Member Since:
2006-06-14
That's the only way I know
Sun, 05/18/2008 - 6:19pm

That's the only way I know of to get rid of virtual IRQs. I don't even know if virtual IRQs are all that bad, honestly. I should investigate that a bit more sometime.

--

WARNING: I no longer actively participate in these forums. My thoughts on trixbox in a nutshell: http://www.youtube.com/watch?v=q4xBMkWu1pE Use AsteriskNOW instead.


&nbsp

far182
Posts: 82
 Member Since:
2007-07-18
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.


&nbsp

SkykingOH
Posts: 9675
 Member Since:
2007-12-17
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"


&nbsp

lagreca
Posts: 123
 Member Since:
2007-03-09
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.


&nbsp

admin@ipx.co.nz
Posts: 1
 Member Since:
2007-12-01
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


&nbsp

mrbostn
Posts: 77
 Member Since:
2007-05-01
Pfsense and nics
Wed, 06/11/2008 - 1:21pm

1. Install Pfsense 1.2r4, or whatever the latest version is. Traffice shapping is better than your version. (Ver 1.3 should have even better traffice shapping)
2. Install Intel NICs in your trixbox, AND Pfsense box.


&nbsp

lagreca
Posts: 123
 Member Since:
2007-03-09
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?


&nbsp

far182
Posts: 82
 Member Since:
2007-07-18
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.


&nbsp

johannabartley
Posts: 8
 Member Since:
2008-07-30
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.


&nbsp

NameOfTheDragon
Posts: 17
 Member Since:
2007-08-19
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


&nbsp

lagreca
Posts: 123
 Member Since:
2007-03-09
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.


&nbsp

ibgp3
Posts: 24
 Member Since:
2008-10-29
Modems
Thu, 02/05/2009 - 8:20am

Everything here fits with the idea of chipset overload in the modem. The only quality issue we had was when we were running multiple Citrix connections. Phone quality went to ----.
Looks like I want to investigate a better modem option.
Anybody solve problems by upgrading to one of these?

Below is a list of approved cable modems that can be used on the Road Runner network.
3COM
AMBIT
Arris
CISCO
COM21
Ericsson/Aastra
Linksys
Motorola
NetGEAR
SA
SMC
TCE/RCA
Terayon
Toshiba
ZyXEL

Vendor Model

--------------------------------------------------------------------------------

3COM CMX
3CR29220
3CR29221
3CR29223

--------------------------------------------------------------------------------

AMBIT 60194E USB h/w 1.6
60194E USB h/w 1.8
60237EUW h/w 4.3
60194E USB h/w 1.13
60678EU h/w 1.12
60740EU h/w 4.6/4.7
60740EUW h/w 4.6/4.7
U10C018 h/w 1.20
U10C019 h/w 4.10
U10C017 h/w 2.22
U10C020 h/w 4.10
U10C022 h/w 2.33

--------------------------------------------------------------------------------

Arris TM402-P/G h/w 6/7/8/32
TM502A/G h/w 02
TM508 h/w 07
TM512 h/w 07

--------------------------------------------------------------------------------

CISCO 924
905

--------------------------------------------------------------------------------

COM21 DP1010/CP3001
DP111
DP1110
DP1110XB

--------------------------------------------------------------------------------

Ericsson/Aastra HM200c Zat510/102

--------------------------------------------------------------------------------

Linksys BEFCMUH4

--------------------------------------------------------------------------------

Motorola DM100
SB3100
SB4100
SB4101
SB4200
SB4220
SB5100
SB5101
SB5120 h/w 1/4
SBG1000
SBG900 h/w 2/3
SBG940
CG4501
SBV4200
SBV5121
SBV5220

--------------------------------------------------------------------------------

NetGEAR CG814W
CG814WG h/w 1.02
CG814CPR-2TCNAS h/w 1.03
CG814WG v2 h/w 1.03
CG814WG CPR h/w 1.03

--------------------------------------------------------------------------------

SA DPX100
DPX110
DPX2100
DPC2100 h/w 1.1
DPC2100/r2 h/w 2.0-2.1
DPR362
DPR2320 h/w 1.2
DPX2203 h/w 1.1
DPX2203 h/w 2.1
DPC2203 h/w 1.1

--------------------------------------------------------------------------------

SMC 8013WG h/w 1D
8014CPR h/w 1A & 1B
8014WG h/w 1A
8014WG-SI h/w 1A

--------------------------------------------------------------------------------

TCE/RCA DCM205
DCM215
DCM225/226
DCM235/R
DCM245
DCM305
DCM315
DCM325
DCM425 h/w version 4.0/4.1
DCW615
DCW725 h/w version 4.0/4.1/5.0

--------------------------------------------------------------------------------

Terayon ECM100/110
TJ615
TJ715

--------------------------------------------------------------------------------

Toshiba PCX1000
PCX1100
PCX1100u
PCX2000
PCX2200
PCX2500

PCX2600 h/w 19.0.0/19.0.1
PCX5000

--------------------------------------------------------------------------------

ZyXEL 944S
964 CR h/w 3.6
964 APR h/w 3.8
974H h/w AE52


&nbsp

SkykingOH
Posts: 9675
 Member Since:
2007-12-17
You say 'Multiple Citrix
Thu, 02/05/2009 - 8:45am

You say 'Multiple Citrix Connections'

DOCSIS cable modems have a very low session limit. We have run into this issue with multiple SIP sessions and large terminal services deployments.

Can you put the Citrix sessions on a VPN? That will make them appear to be just a couple of connections to the DOCSIS layer. It will also help you set QoS as you will have a single flow to manage.

--

Scott

aka "Skyking"


&nbsp

ibgp3
Posts: 24
 Member Since:
2008-10-29
Citrix sessions
Thu, 02/05/2009 - 9:37am

Gotomeeting comes up Citrix. I am scratching my head about VPN to them.

Besides, I thought you were the guy who blamed it all on the modems.

The brand name on this one makes me tempted to try it:
http://cgi.ebay.com/Cisco-uBR924-uBR900-924-Cable-Modem-4-Port-Ro...


&nbsp

SkykingOH
Posts: 9675
 Member Since:
2007-12-17
Quote: Besides, I thought
Thu, 02/05/2009 - 9:56am
Quote:
Besides, I thought you were the guy who blamed it all on the modems.

I am not sure where you ever got that idea. I find the problem.

You said Citrix sessions not a net meeting provider, I thought you had a group of users on thin clients.

Don't buy the uBR900 it's DOCSIS 1.0 (very old RF modem standard). You won't have access to the higher tier speeds.

You can swap all the modems out in the world but if you are not doing something about QoS in the form of prioritizing and scheduling packets then the problems will continue. Since you only have control up you your interface on the modem if your provider is over subscribed there are no remedial actions you can take to correct the situation.

No magic buttons (Ethan sells those).

--

Scott

aka "Skyking"


&nbsp

ibgp3
Posts: 24
 Member Since:
2008-10-29
I stand corrected
Thu, 02/05/2009 - 10:19am

I stand corrected,Sir.
.....but in the situations where every other part of the setup has been changed out to no avail....

...where did I get the idea?

"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. "

...and that is a 924, is that better?


&nbsp

SkykingOH
Posts: 9675
 Member Since:
2007-12-17
Quote: "The chips used in T1
Thu, 02/05/2009 - 12:18pm
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 quoted that statement I did not make it.

It's nothing to do with the chipsets is the underlying transport technology. DOCSIS has many limitations on session setup and tear down where Ethernet is mapped to the DOCSIS RF technology. Keep in mind it is all happening at layer 2.

--

Scott

aka "Skyking"


&nbsp

ibgp3
Posts: 24
 Member Since:
2008-10-29
cisco 924
Fri, 02/06/2009 - 5:21am

So the limitation is in the protocol, and not the chipsets.
Then the make and model will not matter much.
Would the expectation be that DSL is signifigantly better, or is anything short of T1 sub-standard?


&nbsp

SkykingOH
Posts: 9675
 Member Since:
2007-12-17
What is sub-standard? Your
Fri, 02/06/2009 - 6:35am

What is sub-standard? Your chipset comment confuses me, routers have different firmware that can impact voice quality.

You have not told us about your traffic levels and an overview of your network. It seems you are grasping at straws.

What does the network look like?
How are you using it?
What exactly is the issue you are trying to solve?

--

Scott

aka "Skyking"


&nbsp

ibgp3
Posts: 24
 Member Since:
2008-10-29
I'm reading the thread and
Fri, 02/06/2009 - 12:41pm

I'm reading the thread and trying to avoid problems before they arise.
So far there have been no user complaints, and I doubt that anyone else noticed the problem I mentioned with the Citrix app.
My office is growing rapidly and my satisfaction could change suddenly. I would like to have a quick fix ready.
Pardon me for trying to pick your brain for generalities.


&nbsp

lagreca
Posts: 123
 Member Since:
2007-03-09
I'm still having strange
Thu, 02/12/2009 - 7:00pm

I'm still having strange VOIP glitches. We have a T-1 with a pfSense firewall and running Trixbox 2.6.1.13.

Here are the results of one of my tests:
http://www.testyourvoip.com/details.html?id=1NB3J0
http://www.testyourvoip.com/details.html?id=4Z684C

Let me start off by saying I don't think the problem is directly related to the Trixbox. I think the problem is more of a traffic shaping issue on the pfSense, however I'm not positive. I'm looking for others that might be able to give me some input on how to fix things.

One possibility is we have a hybrid T-1 from TelePacific with 6 "analog" lines. Its basically VOIP using their Adtran. However, we are NOT using any of the "analog" lines, only data on the T-1 for our trixbox to our ITSP's. I've heard of another user in this situation had problems. When we first got it setup, everything worked great, then a few months into it, everything went bad.

The problem is that VOIP gets garbled, and it consistently on the download side. I am using traffic shaping on the pfSense, and the queues are being utilized, but the VOIP still gets garbled.


&nbsp

citapinc
Posts: 245
 Member Since:
2007-10-13
Our first Trixbox
Fri, 03/06/2009 - 8:58pm

Our first Trixbox installation was having the same issue with a client who was on a DSL line. We switched them from DSL over to cBeyond T1 and used their SIP Connection instead of analog lines and all their issues went away.

Hope that helps.

Dean
Anaheim, CA


&nbsp

swfchang
Posts: 6
 Member Since:
2009-03-26
I have consistently choppy
Wed, 08/12/2009 - 8:11pm

I have consistently choppy voice (somtimes it's so bad that the call would just drop) on the PSTN end. AND I'm calling POTS lines via my TDM card. When I call from IAX extensions (both within LAN and remote), PSTN end always hear choppy voice after a few seconds into the conversation. The strange thing is when I'm calling from SIP extensions (both LAN and remote), they all sounded perfect. Anyone can help how to setup IAX to improve call quality ?

P.S. PSTN end always hear choppy voice whether the calls were initiated from IAX extensions or PSTN initiated calls to IAX extensions.

Stephen


&nbsp

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.