Weird jitter like problem

Ok… this is really wierd and I’d like to know if anyone has ever seen a similar problem…

When someone calls into my asterisk system (sip to sip) through Broadvoice the call sounds just fine…

When I call out to someone (sip to sip) through broadvoice the person that I’m talking to reports that at first you sound fine but after a little while my voice becomes as digitally sounding and kind of broken up…

Is this jitter? If so why is it only occuring when I dial out, and not when someone calls into me? How do I troubleshoot this?

Thanks,
Dan.Creed@thecreeds.net

Check which codec is being used both ways. It may be different in each direction and a specific codec may be causing the problem.

The codec being used both ways is ulaw…

Still haven’t found an answer to this… can anyone help?

Thanks,
Dan

i’ve had a few callquality problems with bv…

first what type of network setup do you have? give us an overview?

5MB X 512 Business connection… NO NAT… My asterisk system is on a public IP… and I’m a one person business… so never really have more than one call at a time and don’t do any file sharing or downloading big files or anything… My ISP is Charter Communications… I’m going to run some pingprobe and wireshark traces tonight…

Thanks,
Dan

Still haven’t found a solution yet… I did some ping probes and everything looks ok so I did some wireshark (ethereal) traces… It looks like the network card in my server is spitting out less packets that are coming back to me… which would explain why it is only my voice that sounds bad and not the voice coming from my VOIPP (broadvoice)… so what would cause my server to just skip sending out X # of packets? It is my understanding that the incoming and outgoing RTP packets should be of close to the same number and that the larger the difference between the two the more dropped packets you have, the more voice quality problems you have…

Thanks,
Daniel A. Creed

bump

Anyone??? Anyone??? I just can’t seem to fix this problem…

try ping -t (yourbvserverhere) (thats a windows command) and let it run while the call goes. see if a lot of packets drop?

I already did that with Ping Plotter (see www.pingplotter.com)… and I’m not dropping packets or having high latency… this does NOT appear to be a latency or dropped packet issue… its just plain odd… Could I call someone so they could hear what I am talking about…

I think this weekend I’ll try another ATA

Thanks,
Dan

When there is jitter does it normally just sound like dead spots… or does the person sound all “digitally”??? In my case the person sounds like robotic digitally…

Did you ever find an answer to this? I have BV as well. I recently bought a new internet connection because the company I was sharing bandwidth with was full. I now have cox business cable with 7Mb down and 768K up. From what I’ve read, that should be plenty to serve my websites, email, etc and have plenty for a few calls at once. At the moment, I’m the only one even at the office, so there’s only 1 call max. I don’t have dramatic outgoing bandwidth with the sites either

I’m having the problem basically as you described now where when I MAKE a call to someone, I can hear them fine 99% of the time. But they usually say that I’m “breaking up” and the phone is choppy. It doesn’t happen all the time but often enough that it’s not suitable for business. However, when I ask those same people to call me right back, they say it’s MUCH better and we can talk just fine. They say it might break up occasionally, but overall, it’s dramatically better.

So why do I have a problem with an outgoing call, but incoming calls are more or less fine???

My network looks like this:
[CABLE ROUTER]
|
[SONICWALL TZ170]
|
[ASTERISK] [SIPURA 2100]

I don’t know whether to follow up with Asterisk, Cox, SonicWall, Sipura, or someone else.

I believe my bandwidth is more than sufficient and is fairly consistent. I have noticed when running VOIP tests on some sites that Jitter shows fine 90% of the time and then occasionally will show very high and that it is a problem…???

jjblodg:

You should try pinging your outgoing and incoming VOIP provider’s servers to determine if network latency is the issue. Anything over 150ms is likely the cause and in my experience anything over 100ms is bad. It sounds like the connection to your providers outgoing server is slow. I’ve had this problem too, but with both servers.

If you find out that is is network latency, then run a traceroute on the problematic server and figure out where the bottleneck is. If the bottleneck is your VOIP provider or DSL provider then you can complain to them. If it’s somewhere in-between, I’m not sure how to address that.

