Let’s talk about some of its new capabilities.

A major focus of the Asterisk 10 development cycle was Asterisk’s support for media types. In versions of Asterisk 1.8 and prior, Asterisk supported a rather limited number of codecs due to some architectural limitations. Plumbing was ripped out, kitchens were remodeled, girders were swapped, and Asterisk 10 now has a media architecture that’s capable of handling both a nearly unlimited number of codecs as well as codecs with more complex parameters. What does this mean for users? First, it means that Asterisk now comes with some additional codecs, including the 32kHz variant of the Speex codec (previous versions of Asterisk only supported the 8kHz or 16kHz variants), Skype’s Superwideband SILK codec, and pass-through support for the 44.1kHz and 48kHz variants of the CELT format.

Astute readers will note that earlier versions of Asterisk were only capable of operating on 8kHz and 16kHz sampled audio, and that the aforementioned newly-supported codecs operate at rates other than these. You’re absolutely correct. In order to support these new codecs, Asterisk 10 has also been provided with support for a variety of super and ultra-wideband sampling rates, all of which are supported as file format types for file playback or recording.

One of the best ways to show off the enhanced media capability is with an all new conferencing application. Asterisk 10 features a fully-functional software-driven conferencing application called ConfBridge. Astute readers will again note that ConfBridge was first made available in Asterisk 1.6. Again you’re correct. But, the ConfBridge of yore was sparsly featured and was only capable of operating at 8kHz (or 16kHz with a compile-time option). The ConfBridge of today (Asterisk 10), supports a full range of sampling rates (8, 12, 16, 24, 32, 44.1, 48, 96, and 192kHz) for its participants – it automatically selects the best sampling rate based on the participants’ native codec. Besides that, ConfBridge provides much greater control over in-call menus (customizable on a per-DTMF, per-caller basis), per-user profiles, as well as dynamic conference creation.

Speaking of showing off, what better way to “show” off capability than with some video? ConfBridge in Asterisk 10 provides basic video conferencing support. That’s right, if you and your friends have video-capable SIP devices, that all speak the same video codec and profile, you can create multi-party video conferences. The video played out to each participant follows a marked user; a user chosen by DTMF; or, the most useful, the user who’s currently talking.

In addition to the improvements to voice and video capabilities, Asterisk 10 can also improve your faxing experience. Asterisk 1.4 is capable of T.38 pass-through, where one T.38 capable endpoint can send a fax directly to another T.38 capable endpoint – usually a couple of SIP peers. Asterisk 1.6.X and 1.8 are capable of T.38 termination, where Asterisk can read/write TIFF files from/to T.38 endpoints. Now, with Asterisk 10, transparency between non-T.38 and T.38 is possible, with its T.38 Gateway (aka T.38 Relay) support. So, if you have a Digium E1 card terminated to the PSTN, you can now carry a fax directly from the PSTN to a T.38-enabled SIP device, without the intermediary “termination” step of TIFF conversion required in earlier versions of Asterisk. Or, if you’ve got a T.38 capable SIP provider, and a second provider that isn’t capable of T.38, you can mediate between the two; again, without any intermediary “termination” step. That means much faster and more reliable faxing in Asterisk 10.

What do we need from the community?

Testing, Testing, Testing.

Besides these great features, Asterisk 10 features a number of other important changes, many of which are under-the-hood. All of these under-the-hood changes mean that there are probably (definitely) some broken bits that Digium hasn’t found. So, to find them, we need your help. Please report any issues you find to the issue tracker.

Again, please report any issues (bugs, etc) that you find to the Issue Tracker.

It’s also useful to see successful test reports. Please post these to the asterisk-devmailing list. Or, if you IRC, then hop on over to the #asterisk-testing channel on theFreeNode network so we can work together in testing the many parts of Asterisk.

As always, we thank you for your participation.

Related posts:

1. Asterisk 10.0.0 Beta 1 Now Available
2. Asterisk 1.8, now in Beta
3. Asterisk 10.0.0-beta2 Now Available

astlinux

The AstLinux Team announces the 0.7.7 release. There are several updates and bug fixes related to Asterisk as well as the inclusion of PPTP as a VPN option. All current AstLinux users are encouraged to update to this release.

Related posts:

1. AstLinux 0.7.8 Release
2. AstLinux 0.7.6 Release
3. AstLinux 0.7.9 Released

Related posts:

1. Elastix: 1.2 Stable Released
2. Asterisk 1.8.0-Beta2 Now Available
3. Asterisk 1.6.1.13 Now Available

Developers are asked to stop merging bug fix changes into these branches as the only changes should be security related.

More information about the maintenance periods for branches, please see http://www.asterisk.org/asterisk-versions which contains a table outlining when branches will move between the various maintenance cycles. Currently Asterisk 1.4 and 1.6.2 branches are scheduled to move to security fix only modes in December of 2010, although that date is likely to be extended until Asterisk 1.8 is fully available.

Related posts:

1. Asterisk 1.6.0.28-Rc2 and Asterisk 1.6.1.20-Rc2 Now Available
2. Asterisk 1.4.32-Rc1, Asterisk 1.6.0.28-Rc1, Asterisk 1.6.1.20-Rc1 and Asterisk 1.6.2.7-Rc1 Now Available
3. Asterisk 1.4.42 Now Available (Final Maintenance Release)

