6 thoughts on - Audio Dropouts During Call

• Well, I now have another office complaining of the audio drop-outs. Logs are showing the same issues.

• 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

  http://www.hardwaresecrets.com/how-gigabit-ethernet-works/

  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.

• Can you provide a link to such a tester?

  I disagree.

  *Certainly*, incorrect pair terminations can cause the sort of problems described, however I haven’t yet come across a cable tester which can identify that a cable correctly connected from end to end with wires {1..8} <-> {1..8}
  is in fact not correctly connected in ethernet 1-2 3-6 4-5 7-8 pairs.

  All cable testers I have so far encountered will check that all wires are correctly connected end to end and not cross connected etc., but have no clue whether the wire joining pin 3 at one end to pin 3 at the other end is twisted together with the cable from pin 4 or pin 6.

  I would be very interested to find such a tester, if you can point us at one.

  Thanks,

  Antony.

• 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.

  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.

  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.

  Is there anything in the pjsip code that might cause RTP latency if reverse DNS lookup timed out for one reason or another?
  **

  –

• Well, I did say a _good_ cable tester, and that means “expensive” 🙂

  I agree, the simple DC-continuity type of cable tester won’t catch more than a fraction of the problems. These inexpensive testers ($50-$100
  range, usually) can diagnose open wires, or cases where the two ends of the cable are wired differently and the signals don’t match up at all. As you correctly point out, they’re useless for “mixed pair” problems since these don’t show up at all on DC. Electrical detection of such problems has to be done in a high-frequency (signal or pulse) domain.

  What you need is a tester which has either or both of two capabilities:

  (1) Crosstalk measurement – excite one pair with a signal, and measure
  the other pairs/wires to see if some of the signal leaks across onto
  them.

  (2) TDR – Time Domain Reflectometry. Excite a pair with a known pulse,
  and measure the voltage across the pair over time. This lets you
  measure the actual impedance of the pair all the way to the “far
  end”. A swapped-pair problem will show up pretty quickly as an
  incorrect (and varying) impedance on the “pair” you are trying to
  drive. TDR can locate broken wires and sorts – not just the fact
  that they’re there, but how far down the cable they are. A good
  TDR setup can even let you “see” things like a place where the cable
  has been bent too sharply or pinched, and the twisted-pair wires
  have been smooshed out of their proper configuration.

  As to specifics, a bit of Google-fu turns out the following possibilities. I haven’t used any of them myself, but the data sheet summaries of capabilities look promising.

  The high-end Fluke cable-testers such as the CIQ-100, DSX-5000, and DSX-8000 would probably work – these are described as being able to locate crosstalk faults and impedance faults.

  Another very interesting device is the PocketEthernet tester, which sells for 199 Euros (less without VAT). It analyzes the wiremap, has TDR capability, and includes a bunch of higher-level diagnostics as well (bit-error-rate, Ethernet link analysis and capabilities-
  announcement, DHCP, ping tests, bit-error-rate testing, etc.). It uses a tablet or smartphone as its GUI (connected via BlueTooth) and generates a pretty spiffy-looking report in PDF format. I don’t know what its sensitivity would be to such problems on a short (e.g. jumper) cable – that’d be a good question to ask the manufacturer.

  For diagnosing signal integrity problems in a building’s installed Ethernet wiring, I’d want to have a device of this sort available. The high-end devices can probably be rented. The PocketEthernet is cheap enough that I’d just buy one if I can to do any work of this sort.

  There’s also another dirt-cheap method for diagnosing bad Ethernet jumpers – substitution. Buy a bunch of known-good CAT-6E (e.g.)
  jumpers from a reliable vendor, and inspect them. Mark them as
  “This is a good one”. If you have a suspect connection, start swapping cables one at a time – replace each jumper with one of your known-good supply and re-test to see if the problem goes away. If it does, take the cable you removed from service and
  _immediately_ cut off both ends right at the connector, and then throw the whole thing into the trash, so that no one will _ever_
  put it back in service. Do not try to salvage, repair, or re-use a bad jumper – life’s too short to try to pinch pennies like that.
  (If you don’t do this, the old cable _will_ come back to haunt you some day.)

• 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.

  –