mirror of
https://github.com/asterisk/asterisk.git
synced 2025-10-31 02:37:10 +00:00
d8d5e38f65
This document specifies the timing modules available in Asterisk beginning with Asterisk 1.6.1. The document goes into detail about the differences between each and gives a general overview of what timing is used for in Asterisk. There is also a section which can be used to help customize your setup or to troubleshoot timing issues you may have. I also added messages to the DAHDI timing test used in res_timing_dahdi.c that points to this new documentation if people experience problems. Big thanks to all who contributed comments on this. (closes issue #14490) Reported by: mmichelson Patches: timing.txt uploaded by mmichelson (license 60) Review: http://reviewboard.digium.com/r/164/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179937 65c4cc65-6c06-0410-ace0-fbb531ad65f3
91 lines
5.1 KiB
Plaintext
91 lines
5.1 KiB
Plaintext
Asterisk Timing Interfaces
|
|
-------------------------------------
|
|
In the past, if internal timing were desired for an Asterisk system, then the
|
|
only source acceptable was from DAHDI. Beginning with Asterisk 1.6.1, a new
|
|
timing API was introduced which allows for various timing modules to be used.
|
|
Included with Asterisk are the following timing modules:
|
|
|
|
res_timing_pthread.so
|
|
res_timing_dahdi.so
|
|
res_timing_timerfd.so (Beginning with Asterisk 1.6.2)
|
|
|
|
res_timing_pthread uses the POSIX pthreads library in order to provide timing.
|
|
Since the code uses a commonly-implemented set of functions, res_timing_pthread
|
|
is portable to many types of systems. In fact, this is the only timing source
|
|
currently usable on a non-Linux system. Due to the fact that a single userspace
|
|
thread is used to provide timing for all users of the timer, res_timing_pthread
|
|
is also the least efficient of the timing sources and has been known to lose
|
|
its effectiveness in a heavily-loaded environment.
|
|
|
|
res_timing_dahdi uses timing mechanisms provided by DAHDI. This method of
|
|
timing was previously the only means by which Asterisk could receive timing. It
|
|
has the benefit of being efficient, and if a system is already going to use
|
|
DAHDI hardware, then it makes good sense to use this timing source. If,
|
|
however, there is no need for DAHDI other than as a timing source, this timing
|
|
source may seem unattractive. For people who are upgrading from 1.4 and are used
|
|
to the old ztdummy timing interface, res_timing_dahdi provides the interface
|
|
to dahdi_dummy, which is ztdummy's replacement.
|
|
|
|
res_timing_timerfd uses a timing mechanism provided directly by the Linux
|
|
kernel. This timing interface is only available on Linux systems using a kernel
|
|
version at least 2.6.25 and a glibc version at least 2.8. This interface has
|
|
the benefit of being very efficient, but at the time this is being written,
|
|
it is a relatively new feature on Linux, meaning that its availability is not
|
|
widespread.
|
|
|
|
What Asterisk does with the Timing Interfaces
|
|
---------------------------------------------
|
|
By default, Asterisk will build and load all of the timing interfaces. These
|
|
timing interfaces are "ordered" based on a hard-coded priority number defined
|
|
in each of the modules. As of the time of this writing, the preferences for the
|
|
modules is the following: res_timing_timerfd.so, res_timing_dahdi.so,
|
|
res_timing_pthread.so.
|
|
|
|
The only functionality that requires internal timing is IAX2 trunking. It may
|
|
also be used when generating audio for playback, such as from a file. Even
|
|
though internal timing is not a requirement for most Asterisk functionality,
|
|
it may be advantageous to use it since the alternative is to use timing based
|
|
on incoming frames of audio. If there are no incoming frames or if the incoming
|
|
frames of audio are from an unreliable or jittery source, then the
|
|
corresponding outgoing audio will also be unreliable, or even worse,
|
|
nonexistent. Using internal timing prevents such unreliability.
|
|
|
|
Customizations/Troubleshooting
|
|
---------------------------------------------
|
|
Now that you know Asterisk's default preferences for timing modules, you may
|
|
decide that you have a different preference. Maybe you're on a timerfd-capable
|
|
system but you would prefer to get your timing from DAHDI since you already are
|
|
using DAHDI to drive your hardware.
|
|
|
|
Alternatively, you may have been directed to this document due to an error you
|
|
are currently experiencing with Asterisk. If you receive an error message
|
|
regarding timing not working correctly, then you can use one of the following
|
|
suggestions to disable a faulty timing module.
|
|
|
|
1. Don't build the timing modules you know you will not use. You can disable
|
|
the compilation of any of the timing modules using menuselect. The modules are
|
|
listed in the "Resource Modules" section. Note that if you have already built
|
|
Asterisk and have received an error about a timing module not working properly,
|
|
it is not sufficient to disable it from being built. You will need to remove
|
|
the module from your modules directory (by default, /usr/lib/asterisk/modules)
|
|
to make sure that it does not get loaded again.
|
|
|
|
2. Build, but do not load the timing modules you know you will not use. You can
|
|
edit modules.conf using "noload" lines to disable the loading of specific
|
|
timing modules by default. Based on the note in the section above, you may
|
|
realize that your Asterisk setup does not require internal timing at all. If
|
|
this is the case, you can safely noload all timing modules.
|
|
|
|
Important Notes
|
|
----------------------------------------------
|
|
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.
|
|
|
|
Starting with Asterisk 1.6.2, however, there will be a new application,
|
|
ConfBridge, which will be capable of conference bridging without the use
|
|
of DAHDI's built-in mixing engine.
|