russellbryant.net

Matthew Fredrickson, an engineer at Digium and the developer of LibSS7 and the related support in Asterisk, has posted an update on SS7 support in Asterisk to the Asterisk-SS7 mailing list.  It’s a pretty exciting update.  LibSS7 has released a 1.0 release milestone, and there are users that are alraedy using it in very high volume installations.  From the update:

There are some very good and very interesting things that have been happening. If any of you know Joseph on this list, he works for a mobile phone company in Kentucky. He is using Asterisk with libss7 to provide voicemail services to his mobile subscribers.

He has quite a good setup for helping me find issues, and is also a good indicator for how well libss7 is doing stability and scalability wise. Well the news is that running a current version of libss7/Asterisk-1.6.0 branch he has been running a load over 100,000 calls per day for close to a month, with no link related stability problems and no Asterisk issues.

Congratulations to Matt for reaching the 1.0 release milestone of LibSS7, and Thank You to everyone who has helped him out with testing!

Astricon 2008 is coming up in a couple of months. I have been to every Astricon in the United States and I always have an amazing time. I spend so much time deep in the trenches of the code that it is really nice to get out and meet people that make good use of Asterisk.

I am currently scheduled to give 2 talks this year. One of them is a “lightning talk”, where I will spend 10 to 15 minutes giving a talk titled “Deadlocks explained for the masses”. I plan to explain some multi-threaded programming concepts and the causes of deadlocks in a way that all attendees can understand.

My second talk is a joint talk with Kevin Fleming, called “The Asterisk Update - The Present, The Future”. Kevin and I will be discussing the current state of Asterisk development, as well as some of our plans for the future direction of the project.

I strongly encourage you to consider attending Astricon, and if you do, come say hello!

The Asterisk.org development team has released Asterisk versions 1.4.21.2 and 1.2.30.

Both of these releases include fixes for two security issues. Both of these issues affect users of the IAX2 channel driver. For more details on these vulnerabilities, see the published security advisories, AST-2008-010 and AST-2008-011.

Thank you for your continued support of Asterisk!

On September 26-28 in Glendale, Arizona, a group of Asterisk developers will be getting together for three days of hacking, coding, testing, designing and otherwise beating on the Asterisk code base. The event will be hosted at the Renaissance Glendale Hotel and Spa immediately following AstriCon 2008 and will be low-key and open only to serious developers and contributors. We are expecting to keep the attendance to 50 people or less, including many members of the Digium Asterisk development team (currently around 15 people).

If you wish to participate, please contact Kevin P. Fleming so he can make arrangements with you. We will need to have the final list of attendees in place by August 15th or so, so that hotel accommodations can be confirmed. You can find accommodation and travel information on the AstriCon website at http://www.astricon.net.

Each attendee will be responsible for their own travel, meals and lodging costs; the conference sessions will only have a beverage bar and light snacks. There will be free wireless Internet access in the meeting room and in the guest rooms at the Renaissance.

This year we plan to focus our efforts on media stream handling and codec (format) negotiations; at the previous two DevCons we have talked about these topics but not made any significant progress, and it’s time to get the work done to improve Asterisk so it can do a better job handling complex media streams and changing codec requirements.

If you are interested in attending, send an email application to kpfleming@digium.com including your name, your involvement with Asterisk (or related projects), and who is sponsoring your attendance (if any company or person is doing so). We will accept applications until August 15th, and then make the decisions about who we can accept based on their level of contribution and the space available at the event.

I just came across a whitepaper on analog interface cards via the Digium twitter feed. This paper compares performance of analog cards from Digium, Sangoma, and Rhino.

Check out the promotion where you can get $100 off your purchase.

Here is the whitepaper.

Working at Digium is so random sometimes. This morning, an entire pallet of Dr. Pepper arrived for Kevin P. Fleming, my boss, and the Director of Software Technologies. This pallet held 42 cases of 24 20 oz. bottles each. That’s 1008 20 oz. bottles of Dr. Pepper. Furthermore, this arrived with no information on who sent it!