In order to write these tests we need to be able to run the test suite on our development machine (typically a virtual machine or some other box which you won’t be using for production). We’ll be installing the test suite on an Ubuntu Server 9.10 along with the dependencies, then running the automated tests. Writing automated tests though is beyond the scope of this document. See the README.txt file in the testsuite/ directory for more information (http://svn.asterisk.org/svn/testsuite/asterisk/trunk/README.txt).

We’ll be starting with a fresh, minimal install of Ubuntu Server 9.10, so once you’ve gotten that installed, feel free to move on.

Installing Dependencies

Before we get started building the test suite, we need to install the dependencies it requires. The following applications are necessary to run all the currently developed tests, but additional dependencies surely will be required in the future. The current list of dependencies is available in the README.txt file within the testsuite/ repository (referenced earlier). Don’t worry about installing all these dependencies now, because we’re going to step through all the applications you need to install throughout the post.

• SIPp
• python >= 2.4
• python-yaml
• bash
• asttest
• StarPy
• python-twisted

Building Asterisk and the Test Suite

The Asterisk Test Suite must be installed and run as root, so if you’re not root, switch now (sudo su -) and we’ll get started!

First thing we want to do is create our directory structure and then checkout the version of Asterisk we want to test, and then grab the test suite. If you haven’t already installed Subversion, then do that now (apt-get install subversion).

# cd /usr/src/
# mkdir asterisk-complete
# cd asterisk-complete
# mkdir asterisk
# cd asterisk
# svn co http://svn.asterisk.org/svn/asterisk/branches/1.6.2 1.6.2-vanilla
# cd 1.6.2-vanilla
# svn co http://svn.asterisk.org/svn/testsuite/asterisk/trunk testsuite

Notice that we checked out the latest 1.6.2 branch and named it 1.6.2-vanilla. We then changed into the 1.6.2-vanilla directory and checked out the test suite. This is because the scripts being run from the test suite expect to be located in a subdirectory of Asterisk.

The test suite expects Asterisk to already be installed the first time it runs, so we should make sure we can compile Asterisk. We can find the bare dependencies we need with the ./configure script and install those one at a time as it fails to find the necessary components for compiling.

Note: Of course you don’t have to run ./configure multiple times — you could just install all the necessary dependencies by running: apt-get install gcc g++ libxml2-dev

# pwd
/usr/src/asterisk-complete/asterisk/1.6.2-vanilla
# ./configure
configure: error: no acceptable C compiler found in $PATH

So we have our first dependency to resolve. In this case we’re missing the GCC compiler, so lets install that now with: apt-get install gcc. Several package dependencies will be listed. Press Y to continue with the installation of GCC and its dependencies.

Now that we have our GCC compiler installed lets see what our next dependency is.

# ./configure
configure: error: C++ preprocessor "/lib/cpp" fails sanity check

We’re missing the GCC C++ preprocessor, which can be installed by running: apt-get install g++. You will see several dependencies listed and they can all be installed by pressing Y.

If we run ./configure again we appear to get much closer, but not quite all the way.

# ./configure
checking for xml2-config... no
configure: *** XML documentation will not be available because the 'libxml2' development package is missing.
configure: *** Please run the 'configure' script with the '--disable-xmldoc' parameter option
configure: *** or install the 'libxml2' development package.

Appears we’re missing the development libraries for the XML documentation. Lets install that now with: apt-get install libxml2-dev. A couple of dependencies will be installed along with libxml2-dev after pressing Y.

# ./configure
configure: error: *** termcap support not found (on modern systems, this typically means the ncurses development package is missing)

Lets install the missing ncurses-dev package and dependencies with: apt-get install ncurses-dev

# ./configure
configure: Package configured for:
configure: OS type  : linux-gnu
configure: Host CPU : i686
configure: build-cpu:vendor:os: i686 : pc : linux-gnu :
configure: host-cpu:vendor:os: i686 : pc : linux-gnu :

That’s it! If you see the big Asterisk symbol in ASCII text then you’ve made it to the end. Of course this is the bare minimum to get Asterisk compiled and installed, but we’ll use this for now. We’ll likely need to install some additional packages later to meet the dependencies of the test suite.

Lets try running the runtests.py script found in the testsuite/ subdirectory located in our Asterisk source. Remember that we checked this out earlier and is not part of the standard Asterisk checkout.

# cd testsuite/
# ./runtests.py
Traceback (most recent call last):
 File "./runtests.py", line 15, in <module>
 import yaml
ImportError: No module named yaml

OK, so we’re missing the python yaml package. We can install this with: apt-get install python-yaml

If we run the runtests.py script again we’ll get the following error:

# ./runtests.py
I/O Error getting Asterisk version from ../include/asterisk/version.h

This means we didn’t compile and install Asterisk prior to running our tests! So before continuing with our test suite install, we need to install Asterisk.

# cd ..
# pwd
/usr/src/asterisk-complete/asterisk/1.6.2-vanilla
# make install

Now that we have installed Asterisk, lets see where that gets us with our runtests.py script. We’re going to pass it the -l flag in order to list the tests we could potentially run, and the status of the dependencies they require.

# cd testsuite/
# ./runtests.py -l
Configured tests:
001) example
 --> Summary: Check to see if the Asterisk binary has been installed
 --> Minimum Version: 1.4 (True)
 --> Dependency: bash -- Met: True
002) ami-login
 --> Summary: Test loggin in to the Asterisk Manager Interface
 --> Minimum Version: 1.4 (True)
 --> Dependency: twisted -- Met: True
 --> Dependency: starpy -- Met: False
003) blind-transfer-accountcode
 --> Summary: Test account code propagation for SIP blind transfers.
 --> Minimum Version: 1.4 (True)
 --> Dependency: bash -- Met: True
 --> Dependency: sipp -- Met: False
 --> Dependency: asttest -- Met: False
