Best Timing Source?

Home » Asterisk Users » Best Timing Source?
Asterisk Users 8 Comments

I am currently having a voice quality problem with one of our Asterisk servers. We have checked the network and we have found no problems that could cause the voice to sound cracked and with small interruptions. I am looking at the timing source for Asterisk and it is currently using timerfd even though we have an E1 card installed. Is timerfd better than dahdi? Any recommendations to test if timing may be a problem for voice quality and DTMF?

Telecomunicaciones Abiertas de México S.A. de C.V. Carlos Chávez
+52 (55)9116-91161

8 thoughts on - Best Timing Source?

  • Carlos Chavez wrote:

    What is the scenario and the channels involved? Timing is only used for things such as playback, music on hold, and ConfBridge. If it’s strictly a two party call then Asterisk forwards media as received.

  • The problem appears on all calls, no matter the source or destination. There are desk phones, softphones and a couple SIP trunks to another office. They all experience the problem. Calls between extensions, from or to the E1, from or to trunks. The only scenario left to try is connecting calls only via the E1 so we completely eliminate the network side of things and se if we get the same behaviour. During calls you can hear some background noice and interruptions in the voice. DTMF fails when we try to dial to external IVR.

    I do not really believe that the fault is in the Asterisk server but I have to eliminate all posibilities on my side before I can lay blame on the network infrastructure. I was also just wondering if DAHDI
    would not be a better timing source for Asterisk since it is hardware based?

  • Carlos Chavez wrote:

    Either timerfd or dahdi should perform the same. I wouldn’t expect dahdi to improve things unless something was really wrong on the system itself.

  • Rule One: Start your own topics — don’t jump in on someone else’s, unless it’s actually relevant.

    Rule Two: Type your reply *after* the thing you are replying to.

    Your SIP trunk provider will know how to connect an Asterisk box to them.
    That, after all, is what most people are going to be connecting.

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

    Anyone with this server and Asterisk ever had issues like these?

  • 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

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

    Telecomunicaciones Abiertas de México S.A. de C.V. Carlos Chávez
    +52 (55)9116-91161

  • This is the bit I mean, but if you have calls going over the E1 that are okay then its probably not this.

    |# span=,,,,[,yellow] # # All T1/E1 spans generate a clock signal on their transmit side. The # 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. |