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…
We are running Asterisk 188.8.131.52 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 184.108.40.206 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 -…
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:
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 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…
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) ? Thanks.
The Asterisk Development Team is pleased to announce the release of Asterisk 220.127.116.11. This release is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk/ The release of Asterisk 18.104.22.168 resolves several issues reported by the community and would have not been possible without your participation. Thank you! The following is a sample of the issues resolved in this release: * AST-2012-001: prevent crash when an SDP offer is received with an encrypted video stream when support for video is disabled and res_srtp is loaded. (closes issue ASTERISK-19202) Reported by: Catalin Sanda * Handle AST_CONTROL_UPDATE_RTP_PEER frames in local bridge loop. Failing to…
You mean say 0=Slave (Use PSTN clock)
1=Master(generate Internal clock) So best option is 0 for all span if you connected on PSTN right ?
Date: Fri, 27 May 2011 17:27:43 -0300
Subject: Re: [asterisk-users] DAHDI span timeing source Hi
The timing source is the clock of the system. When a equipment is 0, the other should be 1. The correct is: 0=slave, 1=master. The default for private systems is "slave".
On Fri, May 27, 2011 at 05:30:02PM +0000, firstname.lastname@example.org wrote:
> What is better more cores (eg. 2x quadcore) or more CPU speed for a server
> that handle a lot of of Meetme Concerences with hundreds of concurrent G711
> alaw Channels (no transcoding) ?
> in my opinion, more cores are better, because Asterisk ist multithreded and
> each channel has a good chance to distribute to the cores.
> is that right or what do you think? I don't have an answer for you…
On Tue, Mar 22, 2011 at 12:53 PM, satish patel
> Hey Guys!
> We have two Asterisk with A102D Sangoma cards now i want to connect them
> back-to-back over PRI line via Cross-cable so what would be the
> configuration specially timing source and all? anybody did it before like
> this ?
> I want to make sure everything before putting in production.. (saving my
> If is no different then setting up the card…