<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Been doing some more troubleshooting on this issue. Started up
TCPDump and let it run for a whole day, then loaded the file into
Wireshark. What is interesting is that there doesn't seem to be any
lost packets. The RTP sequence numbers are always contiguous.
However, if I output the streams as .au files and listen to them
there are obvious points where the audio just goes silent in the
middle of the person speaking, and it effects both directions.
Doesn't make any sense.<br>
<br>
<br>
<div class="moz-cite-prefix">On 4/4/2018 10:33 AM, Brent Davidson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4a94024f-fb63-293b-ffc4-2d6f4de14702@texascountrytitle.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
At the first office, I replaced all the wiring except the in-wall
stuff. Checked all the cables to make sure they were correct.
I've done cabling for the last 20+ years, so I've usually got a
good feel for that. Make all my own cables and do all my own
wiring. I still make a habit of checking that first because you
never know when somebody is going to decide to swap out a cable
with one they just pulled out of hammerspace for one reason or
another.<br>
<br>
All of the duplex and flow control settings are set to
auto-negotiate. The switch logs don't show any unexpected amount
of collisions, and no receive or transmit errors.<br>
<br>
I might add that I have the same setup in 8 offices. Right now,
only two of the offices are reporting problems. All of these
offices were previously operating fine with Asterisk 1.4
installations. Over the past year all offices were upgraded to
new phone/fax servers running Asterisk 13. All offices ran fine
for several months until the one problem office started having the
audio drop-outs, and then a few weeks later the second office
started having the same issue.<br>
<br>
Is there anything in the pjsip code that might cause RTP latency
if reverse DNS lookup timed out for one reason or another?<br>
<div class="moz-signature">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<title></title>
<div class="moz-signature"><br>
<br>
</div>
</div>
<div class="moz-cite-prefix">On 4/3/2018 5:20 PM, Dave Platt
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9cb4294b-9764-8f27-1079-d595b02681d2@radagast.org">
<blockquote type="cite">
<pre wrap="">I looked at your network diagram. Try checking the configuration of the
Ethernet ports on the firewall and the Asterisk box. Make sure they are
set to auto-negotiate and not set to a fixed speed and fixed duplex.
I have found in the past that if one end of a link is expecting auto-
negotiation (as the switches probably are) and the other end is expecting
a fixed configuration, things can degrade to half-duplex trying to talk
to full-duplex, resulting in lots of collisions and packet loss when there
is any kind of significant traffic.
Your description would be consistent with the firewall introducing lots of
LAN collisions when busy, in the central gigabit switch, even if the VoIP
traffic isn't passing through the firewall.
</pre>
</blockquote>
<pre wrap="">Also, check the wiring. Check each individual RJ-45 jumper, *and* the
in-house wiring, with a proper tester that can verify that the
individual pairs are hooked up correctly.
I've seen all kinds of hell occur, in situations where somebody used
telco-type RJ-45 connecting cables, in place of proper Ethernet
connecting cables.
The problem is this: in a telco RJ-45 cable (such as was/is often used
for proprietary telephone systems) the individual wires are either not
in twisted pairs, or are twisted-pairs in a 1-2 3-4 5-6 7-8 arrangement.
These work fine for analog connections. They're latent-death-on-wheels
for Ethernet.
Ethernet only works well if you connect the pairs as a 1-2, 3-6, 4-5,
7-8 arrangement, because this is how the signals are sent electrically.
Using the correct connections ensures that the signals on each pair are
"balanced" electrically - that is, the two wires in each twisted pair
are carrying equal-but-opposite currents for the two sides of an
individual signal. This minimizes electrical coupling between pairs,
and thus minimizes crosstalk.
If you use a telco-style cable (these are often black, and flat), or if
you use what looks like an Ethernet cable but which had its wires
"punched down" to the connector in the wrong pairing, things go very
badly indeed. One twisted pair might be carrying one TX signal and one
RX signal. This pretty much *guarantees* terrible cross-talk between
the two.
The symptoms of this can be as was related... the connection appears to
work OK under light load, when there's usually traffic flowing in only
one direction at a time. However, when you put a bidirectional load on
the connection, the signals going from A to B and from B to A cross-talk
with one another, leading to a very high rate of corrupted/dropped
packets on the network.
This will often show up in the end device's Ethernet packet statistics,
if you can get to them... look for a high rate of dropped or "bad"
packets, FCS (frame sequence check) errors, etc.
I've seen a fair number of cheap "Ethernet" cables that had been
manufactured wrong. You should see a color pairing such as
<a class="moz-txt-link-freetext" href="http://www.hardwaresecrets.com/how-gigabit-ethernet-works/" moz-do-not-send="true">http://www.hardwaresecrets.com/how-gigabit-ethernet-works/</a>
indicates - pins 4 and 5 are a pair (blue, and white-and-blue), and the
next-outer pins are also a pair (orange, and white-with-orange).
If you see a pattern such as "white-with-green, green, white-with-blue,
blue, white-with-orange, orange, white-with-brown, brown" where there
are four color-matched pairs of wires next to one another, you've got a
bad cable.
The same error can occur when building wiring is "punched down" to the
RJ-45 jacks.
A good Ethernet cable-pair tester can spot such things pretty quickly.
</pre>
</blockquote>
<br>
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2">
<br>
<br>
<hr style="border:none; color:#909090; background-color:#B0B0B0;
height: 1px; width: 99%;">
<table style="border-collapse:collapse;border:none;">
<tbody>
<tr>
<td style="border:none;padding:0px 15px 0px 8px"> <a
href="http://www.avg.com/internet-security"
moz-do-not-send="true"> <img
src="http://static.avast.com/emails/avg-mail-stamp.png"
alt="AVG logo" moz-do-not-send="true" border="0"> </a>
</td>
<td>
<p style="color:#3d4d5a;
font-family:"Calibri","Verdana","Arial","Helvetica";
font-size:12pt;"> This email has been checked for
viruses by AVG antivirus software. <br>
<a href="http://www.avg.com/internet-security"
moz-do-not-send="true">www.avg.com</a> </p>
</td>
</tr>
</tbody>
</table>
<br>
<a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1" moz-do-not-send="true"> </a></div>
<br>
<b>WARNING-FRAUDULENT FUNDING INSTRUCTIONS</b><br>
<br>
Email hacking and fraud are on the rise to fraudulently misdirect
funds. Please call your escrow officer immediately using contract
information found from an independent source, such as the sales
contract or internet, to verify any funding instructions received.
We are not responsible for any wires sent by you to an incorrect
bank account. <br>
</blockquote>
<br>
<br><html><body><b>WARNING-FRAUDULENT FUNDING INSTRUCTIONS</b><br><br>Email hacking and fraud are on the rise to fraudulently misdirect funds. Please call your escrow officer immediately using contract information found from an independent source, such as the sales contract or internet, to verify any funding instructions received. We are not responsible for any wires sent by you to an incorrect bank account. </body></html>
<br></body>
</html>