Someone must be very happy with Kevin right now. He made a comment that someone must have really liked his work on modular echo cancelers and other fixes and improvements preparing for the first release of DAHDI.

Dr. Pepper on the receiving dock, after we had already taken the first 5 cases off of it:

Moving it upstairs to be in the software engineering area …

The full stack in its final resting place, for now. This stack is two cases deep. Also, there is a row of 6 more cases that can’t be seen in this picture.

I sure hope Kevin is willing to share a couple of bottles with the rest of the team!

A little over a year I ago, I made a post to the Asterisk-dev mailing list looking for someone to do some load testing with the Hoard Memory Allocator.

Chris Tooley just recently gave it a test run and saw a boost of about 10% in the number of call setups per second that his machine could handle.

I would encourage others to give this a try when load testing your system. There is virtually no setup other than installing hoard. There are some Asterisk functionality that I feel would see much greater performance improvements than have been demonstrated so far.

The Asterisk.org development team has released Asterisk version 1.4.21.1.

This includes a critical bug fix for 1.4.21. All users that experienced lockups when upgrading to 1.4.21 should have their issues resolved with this update.

Asterisk 1.4.21.1 is available for download from the downloads site:

• http://downloads.digium.com/pub/telephony/asterisk

Thank you for your continued support of Asterisk!

Greetings fellow developers!

This is part 3 of a series on implementing the basic interfaces to provide features to Asterisk.

Part 1 - Basic Module Structure
Part 2 - CDR Handling Interface

In this section, you will see how to implement an Asterisk CLI command. CLI commands are extremely useful for showing configuration, statistics, and other debugging purposes.

We are going to continue editing the module from part 2, res_helloworld2.c.

The first step is to include the header file which defines the CLI command interface.

#include "asterisk/cli.h"


Here is the code for a CLI command, “echo”. It simply prints back the first argument to the CLI command. The individual parts of this function will be described later.

static char *handle_cli_echo(struct ast_cli_entry *e, int cmd, struct ast_cli_args *a)
{
    switch (cmd) {
    case CLI_INIT:
        e->command = "echo";
        e->usage =
            "Usage: echo <stuff>\n"
            "       Print back the first argument.\n"
            "Examples:\n"
            "       echo foo\n"
            "       echo \"multiple words\"\n"
            "";
        return NULL;
    case CLI_GENERATE:
        return NULL;
    }

    if (a->argc == e->args) {
        ast_cli(a->fd, "You did not provide an argument to echo\n\n");
        return CLI_SHOWUSAGE;
    }

    ast_cli(a->fd, "%s\n", a->argv[1]);

    return CLI_SUCCESS;
}

The first line of this CLI handler matches the defined function prototype for CLI command handlers. The ast_cli_entry argument includes static information about the CLI command being executed. The cmd argument is set when the CLI command is being invoked for a reason other than normal execution from the CLI, which will be explained more later. The ast_cli_args argument contains information specific to this one time execution of the command, like the arguments to the command.

static char *handle_cli_echo(struct ast_cli_entry *e, int cmd, struct ast_cli_args *a)


The switch statement at the beginning of the function handles when the cmd argument is set to indicate that the function is being called for a reason other than normal execution. There are two cases handled.

• CLI_INIT. Every CLI command handler is called one time with a cmd of CLI_INIT. This asks the function to fill in the documentation on what the command is, as well as usage documentation.
• CLI_GENERATE. This cmd is used for implementing tab completion. CLI commands that provide tab completion of arguments must add code here. Implementing tab completion may be explained in a later tutorial. For now, there are many examples throughout the code.

The next code snippet ensures that at least one argument has been provided to the function. It is worth noting here that the ast_cli_entry argument is used to retrieve how many arguments define the command itself and the ast_cli_args argument is used to retrieve how many arguments were actually specified at the CLI when executing this command. If they are equal, then simply “echo” was provided.

if (a->argc == e->args) {
ast_cli(a->fd, "You did not provide an argument to echo\n\n");
return CLI_SHOWUSAGE;
}


Finally, we print a single argument to the CLI, and return that the execution of the CLI command was successful.