004) rfc2833_dtmf_detect
 --> Summary: Test RFC2833 DTMF detection
 --> Minimum Version: 1.4 (True)
 --> Dependency: bash -- Met: True
 --> Dependency: sipp -- Met: False
 --> Dependency: asttest -- Met: False
005) sip_channel_params
 --> Summary: Test Retrieval of SIP CHANNEL parameters
 --> Minimum Version: 1.8 (False)
 --> Dependency: bash -- Met: True
 --> Dependency: sipp -- Met: False
 --> Dependency: asttest -- Met: False
006) iax-call-basic
 --> Summary: Test a basic IAX2 call
 --> Minimum Version: 1.4 (True)
 --> Dependency: twisted -- Met: True
 --> Dependency: starpy -- Met: False
007) manager-action-events-response
 --> Summary: Test the presence and absence of a response from the Events manager action
 --> Minimum Version: 1.4 (True)
 --> Dependency: bash -- Met: True
 --> Dependency: asttest -- Met: False
008) originate-cdr-disposition
 --> Summary: Test for proper CDR dispositions when originating calls.
 --> Minimum Version: 1.4 (True)
 --> Dependency: bash -- Met: True
 --> Dependency: sipp -- Met: False
 --> Dependency: asttest -- Met: False
009) func_srv
 --> Summary: Test func_srv for correctness
 --> Minimum Version: 1.8 (False)
 --> Dependency: asttest -- Met: False
010) sip_outbound_address
 --> Summary: Test explicit outbound host for SIP calls
 --> Minimum Version: 1.4 (True)
 --> Dependency: bash -- Met: True
 --> Dependency: sipp -- Met: False
 --> Dependency: asttest -- Met: False

There will likely be more by the time you try this out, but I think that’s a pretty good sampling. Looking through the tests we can see several dependencies being met with True and several others being met with False. Our goal now is to make sure we satisfy all the dependencies for the tests prior to running them. Starting at the top, the first dependency we haven’t satisfied is starpy.

From the StarPy website at http://www.vrplumber.com/programming/starpy/, “StarPy is a Python + Twisted protocol that provides access to the Asterisk PBX’s Manager Interface (AMI) and Fast Asterisk Gateway Interface (FastAGI). Together these allow you write both command-and-control interfaces (used, for example to generate new calls) and to customise user interactions from the dial-plan.  You can readily write applications that use the AMI and FastAGI protocol together with any of the already-available Twisted protocols“. Basically some tests are using it to generate calls in Asterisk to perform various tests.

We can install StarPy with the following commands:

# cd /usr/src/asterisk-complete/
# mkdir thirdparty
# cd thirdparty
# svn co https://starpy.svn.sourceforge.net/svnroot/starpy
# cd starpy/trunk/
# python setup.py install

You can see that we created a thirdparty/ directory within our asterisk-complete/ directory and checked out the latest version of StarPy. We then installed it via the setup.py script, and that’s it for satisfying the StarPy dependency.

After we change back to our testsuite/starpy dependency is satisfied:

# cd /usr/src/asterisk-complete/asterisk/1.6.2-vanilla/testsuite/
# ./runtests.py -l
...
--> Dependency: starpy -- Met: True
...

Let’s look and see what our next dependency is. Scrolling down a bit we can see the following:

--> Dependency: sipp -- Met: False

We need to install SIPp which is used for generating calls into the system. SIPp is a very useful utility for load testing Asterisk and executing detailed call flows. More information about SIPp is available at http://sipp.sourceforge.net/. We must install SIPp from source because some of the tests are already using advanced functionality for testing things like DTMF, so we can’t use the precompiled sip-tester package.

Note: Be sure to grab the latest SIPp snapshot. Right now that is version 2009-07-29.

# cd /usr/src/asterisk-complete/thirdparty
# mkdir sipp
# cd sipp
# wget http://sipp.sourceforge.net/snapshots/sipp.2009-07-29.tar.gz
# tar zxvf sipp.2009-07-29.tar.gz
# cd sipp.svn
# make pcapplay
send_packets.c:44:18: error: pcap.h: No such file or directory
make[1]: *** [send_packets.o] Error 1
make[1]: Leaving directory `/usr/src/asterisk-complete/thirdparty/sipp/sipp.svn'
make: *** [pcapplay] Error 2

Uh oh! We’re missing pcap support! Lets install that now.

# apt-get install libpcap-dev

Now we can compile SIPp with pcap support. There is no ‘make install‘ target to run, so we can just copy the resulting sipp binary to /usr/bin (or some other appropriate location that exists in your path).

# make pcapplay
# cp sipp /usr/bin
# cd /usr/src/asterisk-complete/asterisk/1.6.2-vanilla/testsuite/

After verifying that the SIPp dependency is available, we notice the next one in our list is asttest.

--> Dependency: asttest -- Met: False

The asttest dependency is an application distributed as part of the Asterisk test suite. It is dependent on Lua and the Lua development libraries. Switching in to the asttest/ directory and running ‘make‘ will provide the following error:

# cd asttest/
# pwd
/usr/src/asterisk-complete/asterisk/1.6.2-vanilla/testsuite/asttest
# make
make[1]: *** [src/lfs.o] Error 1
make[1]: Leaving directory `/usr/src/asterisk-complete/asterisk/1.6.2-vanilla/testsuite/asttest/lib/lua/luafilesystem-1.4.2'
make: *** [lib/lua/luafilesystem-1.4.2/src/lfs.o] Error 2