We’re curently having a periodic issue with high latency because of something between our DSL provider and our VOIP provider.

Mark MacVicar

Take look at forums.digium.com/viewtopic.php?t=15577
It may be not your case but it worth trying…

So I understand this correctly, could somebody look at this and tell me if they agree that there appears to be big problems between my VOIP provider and my network??? I did 3 tracert’s with about 1 or 2 minutes between of both the inbound and outbound servers of Vitelity. It appears that the outbound is worse (which is what people are complaining about).

outbound1.vitelity.net

[code]
Tracing route to outbound1.vitelity.net [64.2.142.18]
3 52 ms 12 ms 13 ms 68.1.8.17
4 12 ms 13 ms 14 ms dukedsrj02-so110.tc.at.cox.net [68.1.15.49]
5 13 ms 12 ms 13 ms 12.124.65.61
6 111 ms 60 ms 33 ms gbr6.attga.ip.att.net [12.123.21.86]
7 49 ms 35 ms 34 ms tbr1.attga.ip.att.net [12.122.12.25]
8 39 ms 39 ms 37 ms tbr2.wswdc.ip.att.net [12.122.10.69]
9 31 ms 32 ms 35 ms ggr1.ascva.ip.att.net [12.123.8.173]
10 37 ms 30 ms 32 ms p2-0.IR1.Ashburn-VA.us.xo.net [206.111.0.61]
11 33 ms 54 ms 35 ms 65.106.3.245.ptr.us.xo.net [65.106.3.245]
12 50 ms 55 ms 51 ms p6-0-0.RAR1.Chicago-IL.us.xo.net [65.106.0.45]
13 76 ms 86 ms 194 ms p6-0-0.rar2.denver-co.us.xo.net [65.106.0.25]
14 76 ms 74 ms 77 ms 65.106.6.26.ptr.us.xo.net [65.106.6.26]
15 76 ms 76 ms 74 ms 207.88.83.78.ptr.us.xo.net [207.88.83.78]
16 81 ms 82 ms 80 ms 66.236.84.206.ptr.us.xo.net [66.236.84.206]
17 104 ms 114 ms 73 ms 64.2.142.18.ptr.us.xo.net [64.2.142.18]

Tracing route to outbound1.vitelity.net [64.2.142.18]
3 11 ms 15 ms 20 ms 68.1.8.17
4 12 ms 16 ms 15 ms dukedsrj02-so110.tc.at.cox.net [68.1.15.49]
5 16 ms 17 ms 21 ms 12.124.65.61
6 112 ms 95 ms 31 ms gbr6.attga.ip.att.net [12.123.21.86]
7 38 ms 37 ms 37 ms tbr1.attga.ip.att.net [12.122.12.25]
8 33 ms 33 ms 35 ms tbr2.wswdc.ip.att.net [12.122.10.69]
9 33 ms 31 ms 36 ms ggr1.ascva.ip.att.net [12.123.8.173]
10 45 ms 31 ms 45 ms p2-0.IR1.Ashburn-VA.us.xo.net [206.111.0.61]
11 33 ms 33 ms 35 ms 65.106.3.245.ptr.us.xo.net [65.106.3.245]
12 164 ms 302 ms 193 ms p6-0-0.RAR1.Chicago-IL.us.xo.net [65.106.0.45]
13 82 ms 139 ms 74 ms p6-0-0.rar2.denver-co.us.xo.net [65.106.0.25]
14 74 ms 75 ms 74 ms 65.106.6.26.ptr.us.xo.net [65.106.6.26]
15 95 ms 78 ms 89 ms 207.88.83.78.ptr.us.xo.net [207.88.83.78]
16 120 ms 77 ms 80 ms 66.236.84.206.ptr.us.xo.net [66.236.84.206]
17 74 ms 72 ms 73 ms 64.2.142.18.ptr.us.xo.net [64.2.142.18]