ast_cli(a->fd, "%s\n", a->argv[1]);
return CLI_SUCCESS;


The next thing that we have to add is the table of CLI commands included in this module. We will use AST_CLI_DEFINE() to add a single entry to this table. AST_CLI_DEFINE includes the pointer to the CLI command handling function, as well as a brief summary of what the command does.

static struct ast_cli_entry cli_helloworld[] = {
AST_CLI_DEFINE(handle_cli_echo, “Echo to the CLI”),
};


Finally, as discussed in part 2, we have to modify load_module and unload_module to register and unregister the CLI command table with the Asterisk core.

In unload_module, we add this:

ast_cli_unregister_multiple(cli_helloworld, ARRAY_LEN(cli_helloworld));


In load_module, we add this:

ast_cli_register_multiple(cli_helloworld, ARRAY_LEN(cli_helloworld));


That’s it! Recompile and reinstall the module. Take a look at res_helloworld3.c, for the completed code.

You can then try it out.

*CLI> help echo
Usage: echo 
       Print back the first argument.
Examples:
       echo foo
       echo "multiple words"

*CLI> echo
You did not provide an argument to echo

Usage: echo 
       Print back the first argument.
Examples:
       echo foo
       echo "multiple words"

*CLI> echo foo
foo

*CLI> echo hello world
hello

*CLI> echo "hello world"
hello world

In part 1, I explained the “Hello World” of Asterisk modules. It implemented just enough to properly compile, get loaded into Asterisk, and print something to the Asterisk log when the module was loaded and unloaded. Now, it’s time to start making modules that do something useful.

In res_helloworld.c, we implemented a load_module and unload_module function. In that module, they just printed to the log. They actually have a much more important purpose in life.

The job of load_module() is to say, “Hello Asterisk, I’m a module. I can provide some features to Asterisk and here is how you use them.”

Conversely, the job of unload module is to say, “Hello Asterisk, again. I’m about to disappear, so please don’t use any of these features that I was providing to you anymore. If you do, you’ll explode. kthx!”

So, it’s time to update this module to provide a feature to Asterisk. We’ll start with a CDR (Call Detail Record) handler. It is one of, if not the simplest interface to implement. To keep things simple, we’re going to implement an Asterisk CDR handler that once again, just uses the Asterisk logging interface.

The first thing to do is to add the appropriate header file so that module has the appropriate definitions for the CDR interface.


#include "asterisk/cdr.h"


Next, we’re going to add a new function. This function will get called every time that there is a new CDR to post. It takes a single argument, which is the CDR itself.

static int cdr_helloworld(struct ast_cdr *cdr)
{
    ast_log(LOG_NOTICE, "We got a CDR for channel '%s'.  "
        "Source: '%s', Dest: '%s', Duration: %ld\n",
        cdr->channel, cdr->src, cdr->dst, cdr->duration);

    return 0;
}

Next, as I described before, we have to make the load_module() and unload_module() functions aware of this new feature that is implemented by the module.

In load_module(), we will add a function call to “register” the CDR handler with the Asterisk core. The arguments are the name of the handler, a short description, and the function that the Asterisk core needs to call when a CDR is ready for posting.


ast_cdr_register("HelloWorld", "Hello World CDR Handler", cdr_helloworld);


In unload_module(), we will add a function call to “unregister” the CDR handler form the Asterisk core.


ast_cdr_unregister("HelloWorld");


That’s it! See the finished code here, res_helloworld2.c.

Compile it and install it. When you start Asterisk, you should be able to verify that your new CDR handler has been registered with the Asterisk core.


*CLI> cdr show status
...
CDR registered backend: HelloWorld
...


When you hang up a call, you should see the result of your CDR handler being executed.


[Jun 20 18:08:29] NOTICE[4922]: res_helloworld.c:36 cdr_helloworld: We got a CDR for channel ‘SIP/5001-007e9da8′. Source: ‘5001′, Dest: ‘586′, Duration: 1


And now, you have implemented an Asterisk module that adds custom handling of CDR records!