We can install the Lua development libraries and dependencies by running: apt-get install liblua5.1-0-dev lua5.1

# apt-get install liblua5.1-0-dev lua5.1

After installing Lua, we can run ‘make install‘ to install asttest.

At this point if you run ./runtests -l you will notice that all the dependencies have been satisfied (unless of course new tests have been added which require additional dependencies not yet required). So go ahead and run the tests and see if your checkout of Asterisk will pass all the tests!

# cd ..
# pwd
/usr/src/asterisk-complete/asterisk/1.6.2-vanilla/testsuite
# ./runtests.py

Once all the tests have completed, you’ll be provided a summary of the test that were run and their pass/fail status. The last part of the output will also be some XML output that you could use in scripts.

=== TEST RESULTS ===
--> example --- PASSED
--> ami-login --- PASSED
--> blind-transfer-accountcode --- PASSED
--> rfc2833_dtmf_detect --- PASSED
--> iax-call-basic --- PASSED
--> manager-action-events-response --- PASSED
--> originate-cdr-disposition --- PASSED

<?xml version="1.0" encoding="UTF-8"?>
<testsuite errors="0" time="158.71" tests="10" name="AsteriskTestSuite">
 <testcase time="0.01" name="example"/>
 <testcase time="25.51" name="ami-login"/>
 <testcase time="12.24" name="blind-transfer-accountcode"/>
 <testcase time="12.05" name="rfc2833_dtmf_detect"/>
 <testcase time="20.35" name="iax-call-basic"/>
 <testcase time="67.09" name="manager-action-events-response"/>
 <testcase time="21.48" name="originate-cdr-disposition"/>
</testsuite>

As you can see, all 10 of our tests passed and took 158 seconds to execute. Now that you have the test suite infrastructure setup and executing all the tests, you can start building your own tests. More information about buildings tests is available in the README.txt file within the top level of your testsuite/ directory. Go forth and create tests!

No related posts.

http://downloads.asterisk.org

http://downloads.digium.com

https://issues.asterisk.org

http://packages.asterisk.org

https://reviewboard.asterisk.org

http://svn.digium.com

http://svnview.digium.com

Enjoy!

Related posts:

1. Asterisk 1.8.0-Beta3 Now Available
2. Asterisk 1.8.8.0-rc1 Now Available
3. Asterisk open source project servers have new names!

Digium presentations:

Tristan Barnum – Wednesday, March 10th – 13:50PM – 14:20PM – Switchvox as an SMB Solution

Asterisk is being used all over the world as the open source core of an incredible (and growing!) number of communication applications. Learn how an open standards compliant solution with a foundation of open source software becomes a more powerful and flexible Unified Communications solution than traditional, proprietary systems could ever hope to be. The cost savings associated with open source and VoIP, in combination with easy to use applications allows for successful deployments affordable for small and medium businesses.

Steve Sokol – Thursday, March 11th – 12:30PM – 13:00PM – Cost Effective UC Solutions with Asterisk and Open Source

The Asterisk open source communications engine serves as the “glue” of the UC universe.  Even before the term “unified communications” was in vogue, integrators used Asterisk to build low cost, high value solutions.  Asterisk’s open interfaces make it easy voice-enable business processes.  Asterisk’s radical price point makes it affordable.  In this presentation Steve Sokol, Director of Asterisk Advocacy for Digium offers a primer on building custom UC solutions with Asterisk and other open source technologies.

For more information please visit www.ucexpo.co.uk/Seminars/Digium-Asterisk-World-London

Related posts:

1. Isn’t everyone looking for more ways to save money in their business these days?
2. Straight from the Source’s Mouth: Three Insiders Speak About Asterisk
3. Digium Releases TCE400B PCI-Express Transcoder Card

Now that Asterisk 1.6.2.0 (and 1.6.2.1) has recently been released, we thought it wise to create an announcement about some of the new items and changes available in the new feature release, along with where Asterisk is going in the next few months.

As with all new releases, if you plan on upgrading from any previous release be sure you test thoroughly in a test environment, and carefully read both the

CHANGES and the UPGRADE.txt files, which contain useful information about functionality changes between versions.

Some of the new features included in the Asterisk 1.6.2.0 release are:

SIP Changes

• if the channel variable ATTENDED_TRANSFER_COMPLETE_SOUND is set, the sound will be played to the target of an attended transfer
• Added support for subscribing to MWI on a remote server and making the status available as a mailbox. Please see the sip.conf.sample file for more information.
• Added support for ITU G.722.1 and G.722.1C (Siren7 and Siren14) media streams.

DAHDI Changes

• chan_dahdi now supports MFC/R2 signalling when Asterisk is compiled with support for LibOpenR2. http://www.libopenr2.org/
• As of version 1.6.1, Asterisk no longer depends on DAHDI as the sole timing source. In 1.6.2, an additional timing provider was introduced, res_timing_timerfd, which takes advantage of the timerfd API provided by newer versions of the Linux kernel. This timing provider provides much higher performance than the other non-DAHDI timing module, res_timing_pthread.

Dialplan Functions

• Added a new dialplan function, CURLOPT, which permits setting various options that may be useful with the CURL dialplan function, such as cookies, proxies, connection timeouts, passwords, etc.
• Added debugging CLI functions to func_odbc, ‘odbc read’ and ‘odbc write’.
• func_odbc now may specify an insert query to execute, when the write query affects 0 rows (usually indicating that no such row exists).
• func_odbc now supports database transactions across multiple queries.
• Added REALTIME_FIELD and REALTIME_HASH, which should aid users in better obtaining realtime data from the dialplan.

