<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi there,<br>
<br>
In other words you are maybe on 60ms and they are on 20ms or vice
versa. Do a wireshark trace and see if the codecs and ptime agree on
both sides otherwise you will get grabbled sounds.<br>
<br>
<div class="moz-cite-prefix">On 10/29/2013 02:49 PM, Daniel van den
Berg wrote:<br>
</div>
<blockquote cite="mid:526FAEC7.8010804@suretel.co.za" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi there,<br>
<br>
Sounds like codec ptime mismatch...what codec are you using? If
you are using g729 make sure that you and your provider is giving
the same ptime.<br>
<br>
<div class="moz-cite-prefix">On 10/29/2013 11:55 AM, Stelios
Koroneos wrote:<br>
</div>
<blockquote
cite="mid:1383040559.7551.40.camel@localhost.localdomain"
type="cite">
<pre wrap="">On Mon, 2013-10-28 at 14:29 -0400, Eddie Mikell wrote:
</pre>
<blockquote type="cite">
<pre wrap="">All,
The users in our organization are well, quite frankly, sick of phone
service that is being provided. The choppy phone calls, and drop outs
are detrimental to our sales force.
I've tried about everything I can think of.
Moved the asterisk server from VM machine to dedicated machine
More than enough bandwidth
Setting 802.1p = 7
Set Dedicated voice traffic 35% of bandwidth.
Not sure what option would be the best
Put analog lines in the conference room to avoid the dropouts
- leave the sip lines in place for day to day use
Hire a consultant
Ditch the system and buy a pre-packaged system - RingCentral
or some such.
There are no local asterisk professionals who can help, and we are a
little leery of opening up our system to outside consultants.
Anyone else face the above, and finally abandoned Asterisk for a
commercial system?
We have 167 users.
I use Grandstream GXP 2100 on the desktop and Polycom ip6000 for the
conference rooms.
Suggestions welcome.
</pre>
</blockquote>
<pre wrap="">A general rule of thump after several years with voip
Voip turns out to be the "canary in the coal-mine" of a network. The
smallest change or problem will manifest itself as a voip issue no
matter what.
Now to some practical advice
Voip was designed for LAN's, The moment voip packets leave your lan and
go into a WAN of any sort, it could be the source of frustration for
many reasons.
1) Lots of routers/modems are not build to handle intense voip traffic.
voip generates lots of small in size UPD packages. In most of the cases
the routers/modems bridging your lan with the wan have no problem
handling them BUT what i have found is that once you get over a
threshold of traffic its possible the routers/modem can not cope with
it, mainly because the large number of packets they have to process.
In most enterprise grade routers the specs give you 2 numbers for the
size of data the router can handle.
total throughput and pps (packets per second).
Usually total throughput is calculated using a packet size of around
1500bytes and it takes the router the same resources to process a 1500
bytes package as it does a 90bytes packet of a g729 call, as it just
looks at the headers and not the payload.So yes your router can handle
60Mbits (of 1500byte frames) which is about 5000 packers per second but
for voip that translates to less than 4Mbits of data (5000 packets of 90
bytes)
I think you can get the picture
2) Because of 1) its possible that your ISP has issues, especially if
its handling lots of voip traffic while its equipment is not optimized
for that.
3) QOS and queing in general
Whatever you do with QOS to get a better priority/quality, the dirty
secret is, you can only control what YOU send, not what you receive.
And even that is true till your modem/router. Once the packet is gone
you have no control of how it will be handle by all intermediates till
it reaches its destination.
You have no idea if qos is honored by ALL hops and what kind of queuing
they apply (if they do) to that port/service/qos mark
That beeing said, its possible that you *might* have much better luck
with sip and sip rtp than with iax rtp if your isp and all its
interconnects bother to offer qos for rtp.
Now for receiving it can be even harder if your isp does not provide
correct priority queuing for the rtp stream, as latencies can build fast
especially on "busy hours" (which happen to be the same hours people use
their phones the most...) where people download stuff,emails etc.
ping.icmp and all the other networking monitoring tools/protocols could
be an indicator BUT its most probable that they will be handled by the
isp and its interconnects at the higher qos priority
The only way to see how rtp traffic is handled is to run rtp traffic.
The only way around this is a "dedicated circut" MPLS or similar between
the points of interest (i.e offices), with specific SLA which usually
means much much higher costs.
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">Finally my 2 cents for troubleshouting.
Check the network first !
Find what triggers the problem.
Is it something that happens all time regardless of traffic ?
is it periodic ? (when bw goes over X percent, or at a specific time of
day ?)
Try different qos settings/priority queuing on the router
</pre>
<blockquote type="cite"> </blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>