· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
Asterisk Ver0-1-0

Asterisk Version 0.1.0


* APPS=app_dial.so app_playback.so app_voicemail.so app_directory.so app_intercom.so app_mp3.so

* CHANNEL_LIBS=chan_vofr.so chan_ixj.so

* CODECS+=$(MODG723) codec_gsm.so
  • codec_g723_1.so codec_g723_1b.so

* FORMAT_LIBS=format_g723.so format_wav.so format_mp3.so

* PBX_LIBS=pbx_config.so

c 언어 관련

* logger.c
  • extern void ast_log(int level, char *file, int line, char *function, char *fmt, ...)
    • ast_log(LOG_ERROR, "Unable to create event log: %s\n", strerror(errno));

* include/asterisk/logger.h
  • #define LOG_ERROR 4, _A_

* gcc predefined macros
  • Standard predefined macros
    • --FILE__
    • LINE

GCC predefines two magic identifiers to hold the name of the current function. The identifier __FUNCTION__ holds the name of the function as it appears in the source. The identifier __PRETTY_FUNCTION__ holds the name of the function pretty printed in a language specific fashion. 

* 가변인수

#include <stdio.h>
#include <stdarg.h>
void foo(char *fmt, ...) {
    va_list ap;
    int d;
    char c, *s;
    va_start(ap, fmt);
    while (*fmt)
        switch(*fmt++) {
        case 's':            /* string */
            s = va_arg(ap, char *);
            printf("string %s\n", s);
        case 'd':            /* int */
            d = va_arg(ap, int);
            printf("int %d\n", d);
        case 'c':            /* char */
            /* need a cast here since va_arg only
               takes fully promoted types */
            c = (char) va_arg(ap, int);
            printf("char %c\n", c);


A thread is a sequence of instructions to be executed within
      a program. Normal UNIX processes consist of a single thread
      of execution that starts in main(). In other words, each line
      of your code is executed in turn, exactly one line at a time.
      Before threads, the normal way to achieve multiple
      instruction sequences (ie, doing several things at once, in
      parallel) was to use the fork() and exec() system calls to
      create several processes -- each being a single thread of
In a threaded environment, this model of parallelism is
      turned on its head. Instead of there being several singly
      threaded processes, we have one process consisting of
      multiple threads. In other words, each user process can have
      several threads of execution -- different parts of your code
      can be executing simultaneously. The collection of threads
      form a single process: each thread in the process sees the
      same virtual address space, files, etc.
This last fact has interesting implications. For example,
      when one thread opens a file, it is immediately possible for
      all other threads to access the file. Similarly, if one
      thread alters the value of a global variable, all other
      threads instantly see the new value. In a multithreaded
      process, the cost of communication is negligible. The
      downside of this feature is that a threaded process cannot
      exist across machines (because the underlying resources are
      bound to the local host).
When writing multithreaded applications, you must take the
      initiative to protect shared resources. 
 Pthreads provides an object called a "mutex" (short for
      "mutual exclusion") to facilitate this sort of resource
      locking. Once you create a mutex, there are two things you
      can do with it:


    *       lock it

    *       unlock it


Mutexes have the property that they can only be locked by
    one thread at a time. If two threads attempt to lock the same
    mutex, only one of them succeeds. The other one blocks until
    the first thread releases the mutex. In general, you use
    mutexes to protect some piece of shared data. In order to be
    useful, the mutex itself must be global so that all threads can
    see it (this is true of all pthreads synchronization objects).

      Let's modify the previous code so that we can properly access
      i (we'll show how to create mutexes later):


        int i;                          /* i is shared */
        pthread_mutex_t ilock;          /* controls access to i */


        void func(arg1,arg2)
                int arg1;               /* arg1 is private */
                float *arg2;            /* arg2 is private, *arg2 is shared */
        int zzz;                        /* zzz is private (auto storage class) */
        static float f;                 /* f is shared (static storage class) */

        pthread_mutex_lock(&ilock); /* lock i */
        something = i++;                /* access i */
        pthread_mutex_unlock(&ilock);       /* unlock i */


If you have worked with Asterisk/Trixbox for any length of time, you have dealt with codecs. You’ve seen terms thrown around such as ulaw, alaw, G711, G729, and on and on and one. But what are these? And what are the differences between them? When should use use G726 instead of ulaw? What codecs are even possible in Trixbox? I’ll try to clear some of this up.

For VoIP communication, you need to start with a protocol. The three big protocols are SIP, IAX2, and H323. SIP and IAX2 are natively supported in Trixbox’s version of Asterisk (v1.2), so I’m going to assume that you’re using one of these. Once you have your protocol in place, a codec tells the system what format to send the calls across the protocol.

Codecs are used to convert an analog voice signal to digital. They vary in sound quality and bandwidth consumption. Typically, the better the sound quality, the more bandwidth consumed…the less bandwidth consumed, the worse the sound quality. Here are the codecs currently supported in Asterisk v1.2:

ulaw &#8211; AKA G.711 &#8211; 64Kbps &#8211; ulaw is the standard US codec for uncompressed voice. For internal extension to extension calls, this is the preferred codec. Notice the 64Kbps? This is how much bandwidth is consumed by this codec. When thinking about bandwidth consumption, I like to think in terms of phone lines…a typical phone line (or T1 channel) is 56Kbps (remember the days of modems??). ulaw is just a little higher than that. If your Internet connection is a modem, you would want a more compressed codec. If you have 768Kbps up/down DSL, you should be able to run 12 ulaw calls across the connection (768Kbps / 64Kbps = 12). That is typically not recommended however, and with other Internet stuff going on, that number gets reduced significantly. If a client told me they had a 768Kbps connection, I would tell them not to expect good voice quality on more than 3-4 simultaneous calls with ulaw and that connection.

alaw &#8211; AKA G.711 &#8211; 64Kbps &#8211; alaw is the same as ulaw, but it is the European standard codec.

G.723.1 &#8211; 6.3Kbps or 5.3Kbps &#8211; This is the standard codec used by H323. Since I’m not talking about H323, I’ll skip this one.

G.726 &#8211; 32 Kbps &#8211; G726 is a good alternative to ulaw when you need to save some bandwidth. It consumes 1/2 the amount of bandwidth of ulaw, and the voice quality isn’t degraded much.

G.729 &#8211; 8Kbps &#8211; The G729 codec is excellent, but there is a trade-off. It has very low bandwidth consumption and decent voice quality, however it also has a dark side in that it isn’t free. G.729 licenses are available from Digium at the cost of $10.00 per channel. They also take a significant amount of CPU power to process the compression. Installation requires a purchased license from Digium, and you have to download and run their registration program…it is pretty easy to do, but is still an additional step. Plus, it bases the registration on the MAC address of the computer it was installed on, and is only transferrable once (and you have to contact Digium to do it). This is a good codec, but try G.726 or GSM first.

GSM &#8211; 13Kbps &#8211; GSM is a codec that comes from cell phone technology. It has pretty low bandwidth consumption, but you will notice lower voice quality than a standard PSTN line.

iLBC &#8211; 13.33Kbps &#8211; iLBC is another low-bandwidth codec. They claim better quality than G729, but I haven’t had much experience with them…I don’t know if that is a true statement or not.

Speex &#8211; configurable 4-48Kbps &#8211; Speex is another less-known codec. It’s advantage is that it is flexible (4Kbps to 48Kbps) in terms of bandwidth consumption, but it takes up more CPU than even G.729. Again, I have never used this codec, so I don’t know much more about it.

I hope that helps clear codecs up a bit. My general rule of thumb is to use ulaw if there aren’t any bandwidth constraints. If bandwidth is a consideration, I then try G.726 and GSM in that order. If a customer is jazzed about G.729, I have no problem using that as well (although I don’t think it offers enough advantage over G.726 or GSM to be worth $10 bucks).

sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2010-07-03 22:27:09
Processing time 0.0044 sec