<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 07/04/16 09:00, Carlos Chavez wrote:<br>
    </div>
    <blockquote cite="mid:570578FE.30706@telecomabmex.com" type="cite">On
      4/6/16 2:39 PM, Duncan Turnbull wrote:
      <br>
      <blockquote type="cite">
        <br>
        <blockquote type="cite">    I am starting to think that the
          problem may be in the server hardware itself.  We are using a
          Dell R220 with 8gb of ram and 2 hard disks in a Raid 1
          configuration (Linux Raid).  We are using CentOS 7.  We had to
          remove the raid card from the server to install an E1 card
          (the raid card was Windows only so no loss there really). 
          Internally everything sounds good (from E1 to a conference or
          music) but once you hit a network interface we start getting
          pops and drops.
          <br>
          <br>
              Anyone with this server and Asterisk ever had issues like
          these?
          <br>
          <br>
        </blockquote>
        Just checking you have your E1 timing set to slave off the
        upstream. If not you are going to have E1 sync errors which will
        give you the voice problems you describe
        <br>
        <br>
        <br>
      </blockquote>
          Dahdi_test gives me a 99.97% average.  The problem is present
      on all calls (except calling into the E1 to a conference or to
      MoH).  I am preparing a new server to see if it is a hardware
      issue.
      <br>
      <br>
    </blockquote>
    This is the bit I mean, but if you have calls going over the E1 that
    are okay then its probably not this.<br>
    <br>
    <a class="moz-txt-link-freetext" href="http://www.voip-info.org/wiki/view/Asterisk+PRI">http://www.voip-info.org/wiki/view/Asterisk+PRI</a><br>
    <br>
    <pre><code># span=<span num>,<timing source>,<line build out (LBO)>,<framing>,<coding>[,yellow]

# All T1/E1 spans generate a clock signal on their transmit side. The          
# <timing source> parameter determines whether the clock signal from the far
# end of the T1/E1 is used as the master source of clock timing. If it is, our
# own clock will synchronise to it. T1/E1's connected directly or indirectly to
# a PSTN provider (telco) should generally be the first choice to sync to. The
# PSTN will never be a slave to you. You must be a slave to it.
#
# Chose 1 to make the equipment at the far end of the E1/T1 link the preferred
# source of the master clock. Chose 2 to make it the second choice for the master
# clock, if the first choice port fails (the far end dies, a cable breaks, or
# whatever). Chose 3 to make a port the third choice, and so on. If you have, say,
# 2 ports connected to the PSTN, mark those as 1 and 2. The number used for each
# port should be different.
#
# If you choose 0, the port will never be used as a source of timing. This is
# appropriate when you know the far end should always be a slave to you. If the
# port is connected to a channel bank, for example, you should always be its
# master. Any number of ports can be marked as 0.

# Incorrect timing sync may cause clicks/noise in the audio, poor quality or failed
# faxes, unreliable modem operation, and is a general all round bad thing.
</code></pre>
    <br>
  </body>
</html>