Dialplan Applications

• Scheduled meetme conferences may now have their end times extended by using MeetMeAdmin.
• A new application, Originate, has been introduced, that allows asynchronous call origination from the dialplan.
• Added ConfBridge dialplan application which does conference bridges without DAHDI.

Additional Features

• extensions.conf now allows you to use keyword “same” to define an extension without actually specifying an extension. It uses exactly the same pattern as previously used on the last “exten” line. For example:

       exten => 123,1,NoOp(something)
       same  =>     n,SomethingElse()

• All deprecated CLI commands are removed from the source code. They are now handled by the new clialiases module. See cli_aliases.conf.sample file.
• The contrib/scripts/ directory now has a script called sip_nat_settings that will give you the correct output for an Asterisk box behind nat. It will give you the externhost and localnet settings.
• The Asterisk core now supports ITU G.722.1 and G.722.1C media streams, and can connect calls in passthrough mode, as well as record and play back files.

Version Numbering Changes

Asterisk 1.6.2 will be the last release in the 1.6 series of feature releases.

The original purpose of the Asterisk 1.6 releases was to change how often a

release was created, in order to allow shorter time periods between versions so

the community wouldn’t have to wait 2-3 years for a new feature. The intention

was to release a new 1.6 version, which included feature additions and

performance increases, every 3-4 months.

Unfortunately, the time frame ended up being closer to every 6 months, so the

original intention wasn’t fully developed. In addition, the numbering scheme

was confusing to some users. (Additional information about the how and the why of

the 1.6 numbering scheme can be read at:

http://blogs.asterisk.org/2009/06/24/about-the-new-asterisk-versioning-method/

)

So after about a year and a half of releases (1.6.0.x, 1.6.1.x, and 1.6.2.x),

community feedback was considered, and all that was learned during the 1.6

release cycle was put together to create a better release scheme, which takes

the advantages of both the long stable release cycles, and shorter feature

release cycles of Asterisk, while adding a layer of predictability allowing the

community to plan deployments accordingly.

Whenever a release is created, it will now be tagged either as Standard or LTS

(Long Term Support). Asterisk 1.4 would be considered an LTS release, meaning it

receives bug fixes for a longer period of time, of at least 4 years. A standard

release would have a shorter bug fix release period of at least 1 year.

After the support period expires, that release would then receive security

updates for at least 1 year (Asterisk 1.2 is an example of this), and eventually

would become end-of-life (Asterisk 1.0), thereby no longer receiving updates.

All Asterisk 1.6.x releases are considered Standard releases.

The next LTS (Long Term Support) release will be Asterisk 1.8, slated to be

branched from trunk around Q2 of 2010, at which point time will be spent testing

and getting it ready for full release as Asterisk 1.8.0.

For more information about the current state of releases for versions of

Asterisk currently available see: http://www.asterisk.org/asterisk-versions.

Upcoming Features in Asterisk 1.8

Asterisk 1.8 is shaping up to be an exciting LTS release which will contain

several performance improvements and many new features. Some of the new features

to look forward to in Asterisk 1.8 include:

• The much awaited SRTP support in chan_sip will be added.
• The chan_mgcp module has added PacketCable NCS 1.0 support for Docsis/Eurodocsis Networks. See configs/res_pktccops.conf for more information.
• The chan_spy module has several new options added, including:
  • Added c() option allowing custom DTMF to be set to cycle through the next available channel. By default this is still ‘*’.
  • Added x() option allowing DTMF to be set to exit the application.
  • Added the ‘S’ option, which makes the application automatically exit once it hits a point where no more channels are available to spy on.
  • Added the ‘E’ option, which spies on a single channel and exits when that channel hangs up.
• The MeetMe application now turns on the DENOISE() function by default, for each participant. In our tests, this has significantly decreased background noise (especially noisy data centers).
• A new interface, Channel Event Logging (CEL), is introduced here. CEL logs single events, much like the AMI, but it differs from the AMI in that it logs to database backends much like CDR does.
• A new set of modules were added supporting calendar integration with Asterisk. Dialplan functions for reading from and writing to calendars are included, as well as the ability to execute dialplan logic upon calendar event notifications.
• A new RTP engine and channel driver have been added which supports Multicast RTP. The channel driver can be used with the Page application to perform multicast RTP paging.
• In app_queue, you can now specify a position at which the caller will enter the queue.
• Information regarding the party that a person is currently connected to may be updated dynamically throughout the call. This has the advantage of allowing for the display of a phone to be updated during situations such as a call forward or a transfer.
• A new feature, call completion, will be added. This feature allows for a caller who reaches an unresponsive or busy party to be automatically contacted when the called party becomes available again.

Related posts:

1. Asterisk 10.0.0 Beta 1 Now Available
2. Asterisk 10.0.0-beta2 Now Available
3. More Fax, More Features

In Asterisk 1.4 and prior releases, there was limited support for FAX of any kind; Asterisk 1.4 can pass through T.38 sessions on SIP channels, but that’s all. With an open source addon (based on Steve Underwood’s excellent spandsp library), it can have dialplan applications to send and receive FAX over audio (G.711 TDM) links.
During the development of Asterisk 1.6.0, Steve’s FAX dialplan applications were merged into asterisk-addons, and then directly into the Asterisk source tree, where they became the ‘app_fax’ module. In addition, the T.38 negotiation process was redesigned to allow Asterisk applications to actually be T.38 endpoints; this resulted in the ability to send and receive FAX over audio *and* T.38 links.

