A New Timing API for Asterisk, Silencing Digium Critics

Russell Bryant has post details of a new timing API for Asterisk:

Starting with Asterisk 1.6.1, you will no longer need DAHDI installed at all to get proper timing in Asterisk. There is a new timing API, and there are already two implementations. There is a DAHDI timing interface (res_timing_dahdi) and another (res_timing_pthread) that has no special kernel requirements.

I hope this will shine some much needed light on the folks that are clamoring that Digium is keeping Asterisk proprietary by requiring a DAHDI timing source. One particularly annoying blog post states that the Asterisk fork(s) and other related VoIP/PBX software are gaining speed, because they are not tied to ‘proprietary timers needed for the Digium version of Asterisk.’

Need I inform you (usken.no) that:

  • The DAHDI interface has never been proprietary, the code is open and licensed under the GPL.
  • Timing is only utilized for MeetMe, the IAX2 Trunking feature and optionally during file playback.
  • app_conference is an alternative to MeetMe.
  • IAX2 Trunking feature is an optional feature that is not friendly to voice quality in high packet loss situations, so the loss of a timing device does not cripple or otherwise hinder Asterisk whatsoever.
  • File playback has a ’software timing’ method, if no DAHDI timing is available. This software timing method very well may also be available to IAX2 Trunking, but I am unsure if that functions or not.

I do not see any proprietary timers that are hindering Asterisk.

I see this post from usken.no as yet another attempt to slant the reasoning why people positioned themselves against Digium’s efforts.

Granted I have not agreed with every decision Digium has made (who does?) however I do see that Digium’s interest is very much with keeping Asterisk open source, along with developing a viable business model and an ever evolving ecosystem around its open source creation.

Buy.com Back to School Store

Related Posts:
Digium Launches New Headquarters
You Can’t Make This Stuff Up
Digium Innovation Awards
Digium Acquires SwitchVox
Digium Launches Embedded Platform

This entry was posted on Tuesday, June 17th, 2008 at 10:03 pm and is filed under Asterisk, DAHDI, Digium. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

4 Responses to “A New Timing API for Asterisk, Silencing Digium Critics”

  1. Voip Enthusiast on June 18th, 2008 at 11:25 am

    Asterisk is so behind of others now… I hope by 1.6 they will catch up with FreeSWITCH, and also fix their core problems, bugs… and get some new features that FS has.

  2. jj on June 18th, 2008 at 11:27 am

    VoIP Enthusiast: Please explain what you mean. Exactly where is Asterisk behind, what core problems, what bugs… Digium folks do read this blog, so don’t hold back - you can help fix Asterisk, if you put in at least some effort.

    These kinds of general comments really boil my blood.

  3. Voip Enthusiast on June 18th, 2008 at 11:58 am

    hey… don’t take me wrong, I love Asterisk and I want it to be the best… I report bugs from time to time on Mantis.

    I’m not a coder, but a sysadmin and I try to do what I can… I understand that they are doing what they can too… and I also know that they are doing a lot with 1.6, and I’m really excited about it, but in the past I been having some problems…

    For example, I tried to deploy an asterisk server on a XEN environment, and I needed conference, so I tried to use MeetMe, but when I tried to use zaptel/ztdummy… it didn’t work well with XEN, so I had to find another way to do conferencing, I found app_conference, but it lacked some features that MeetMe had… I got app_conference from the SF repository… I had no choice than to go with a dedicated (real machine) and use asterisk there.

    This finally fixed some of my problems… but in the long run I experienced more, DTMF problems, etc. Now the server is working great, but I still would like to see my bugs fixed and improvements overall.

    I think Asterisk is great, and no… I’m not going to use FreeSWITCH, I refuse to use XML for my configs, but still… they have some nice features that I would like to see in asterisk as well, that’s what I mean when I say that Asterisk is a bit behind of them.

    I prefer to see Asterisk improving it over time… because it’s what got me into the voip world.

    I think Asterisk folks are doing an amazing work with Asterisk and I would like to continue seeing Asterisk progressing.

  4. Leif Madsen on June 20th, 2008 at 5:33 pm

    Voip Enthusiast: Perhaps your issues are with the Xen environment? Last night I installed Asterisk 1.4 with Zaptel + ztdummy into a CentOS 5.1 x86_64 minimal image (plus dependencies for Asterisk/Zaptel) into a VMware Server virtual machine. I then configured a SIP peer, and the following minimal dialplan:

    exten => service,1,NoOp()
    exten => service,n,Answer()
    exten => service,n,Playback(tt-monkeys)
    exten => service,n,Hangup()

    exten => 555,1,NoOp()
    exten => 555,n,Answer()
    exten => 555,n,Milliwatt()

    I then load tested the machine with SIPp (http://sipp.sourceforge.net) while my Polycom was playing Milliwatt() (I dialed extension 555). Then I started generating calls with the default uac script and was getting around 60-70 simultaneous calls before audio was interupted on the Milliwatt() application.

    I find this test to be extremely simple to implement, and is a pretty good indicator of approximate simultaneous call ceiling.

    So in my opinion, your perceivied issues of short-comings in Asterisk on your Xen implementation seem to be more related to your selected distrubution model, and not of Asterisk itself.

    Leif.

Leave a Reply