Post by Olle E. JohanssonPost by Rich AdamsonPost by AndresPacket 50 - Delay 50ms
Packet 51 - Delay 5ms
Packet 52 - Delay 5ms
Packet 53 - Delay 50ms
Packet 54 - Delay 5ms
Packet 55 - Delay 5ms
Is there anyway to space them out evenly at 20ms??
The 20 ms is not the inter-packet timing, its the relative content of what's
within the packet. In other words, the packet contains 20ms of encoded voice.
If the inter-packet times (delays) are large, as they would seem to be
in your example, then something else is not right. Possibly a half-duplex
ethernet connection, something else running on the server, router buffers,
etc.
On a typical * --> C7960 local call, I generally see from 1ms to 20ms
inter-packet delays. Seldom (if ever) anything above 20ms.
I gather from your reply that there are recommendations regarding the
ethernet connection on your Asterisk server? half-duplex seems bad.
Could you elaborate a bit on that?
Yes, half-duplex ethernet connections "can" cause significant problems
depending on the actual load. In very general terms, a half duplex
ethernet interface can run up to about 20% utilization before collisions
occur, whereas a full duplex connection can run close to 100% without
dropping packets. Those rough numbers apply to both 10 meg and 100 meg
ethernets.
If a collision or dropped packet occurs (in a voip udp environment) there
is no way to retransmit the missing/damaged packet. Missing one packet isn't
a big deal, but if you have collisions and/or dropped packets, there is a
very high probability that lots of packets will be dropped. If too many
are dropped, you'll hear the result in the undecoded voice as choppy
voice.
For whatever reason, most unix systems (and MS systems for that matter)
do not give you a convenient way to configure (or even check) "how" your
ethernet adapter negotiates the connection. There are no official
"standards" as to how the negotiation process determines half vs full,
and systems get it wrong about 50% of the time. (As professional network
performance consultants, we've diagnosed a very large number of problems
like this in corporations around the US over the last ten years. Think in
terms of a unix system trying to negotiate half vs full at the exact same
time as the switch is doing the same thing "without" actually communicating
to the opposite end of the cable.)
If the ethernet traffic is low, no one actually notices the problem. But,
as traffic increases (multiple RTP sessions, etc) the problem begins to
occur and the average technical person doesn't have a clue what is really
going on. What makes it difficult to identify/diagnose is that each time
the system is rebooted (and each time a Cat 5 cable is disrupted), the
half vs full negotiation happens again and (as mentioned) 50% of the time
one end gets it wrong. Therefore the performance problem tends to come
and go, and support folks typically don't associate the performance
issue with the actual half/full problem. (In larger companies, the network
support person might reboot a switch without the * support person
knowing it, and suddenly the * support person has a problem for which
he can't identify what happened.)
Assuming alaw/ulaw codecs in use (about 80k bps), a half duplex 10 meg
ethernet would handle roughly 20-25 rtp sessions before bumping into the
problem (your milage may vary). The majority of the folks on this list
seem to be running home/soho systems and would likely never run into the
issue. But the heavier users will.
What makes this half/full problem even more difficult to diagnose is that
many of these systems have other functions running on them (eg, up2date,
remote database calls, web activity, broadcasts) that can consume a fair
amount of ethernet bandwidth, and the support person is so highly focused
on asterisk they forget some other activity might be impacting their voip
quality. Invariably, a Cat 5 cable disruption or reboot (or something
else) happens at the same time the support person makes a programming or
parameter change, and the person jumps to the conclusion they fixed a
problem with their change when in fact the problem was with their ethernet
connection.
To ensure one never gets bit by the issue, simply ensure that all ethernet
interfaces between the asterisk system and the sip phones are statically
defined as full-duplex. (Good luck in finding the utilities that let you
do that on Linux systems. They are out there, but not easy to find.)
The sip phone's negotiation of half vs full is less of an issue as generally
the most traffic it sees is one RTP session. But, to obtain maximum smoke
and ensure highest quality, the phones should be locked at full duplex as
well.
Rich