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?
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…
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…
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…
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…???
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.
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).
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
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)