Once this got into the community’s hands, we started seeing large numbers of bug reports because users could not successfully FAX over T.38 with various ATAs and service providers.  I won’t go into the gory details of why this was the case, except to repeat a recent quote from Steve himself on IRC: “The T.38 spec was written after a night of heavy drinking as a joke.”. While that’s not technically true, it is true that compliance with the T.38 recommendation, primarily in the SIP/SDP negotiations area, is very poor across the industry. Producing a T.38 endpoint that interoperates widely is a complex and difficult process, that can only be achieved through hours and hours (and hours) of testing.

As these problem reports got more severe, we took a significant step: we rewrote the T.38 negotiation mechanisms in Asterisk *again*. These changes first appeared in the 1.6.0.14 and 1.6.1.5 releases. The in-tree app_fax application was updated to support these changes along with them, so open source FAX users got the benefits of these changes immediately… and the result has been wonderful. We get very few T.38 negotiation-related bug reports now, and in nearly every case we can point to a misconfiguration or severely broken far endpoint that is the cause of the problem. For many, many people, FAX over T.38 in Asterisk 1.6.0 and 1.6.1 ‘just works’ now.

While all of this was going on, Digium was also working on our commercial Fax for Asterisk product, which provides comparable functionality to app_fax, but uses a commercial FAX stack. When we began the development of this product, we knew that we wanted as many portions of it as possible to end up open source, so rather than build it as a monolithic module, we built two modules: res_fax and res_fax_digium. res_fax is similar to app_fax, in that it provides dialplan applications, dialplan functions, and other associated components to send and receive FAX. However, it does not actually include any FAX stack; for that, it provides a plugin interface that allows one (or more) additional modules to be loaded to actually provide the FAX technology implementation. It *does* handle all T.38 negotiations, however, using the 3rd generation T.38 implementation in Asterisk.

Of course, res_fax_digium is Digium’s commercial plugin module for res_fax, and we have been delivering the combination of those two modules to our Fax For Asterisk customers for quite a few months now. (Unfortunately it has taken longer to get these modules updated to match Asterisk’s T.38 API than we would have liked, but that’s not important for open source users). Recently, with a final set of changes to the UDPTL stack in Asterisk, we’ve reached the point where we think we’ve implemented all the parts of the T.38 recommendation that we can implement, in as compatible and interoperable a way as we can, with a few configuration options that provide the ability to override broken behavior by far endpoints when necessary. In fact, the combination of the very most recent Asterisk open source releases and either app_fax or res_fax+res_fax_digium now successfully interoperates with quite a few T.38 ATAs we have in our lab and a couple of service providers, and we’re testing more of both as I write this. In nearly every case, this works *without* requiring any configuration changes in Asterisk or the FAX applications, which is good news for end users indeed. We’ve even extended (and fixed) the ‘faxdetect’ functionality in chan_sip so that it works as users expect it to, in a similar way to the faxdetect feature in chan_dahdi.

Now that this point has been reached, it’s time for us to act on our plan to open source res_fax; to that end, I’ve created a new branch in Subversion (/svn/asterisk/team/group/res_fax) based on Asterisk trunk, and merged the most recent version of res_fax into it, updating it to compile against trunk’s recent API changes. By the time Asterisk 1.8 is released, res_fax will *replace* app_fax, as it provides the identical dialplan applications (same names, options and operations), but has additional features and compatibility functionality. To achieve this, though, we’re going to need a res_fax_spandsp plugin module, so that the combination of res_fax + res_fax_spandsp provides the same functionality as app_fax did, and it will be a seamless transition for Asterisk 1.6.x FAX users to move to Asterisk 1.8 when they are ready. We’ve tasked one of our developers to start working on this over the next few weeks, and I’m sure you’ll see some initial steps toward that end shortly. For those of you who have contributed improvements to app_fax and use it heavily (or even those who just use it and can provide testing), I’d encourage you to post a comment in the thread on the asterisk-dev mailing list if you are interested and willing to assist in this effort.

Now, on to even more interesting stuff: as I’ve worked on this over the past 6-8 months, I’ve also spent time finally trying to understand how best to fit TDM-T.38 FAX relay into Asterisk. I know that there are number of community developers who have been working on this, and there are multiple patches in the issue tracker that provide this functionality in various forms. There was also an attempt by Daniel Ferenci to start a discussion on the asterisk-dev list about the best long-term approach for relay support, but he didn’t really get any responses.

Once res_fax and res_fax_spandsp are ready for users to use, it’ll be time for them to be extended to support FAX relay as well. I would like to propose that this be implemented by res_fax providing a new API, a ‘FAX relay session’, that a channel driver (one which services TDM channels) can use to offer T.38 support to the rest of Asterisk, as if it supported T.38 natively. We can start a separate discussion on the list to talk about particulars, but I believe this is the cleanest approach with the least impact on existing code in Asterisk, and I’d like to get opinions from other interested parties and discussion going.

In summary, it appears that Asterisk 1.6.x has achieved pretty solid FAX support (especially over T.38), and that with Asterisk 1.8 we’ll be able to improve it further and begin moving towards FAX relay support as well. For all of you who still insist on using this obsolete technology <G>, I hope this has provided what you need to be able to keep using Asterisk
in every place that it makes sense in your networks!

Related posts:

1. Fax For Asterisk
2. Fax For Asterisk 1.1.6 Release Announcement
3. More Fax, More Features