Tracing route to outbound1.vitelity.net [64.2.142.18]
3 10 ms 10 ms 16 ms 68.1.8.17
4 15 ms 12 ms 19 ms dukedsrj02-so110.tc.at.cox.net [68.1.15.49]
5 38 ms 45 ms 28 ms 12.124.65.61
6 36 ms 32 ms 33 ms gbr6.attga.ip.att.net [12.123.21.86]
7 257 ms 103 ms 53 ms tbr1.attga.ip.att.net [12.122.12.25]
8 33 ms 33 ms 33 ms tbr2.wswdc.ip.att.net [12.122.10.69]
9 32 ms 40 ms 32 ms ggr1.ascva.ip.att.net [12.123.8.173]
10 63 ms 56 ms 121 ms p2-0.IR1.Ashburn-VA.us.xo.net [206.111.0.61]
11 38 ms 34 ms 33 ms 65.106.3.245.ptr.us.xo.net [65.106.3.245]
12 70 ms 58 ms 53 ms p6-0-0.RAR1.Chicago-IL.us.xo.net [65.106.0.45]
13 197 ms 359 ms 486 ms p6-0-0.rar2.denver-co.us.xo.net [65.106.0.25]
14 133 ms 77 ms 278 ms 65.106.6.26.ptr.us.xo.net [65.106.6.26]
15 75 ms 75 ms 79 ms 207.88.83.78.ptr.us.xo.net [207.88.83.78]
16 87 ms 86 ms 122 ms 66.236.84.206.ptr.us.xo.net [66.236.84.206]
17 73 ms 77 ms 74 ms 64.2.142.18.ptr.us.xo.net [64.2.142.18][/code]

those traceroutes look bad around Chicago, send them to your ISP and see what they say.

set up an alternative sip provider and try some calls through them. if the problem goes away you’ll know it’s BV’s fault.

Hello I’m newbie on this. We have a few IP phone in the company and sometimes a trunk that is setup with an VozIP provider for international calls get lost.

When I do a tracert I got this

192.168.1.1 (192.168.1.1) 0.472 ms 0.502 ms 0.544 ms
2 * * *
3 * * *
4 172.21.16.38 (172.21.16.38) 12.665 ms 12.802 ms 12.877 ms
5 static-ip-190157489.cable.net.co (190.157.4.89) 14.662 ms 14.779 ms 14.854 ms
6 10.14.14.126 (10.14.14.126) 182.577 ms 176.441 ms 176.439 ms
7 * * *
8 if-3-2.tcore2.dt8-dallas.as6453.net (66.110.72.6) 239.615 ms 239.791 ms 239.830 ms
9 * * *
10 64.86.78.5 (64.86.78.5) 244.751 ms 234.836 ms 234.711 ms
11 if-22-2.tcore2.ct8-chicago.as6453.net (64.86.79.1) 242.460 ms 260.608 ms 243.184 ms
12 if-3-2.tcore1.w6c-montreal.as6453.net (66.198.96.45) 243.202 ms 240.867 ms 237.576 ms
13 66.198.96.58 (66.198.96.58) 240.951 ms 240.940 ms 239.682 ms
14 te8-3.dr7.mtl.iweb.com (184.107.1.30) 237.827 ms 238.260 ms 238.333 ms
15 67.205.102.9 (67.205.102.9) 231.132 ms 233.240 ms 236.619 ms

what can I do to resolve this?

Re-ask the question without tail ending an existing thread (and with a subject that is precis of the question).

Provide logging from Asterisk.

The only thing that I can tell from your traceorute is that the round trip delay is getting close to the level that is objectional, so you either have an overloaded link or buffer bloat on the path, probably in a place where it can only be fixed by changing ISP.

Unless you are sometime losing packets as a result (not evident on the trace) this may be irrelevant to your main problem. For the main problem you need to get sufficient logging to see who is clearing, and if Asterisk, why (the other end may also provide a reason, but that is rare)