* You are viewing Posts Tagged ‘timing source’

Use Of “timing Test”

I’m interested in using the testing a non-DAHDI timing source to have some assurance I’m on a system that’s not likely to give me grief over timing-related issues.

I’m familiar with dahdi_test and the guideline of needing 99.975% accuracy for reliable conferencing and such. (Is that an accurate guideline? Where did it come from?)

When I started looking at using the timerfd timing source instead, it seemed the “timing test” command was my go-to for checking it, but I’m not sure it’s testing the timing source at the same level dahdi_test did, as it’s only testing 50 ticks per second? How much do I really need? Is it worthwhile to go up to “timing test 1024″ to match?

Would really love an authoritative answer to this question, or at least a direction to go in to figure this one out myself.

I tried asking this question on Server Fault first, by the way–if anyone wants the rep for answering it there, here’s the link: http://serverfault.com/questions/517556/interpreting-and-using-the-asterisk-timing-test-command

Asterisk 1.8 Streaming MOH Timing Interface

We are running Asterisk with an uptime of 40 weeks. Just today our streaming music on hold stopped working. I remember when we had first installed 1.8 we had an issue where the streaming music on hold would not work because Music On Hold was using the DAHDI timing module. We needed the DAHDI timing module loaded so that paging would work. However, at that time we upgraded to and the system loaded properly with both the dahdi and pthread timing module with Music On Hold using the pthread timing module. In that state, everything worked properly – Streaming Music On Hold worked as well as Paging. That has all continued to work properly for the last 40 weeks.

I’m wondering of for some reason the Music on Hold service is now using the DAHDI timing module because when I do “module show like timing” I see:
CLI> module show like timing Module Description Use Count res_timing_dahdi.so DAHDI Timing Interface
res_timing_pthread.so pthread Timing Interface
2 modules loaded

I believe that the pthread used to show a use count of at least 1 with the Music On Hold service using that timing source. I suspec that if I restart the Asterisk service everything will come back up the way that it did last time. However, I’m wondering if there would be a way to switch the Music On Hold module back to using pthread timing without restarting the Asterisk service.

Thanks, Bob

Asterisk Virtualization

Last Updated: 29-Nov-2013

If you are about to dive into the process of Asterisk virtualization or are considering the options for any VoIP Software or PBX phone system then some primary issues might be preventing you from moving (e.g. the lack of proper timing as you need it for IAX2 trunking). If this is your case, consider these options and the pro and cons of each one:

  • OpenVZ - Better resource usage, lower overhead. Primary issue is how to grant access to host node timing source (physical device, or dahdi_dummy in /dev/dahdi/) to the containerized Asterisk process.
  • KVM - Higher overhead, easier installation, ‘true virtualization’. Primary issue is not timing per se, but KVM scheduling. Timing source, while present from dahdi_dummy natively may still not get proper scheduling by KVM process. This could also affect general call quality (even non IAX2 trunked voice), DTMF, etc.
  • VMware – They are moving all server products to their ESXi engine. (The old VMware “server” and ESX products are moving to legacy status – with these you could actually do stuff on the kernel). ESXi is no longer a kernel you can mess with, can’t install drivers, etc. ESXi is being treated as an appliance that you cannot and should not touch (even authorized partners like HP only get to add software through VMware). Many of these devices are not (and will not be) recognized by the VMware kernel, so forgot about host support. At best you can pass-through the device to a single guest, but then you lose the whole point of a shared timing source.
  • XEN - Virtual machines can use both hardware- or paravirtualization. It has been used to separate machines where people should do their sip-registration (internet / intranet /
    pstn-gateway) and the actual dial-beast.

In order to take the most out of Asterisk virtualization besides easy scaling and ability to perform an upgrade in no-time, upgrade to the latest version of Asterisk, as it has a newer timing source that don’t rely on Dahdi and a complete rewrite of ConfBridge which doesn’t require Dahdi for mixing at all.

Asterisk On VM With NO DAHDI Hardware

I know that Asterisk on virtual machine require a timing source. What would you suggest to use for timing? We will plan to use only SIP and IAX2.

meetme with timerfd

We use MeetMe with res_timing_dahdi as the timing source, and once a while we get the following error which then causes Asterisk to crash/restart (with safe Asterisk).

ERROR[6518] res_timing_dahdi.c: Failed to configure DAHDI timing fd for 0 sample timer ticks

According to the following from Asterisk wiki, DAHDI is required for MeetMe.

“Some confusion has arisen regarding the fact that non-DAHDI timing interfaces

are available now. One common misconception which has arisen is that since

timing can be provided elsewhere, DAHDI is no longer required for using the

MeetMe application. Unfortunately, this is not the case. In addition to

providing timing, DAHDI also provides a conferencing engine which the MeetMe

application requires.

I’m curious if DAHDI require/use res_timing_dahdi for it to run/function properly. Can we use res_timing_timerfd (instead of res_timing_dahdi) along with DAHDI for MeetMe?

Thanks a lot,

better timing source for an asterisk gateway


I have to make an asterisk gateway in front of several other asterisk.
This gateway will essentialy be used for outbound call.
This gateway will be connected to other asterisk by IAX trunk, outbound
call will use SIP trunk (voip provider or patton isdn).
I have a TE220BF available than i can use for dahdi timing source. Is a
good idea, or this will give me zero benefit for timerfd timing source
(will host this gateway on debian squeeze or centos 6.2) ?