As a challenge to the community, I’m offering a $25 gift certificate from ThinkGeek to the first 10 working software projects (i.e. projects with useful, downloadable, runnable, Asterisk-related software) to move in and set up shop in the Forge.  (Sorry – no hardware projects, artwork or poetry  qualify for this promotion.)

The winners will be picked by the official Digium Prize Selection Committee (me and whomever I can round up in the Digium cafeteria) and all decisions are final.  If we have to debate the usefulness of an app, it’s probably not useful, so no stuffing the ballot box with Perl AGI scripts that read back the current time.  May the forge be with you…

Forge Q&A

I’ve received a few questions about the Forge since the announcement and would like to share the answers with everyone.  Please let me know if you have any additional questions.

Q) What is the AsteriskForge?
A) AsteriskForge is a web site that provides free development and hosting tools for Asterisk-related open source projects.

Q) Where is AsteriskForge?
A) http://forge.asterisk.org

Q) What tools does AsteriskForge include?
A) AsteriskForge is built on a platform called GForge Advanced Server.  It includes source code control (SVN), file download hosting and tracking (just counts, nothing invasive), mailing lists, forums, documentation, development team management, project management and road-mapping.

Q) Who can use AsteriskForge?
A) Any open source project with a focus on extending or integrating with Asterisk.  The project must be released under an OSI-approved license.

Q) What are examples of the kinds of things that will be hosted on AsteriskForge?
A) Dialplan and AEL snippets (we have a special section for snippets).  AGI scripts and programs in various languages.  Desktop tools including screen pop utilities, operator consoles, CRM integration components, and monitoring utilities.  Server-side integration tools including unified messaging and collaboration components, scalability and redundancy solutions, web services mash-ups, etc.  Administration GUI tools and projects.  Prompt packages.  Industry-specific (vertical) applications.  Power and predictive dialer systems.  Pretty much anything that connects with Asterisk.

Q) Can I mirror my existing Asterisk-related open source project on AsteriskForge?
A) Yes.  We are happy to host mirrors of existing Asterisk-related projects.  We do require that source downloads be included for each mirrored project, not just binary installers.

Q) Is AsteriskForge open to non-software projects?
A) Yes, though the tools tend to be fairly software oriented.  We are open to hosting documentation, voice prompts, hardware CAD/CAM files, even Asterisk-related poetry if it tickles your fancy.

Q) Does Digium get to use AsteriskForge code in commercial products outside of the terms of the selected open source license?
A) No.  The copyright and commercial rights to the code remain with the author(s).  Use of AsteriskForge is not predicated on accepting the Digium Open Source Software Project Submission Agreement.

Q) What other rules and regulations should I know about?
A) You can’t post stuff you don’t own.  We’ll honor take-down notices if they are deemed to be legitimate by our legal staff.  No development of proprietary commercial products – you must release your code as open source.  We won’t host .ISO install images or other huge binaries.  The full list of terms and conditions are available here: http://www.asterisk.org/forge/terms

Q) Is the core of Asterisk moving into AsteriskForge?
A) No.  There’s already a full set of development tools and processes in place for Asterisk, and moving to the AsteriskForge site would be disruptive to the process.  We will continue to use the existing issue tracker, mailing lists, review board, forums and subversion repositories for Asterisk.

Related posts:

1. Asterisk open source project servers have new names!
2. Google Summer of Code 2009 Projects
3. yay! google summer of code

Recently I have been seeing more and more questions about how Asterisk is being released now, and what the 1.6.x versions really mean. I’ll try and clear up some of your questions and make it more clear as to how Asterisk versions work. First, lets talk about the Asterisk 1.2 and 1.4 branches.

Previous release methodology

When we just had Asterisk 1.2 and 1.4, all new development was carried out in trunk (it still is) and only bug fixes went into the 1.2 and 1.4 branches. Currently, the 1.2 branch has been marked as EOL (End of Life), and is currently only receiving security updates. Bug fixes are reserved for the 1.4 branch. This means that until 1.6 came along, all new development was done in trunk, without the ability for people to get access to new features and functionality until the 1.6 branch was created. It’s not to say the new functionality wasn’t available, but with all the changes that can happen in trunk, running a production server based on it would require a very Asterisk savvy (and C code savvy) administrator.

Before we talk about 1.6, lets make sure we understand what trunk, branches, and tags mean.

Branches, and Tags, and Trunk; oh my!

Asterisk development is basically a linear process. All changes happen one after the other, and new features are always put on the end. This is referred to as trunk. All the latest changes to core Asterisk code, new features, and major changes take place here. This is why running trunk in production is not recommended, because the developers essentially have free reign as to what goes in here.

Note: with the advent of review board, the larger commits that go into trunk are of much higher quality, as large changes are not put into trunk without any sort of peer review. The review board application allows these larger changes (such as new features, major core restructuring changes, etc.) to be reviewed by other developers to find common coding issues that would otherwise have had to be found in the wild.

Like a tree, the branches grow from the trunk. These branches are referred to as 1.2, 1.4, etc. A branch is a snapshot of the trunk at the time of creation, and from there, has its own timeline. When a bug is found, fixed, and resolved, the resulting commit is then placed into trunk, and any branches that it effects. When a new feature is created, it is only put into trunk, thereby leaving the branches in a relatively known state that is safe for production use.

From a branch, we create snapshots in time called tags. These tags are the version numbers and tar ball files you can download from the Asterisk.org website. These tags are numbered releases that never change, such as 1.4.18, 1.4.22, etc. In image 1.1, you can see a visual representation of the Asterisk branching and tagging process where the x-axis represents time.

Image 1.1 – Visual representation of Asterisk release branching and tagging.

Understanding the Asterisk 1.6 release process

With the advent of Asterisk 1.6, the release process has differed slightly, in that there are multiple 1.6 branches supported at any given time. The reason for this is because the time frame between the creation of the 1.0 & 1.2 branches, and the 1.2 & 1.4 branches was so great (approximately 1 year in the former, and 2 years in the latter!) that new features would sit in trunk, and many changes would take place over that period of time. Due to the rapid development of Asterisk, these changes were grandiose and thus the user experience between these releases were such that major changes had taken place. Backwards compatibility was difficult to maintain, and simply, who wants to wait 3 years to get the next great feature?

So with Asterisk 1.6, a new release process that allows branches to be created in a more regular fashion (approximately 6-8 months) was developed. Whenever a branch is created, we now update the 3rd most significant digit, which represents a new branch with new features, and the 4th most significant digit is now the tag number in that release. So for example, we have the branch Asterisk 1.6.0, which is a branch created from trunk at a period in time, and within that branch, bug fixes are performed, but no new features are added. The tags from this branch will be version numbers such as 1.6.0.0, 1.6.0.1, 1.6.0.2, etc. Then some period in time, a new branch will be created from trunk such as 1.6.1 (note that the 3rd significant number has increased by one). Within this branch will be new features and changes — that different of the 1.6.0 branch. Within the 1.6.1 branch, we’ll have tags just like all our other branches, such as: 1.6.1.0, 1.6.1.1, 1.6.1.2, etc.

This process continues throughout the lifetime of the 1.6 series of Asterisk. The trunk continues to have development, new features merged and potential core changes to make Asterisk more efficient (which would otherwise be deemed too invasive for a release branch) are committed. The regular release nature of this process allows less drastic changes between major versions (and note that the difference between a 1.6.0 and a 1.6.1 *is* considered a major version upgrade, similar in nature to an upgrade between 1.2 and 1.4, but not quite so drastic), and access to new features on a more regular basis. Because these are considered a major change between versions, it is in your interest to read the UPGRADE-1.6.txt files in your Asterisk source, and to test thoroughly before deploying in a production environment.

It should be noted that at any given time, there will be at least 3 branches of the 1.6 nature maintained. That means bug fixes and maintenance will be performed on your preferred branch for an extended period of time. For example, because there can be code refactoring, and core changes between 1.6.x versions (where x is the major version number), you may wish to maintain your production system on the 1.6.0 branch while your development system is running the 1.6.1 series. This way you don’t have to worry about moving your 1.6.0 system immediately to a 1.6.1 based branch as soon as it is created. Image 1.2 shows a visual representation of the 1.6 release process, which should look similar to the release process between 1.2 and 1.4. The x-axis still represents time, but in this case, time is not over quite so long a period.

Image 1.2 – Visual representation of the Asterisk 1.6 release process

So which version do I use?

It always comes down to the question of, “so which version do I use?” and this can be a tricky one to answer. It probably boils down to what features you need to utilize. By checking the CHANGES file in your Asterisk source tree, you can see what changes have happened between each of the various branches (i.e. the differences between 1.6.0 and 1.6.1). While writing this article, I was asked by someone on IRC the question, “What version do you recommend?”, and the answer I gave was, “I recommend the version that has the features you require, and that passes the testing you have done prior to rolling it out”. He followed up with, “But they all have the feature I require!”, to which I responded, “Do some forward planning, and try to determine that the version you pick has the features you may possibly require in the future so that you don’t have to re-architect your system sooner than you want”. This can save you a lot of time and effort. Do some testing, and play with all the various branches on a development server. See what dialplan applications and functions exist, and how they work. Try to determine what kinds of things you need your phone system to do, and make sure the version you pick can do it. You can also make use of the various mailing lists and IRC chat rooms (asterisk-users mailing list, and #asterisk IRC channel) to ask specific questions if you’re not able to find an answer.

Hopefully this has made the release process a bit more clear!

Related posts:

1. Asterisk 1.6.0 and 1.6.1 Branches Switching to Security Maintenance
2. Asterisk 1.8.0 Now Available!
3. Asterisk 1.8.0-Beta1 Now Available

Congratulations to all accepted students!

Related posts:

1. yay! google summer of code
2. Asterisk Security Advisory – AST-2009-004
3. Asterisk Project Update @ AstriCon 2009

yay!!!
I’ve been accepted for the the google summer of code.
For those who don’t know what is:
- we work on open-source project, been supervised by a mentor
What’s really interesting, that project is called……humm….. Asterisk!
For my project, my mentor will be Mark Michelson aka master of queues!
I’ll work on the implementation for the CLI filtering.
Never heard about it?
let me recap:
I had an idea few months ago:

That idea was never been implemented due to a lack of time.
But since a paycheck will come from Google this summer, it offers me the possibility to focus on that new feature.
That new feature will allow you to see in real-time whats going on in your CLI with some filters (cause when you have 50 channels, it’s impossible to see).
So you will can see only what’s going on, on a specific channel instead of scrolling up like a troll.
You have any idea to better use the CLI and asterisk, particulary to use filters to better use the CLI, feel free to contact me via email or via the asterisk-dev mailing list.
And finally I’d like to say congrats to the 3 other students who have been accepted too:

(and even to those who havent been accepted, don’t give up, maybe next year!)

Related posts:

1. Google Summer of Code 2009 Projects
2. Asterisk Security Advisory – AST-2011-002: Multiple array overflow and crash vulnerabilities in UDPTL code