Классическая операция получения данных из MySQL выглядит следующим образом:

snprintf(sqlcmd, sizeof(sqlcmd) - 1,
        "select n.id,n.name,n.ip,n.port,n.capacity,COUNT(c.node) 
         from cluster_nodes n left join active_calls c on (n.name=c.node) 
         where online=1 group by n.name");
sql_cmd.s = sqlcmd;
sql_cmd.len = strlen(sqlcmd);
LOG(L_DBG, "Trying to execute SQL: '%s'\n", sqlcmd);
fres = dbf.raw_query(db_handle, &sql_cmd, &res);
if (fres == 0) {
        total = RES_ROW_N(res);
        if (total > 0) {
                for(i = 0; i < total; i++) {
                        node = shm_malloc(sizeof(struct ci_li_node));
                        if (node == NULL) {
                                LM_ERR("Could not allocate shared memory\n");
                                return -1;
                        }
                        node->id = RES_ROWS(res)[i].values[0].val.int_val;
                        node->calls_init = RES_ROWS(res)[i].values[5].val.int_val;
                        node->calls_current = node->calls_init;
                        node->calls_max = RES_ROWS(res)[i].values[4].val.int_val;
                        node->port = RES_ROWS(res)[i].values[3].val.int_val;
                        snprintf(node->name, sizeof(node->name), "%s", 
                                (char*)RES_ROWS(res)[i].values[1].val.str_val.s);
                        snprintf(node->ip, sizeof(node->ip), "%s", 
                                (char*)RES_ROWS(res)[i].values[2].val.str_val.s);
                        node->next = NULL;
 
                        total_max += node->calls_max;
                        if (mylist->last == NULL) {
                                mylist->last = node;
                                mylist->first = node;
                        } else {
                                mylist->last->next = node;
                                mylist->last = node;
                        }
                }
                LOG(L_DBG, "PRELOAD TOTAL: [servers] %d items = %lu bytes.\n", 
                        i, i * sizeof(struct ci_li_node));
                mylist->dt = time(NULL);
        }       
        dbf.free_result(db_handle, res);
}

Как видим из простого примера, получение данных из MySQL сводится к трём действиям:

1. Отправляем SQL запрос с помощью команды raw_query.
2. Читаем результаты с помощью макросов RES_ROW_N и RES_ROWS
3. Подчищаем за собой память с помощью free_result

Пока мы действуем по шаблону – всё отлично работает.

Но стоит нам захотеть чего то большего – и подход придётся менять. Например приведенным выше кодом нельзя загрузить за раз большую таблицу (тысячи записей). Прокладочные интерфейсы БД и памяти – накладываются друг на друга и возникают интересные эффекты. Дело в том, что при попытке загрузить большую таблицу целиком – db_mysql выделяет память под неё – одним куском. С другой стороны, pkg_free не освобождает память моментально, а лишь помечает её как готовую к очистке. Всё это приводит к тому, что загрузка большой таблицы срабатывает 2 раза подряд, а на третий возникает ошибка – недостаточно памяти.

Зачем загружать всю таблицу целиком – спросите вы? Вариантов может быть очень много – самый распространённый, пожалуй, – для того, что бы закешировать данные из БД. На одной СУБД далеко не уедешь, даже на такой быстрой как MySQL. Итак, что же нужно сделать для того, что бы обойти проблемы с памятью? Ответ очень простой: нужно воспользоваться вызовом fetch_result. К сожалению, применение этого вызова не расписано в KAMAILIO (OPENSER) Devel Guide, но, как известно, лучшая документация это исходный код. С практикой применения этого вызова можно ознакомиться в модулях Kamailio:

[root@sipproxy kamailio-3.0.3]# grep -l fetch_result */*/*.c
...
modules_k/dialog/dlg_db_handler.c
modules_k/drouting/dr_load.c
modules_k/htable/ht_db.c
modules_k/pdt/pdt.c
...

Вызов fetch_result позволяет указать сколько строк мы хотим поместить в память. Таким образом, вызывая fetch_result в цикле – мы обработаем все строки возвращённые базой данных по порциям. Если вы планируете использовать fetch_result самостоятельно, необходимо передать NULL в качестве указателя db_res_t** _r у функций raw_query(…) и query(…). Для наглядности, рассмотрим похожий кусок кода, написанный с использованием вызова fetch_result. Параметр ci_preload_chunk задаёт количество строк загружаемых в память за 1 вызов:

snprintf(sqlcmd, sizeof(sqlcmd) - 1,
        "select name,owner from sip where host='dynamic' and owner>0"
);
sql_cmd.s = sqlcmd;
sql_cmd.len = strlen(sqlcmd);
LOG(L_DBG, "Trying to execute SQL: '%s'\n", sqlcmd);
fres = dbf.raw_query(db_handle, &sql_cmd, NULL);
if (fres == 0) {
        LOG(L_DBG, "Trying to fetch first %d items.\n", ci_preload_chunk);
        if (dbf.fetch_result(db_handle, &res, ci_preload_chunk) < 0) {
                LM_ERR("Error while fetching result\n");
                if (res) {
                        dbf.free_result(db_handle, res);
                }
                return 0;
        }       
        total = RES_ROW_N(res);
        LOG(L_DBG, "%d first items fetched.\n", total);
        if (total > 0) {
                do {
                        for(i = 0; i < total; i++) {
                                row = RES_ROWS(res) + i;
                                u = shm_malloc(sizeof(struct ci_li_sipuser));
                                if (u == NULL) {
                                        LM_ERR("Could not allocate shared memory\n");
                                        return -1;
                                }       
                                u->sipaccount = atoi((char*)VAL_STRING(ROW_VALUES(row)));
                                u->customer = VAL_INT(ROW_VALUES(row) + 1);
                                u->next = NULL;
                                if (mylist->last == NULL) {
                                        mylist->last = u;
                                        mylist->first = u;
                                } else {
                                        mylist->last->next = u;
                                        mylist->last = u;
                                }
                                mylist->elements++;
                                cnt++;
                        }
                        if (dbf.fetch_result(db_handle, &res, ci_preload_chunk) < 0) {
                                LM_ERR("Error while fetching result\n");
                                if (res) {
                                        dbf.free_result(db_handle, res);
                                }
                                return 0;
                        }
                        total = RES_ROW_N(res);
                } while (total > 0);
                dbf.free_result(db_handle, res);
        }
}

• Асинхронный TLS
• Поддержка UDP RAW сокетов на Linux (повышение производительности на 40-50%)
• Встроенные интерпретаторы LUA и Python
• Встроенные HTTP и XCAP серверы
• Подсистема кеширования работающая по алгоритму «индексированное дерево».
• Регистрация на других серверах по протоколу SIP
• Поддержка заголовка Reason для сообщений CANCEL
• Продолжение работы по слиянию проектов Kamailio и SER – объединены модули: sl, auth, sms и ratelimit

Встроенные интерпретаторы LUA/Python – это, судя по всему, дань моде. Так же как и встроенные серверы XCAP и HTTP. Все остальные изменения – крайне интересны. Надеюсь нововведения не отразятся на стабильности работы Kamailio.

                                 Messages  Retrans   Timeout   Unexpected-Msg
      INVITE ---------->         16        0         0
         100 <----------         0         0         0         16
         180 <----------         0         0         0         0
         183 <----------         0         0         0         0
         200 <----------  E-RTD1 0         0         0         0
         ACK ---------->         0         0
       Pause [      0ms]         0                             0
         BYE ---------->         0         0         0
         200 <----------         0         0         0         0

Данный сценарий не очень подходит для тестирования серверов перенаправления (redirect server). Дело в том, что на любой запрос клиента (INVITE, REGISTER и т.д.) сервер перенаправления, как правило, выдает ответ с кодом 300 (Multiple Choices) или 302 (Moved Temporarily). В сценарии по умолчанию, ответы с данными кодами попадают в категорию "Unexpected Messages" - неожиданных сообщений. В целом тестировать нагрузку можно и так, когда ваш сервер перестанет справляться с нагрузкой, цифра в колонке Timeout начнёт возрастать. Однако при таком подходе, невозможно отличить ответы с кодами 300 и 302 от других "неожиданных ответов".

Вторым недостатком использования теста по умолчанию, является его синтетичность. Все звонки инициированные по этому сценарию - идентичны между собой. Т.е. имеют одинаковые поля From, To, Contact и т.д. Результаты такого теста, могут сильно отличаться от реальности, т.к. одно единственное значение полей From, To, Contact - наверняка попадет в кеш тестируемой системы.

На помощь нам приходит чрезвычайная гибкость утилиты sipp. Дело в том, что пользователь может создать свой собственный, произвольный сценарий тестирования и описать его используя XML. Кроме того, существует возможность подставлять в SIP сообщения, генерируемые программой sipp данные из внешних источников - CSV файлов. Прочитать подробности о создании собственных сценариев, можно на официальном сайте программы sipp. Здесь же, в качестве примера, я приведу сценарий, используемый мной для тестирования производительности сервера перенаправления (SIP Redirect Server).

<?xml version="1.0" encoding="ISO-8859-1" ?>
<scenario name="Redirect Scenario">
    <send retrans="500">
     <![CDATA[
 
      INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
      Via: SIP/2.0/[transport] [local_ip]:[local_port]
      From: [field0] <sip:[field0]@[local_ip]:[local_port]>;tag=[call_number]
      To: sut <sip:[service]@[remote_ip]:[remote_port]>
      Call-ID: [call_id]
      Cseq: 1 INVITE
      Contact: sip:[field0]@[local_ip]:[local_port]
      Max-Forwards: 70
      Subject: Performance Test
      Content-Type: application/sdp
      Content-Length: [len]
 
      v=0
      o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
      s=-
      t=0 0
      c=IN IP[media_ip_type] [media_ip]
      m=audio [media_port] RTP/AVP 0
      a=rtpmap:0 PCMU/8000
 
    ]]>
   </send>
 
   <recv response="300" optional="true">
   </recv>
   <recv response="302">
   </recv>
</scenario>

Пару слов о структуре данного сценарий. Внутри сценария присутствует 1 тег send и 2 тега recv. Тег send описывает запрос отправляемый программой sipp, теги recv - возможные ответы на отправленное сообщение. В теге send присутствует конструкция <![CDATA[ ... ]]> Внутри которой находится тело отправляемого запроса. В теле запроса присутствует большое количество переменных sipp (слова в квадратных скобках). Большинство из них будет подставлено утилитой sipp автоматически. Наибольший интерес для нас представляет переменная [field0]. Перед отправкой на место данного ключевого слова подставляется первое поле из внешнего источника (CSV файла). Для того, что бы использовать этот сценарий, необходимо выполнить:

sipp -sf redirect.xml -inf uids.csv -s 1010 -l 0 -r 2000 10.10.1.4

Здесь redirect.xml - файл, содержащий наш сценарий. uids.csv - файл содержащий большое количество имён пользователей (как верных так и неверных). Именно из файла uids.csv подставляется первое поле взамен ключевого слова [field0]. Именно благодаря этому файлу мы уходим от синтетического сценария ближе к реальности, моделируя ситуацию в которой большое количество абонентов звонит на один и тот же номер. С помощью параметра -s 1010 указывается номер на который будут совершаться вызовы. Значение параметра -s подставляется вместо ключевого слова [service]. Если в сценарии заменить [service] на [field1] то можно смоделировать ситуацию, в которой множество абонентов совершает вызовы множества (различных) номеров. Параметр -l 0 - снимает ограничение на количество активных звонков в единицу времени. Параметр -r 2000 устанавливает скорость инициирования новых вызовов (CPS) - 2000 вызовов в секунду. Ну а 10.10.1.4 это, как несложно догадаться, IP адрес тестируемого сервера.

Так же приведу пример файла users.csv. Первой строкой в файле указывается ключевое слово, в нашем случаем - RANDOM. Это слово, определяет в каком порядке будут использованы строки файла. На сегодня возможны варианты: RANDOM - случайно, SEQUENTIAL - последовательно и специальное USER. Итак, вот он файл:

RANDOM
100;
101;
102;
103;
104;
...
11998;
11999;

Обратите внимание на ';' - для работы с sipp рекомендую включать в csv файлы пустую колонку в конец таблицы. Иначе, есть риск, что sipp добавит к полю виндовый \r. Например вместо имени пользователя "100" будет подставляться "100\r", что может изменить результаты тестирования. Если строк в вашем файле выходит слишком много, генерировать такой файл ненужно. Существует возможность описать последовательность значений в виде формулы. Например вот такая запись будет эквивалентна CSV файлу с цифрами от 0 до 100 000 в первой колонке:

USERS,PRINTF=100000
%d

Реальный тест с использованием приведенного сценария выглядит вот так:

[root@voiptest ~]# sipp -sf redirect.xml -inf uids.csv -s 1010 -l 0 -r 2000 10.10.1.4
Resolving remote host '10.10.1.4'... Done.
------------------------------ Scenario Screen -------- [1-9]: Change Screen --
  Call-rate(length)   Port   Total-time  Total-calls  Remote-host
2000.0(0 ms)/1.000s   5060      49.63 s        99272  10.10.1.4:5060(UDP)

  1270 new calls during 0.636 s period   0 ms scheduler resolution
  0 calls (limit 0)                      Peak was 40 calls, after 2 s
  0 Running, 66004 Paused, 0 Woken up
  0 dead call msg (discarded)            5 out-of-call msg (discarded)
  1 open sockets

                                 Messages  Retrans   Timeout   Unexpected-Msg
      INVITE ---------->         99272     1         0
         300 <----------         0         0         0         0
         302 <----------         99272     0         0         0

Удачного тестирования!

Казалось бы X-Lite (он же eyeBeam) от фирмы CounterPath, один из самых распространённых софтфонов, не должен содержать детских ошибок в работе с SIP proxy, но к сожалению это не так. X-Lite/eyeBeam принципиально не умеет работать с перенаправляющими (Redirect) серверами. Перенаправляющие SIP сервера, это как правило SIP proxy, настроенные таким образом, что бы на запросы клиентов отвечать кодами 3XX (как правило 300 «Multiple Choices» или 302 «Moved Temporarily») – перенаправляя клиента на наименее загруженный сервер.

При попытке зарегистрироваться на сервере перенаправления, X-lite пишет на своём экране: «Registration error: 302 – Redirect». Прямо скажем коды 3XX не являются ошибками, однако X-Lite/eyeBeam считает иначе. Если мы посмотрим wireshark-ом, то увидим следующее:

При попытке зарегистрироваться на балансировщике нагрузки (192.168.14.198), X-Lite (192.168.1.114) получает перенаправление на адрес 192.168.14.207. После этого X-Lite, в соответствии с RFC3261, должен сформировать новый SIP запрос и отправить его по новому адресу (192.168.14.207). Как показывает wireshark, X-Lite формирует новый SIP запрос, подставляя в него адрес полученный от балансировщика нагрузки. Однако, вместо того что бы отправить его по соответствующему IP адресу, X-Lite продолжает использовать IP адрес SIP proxy. Судя по форуму CounterPath, этой проблеме более 2х лет.

Что же другие продукты от CounterPath? eyeBeam, как и следовало ожидать, ведёт себя точно так же как X-Lite, т.е. некорректно обрабатывает редиректы. А вот дорогущий Bria Professional вероятно использует другое ядро, отличное от eyeBeam/X-Lite посколько он правильно работает с перенаправлениями. Что делать? как быть? – Заплатить 50 баксов за Bria Professional или поставить Zoiper. Zoiper корректно отрабатывает перенаправления 3XX полученные от Kamailio.

Если вы начали программировать модуль для Kamailio, вы уже наверняка ознакомились с замечательным документом KAMAILIO (OPENSER) Devel Guide – если нет, рекомендую сделать это прямо сейчас. Содержимое документа будет актуально и пользователям OpenSIPS.

В двух словах о функциях child_init(rank) и mod_init(). Обе эти функции используются для инициализации вашего модуля, с небольшим различием. Функция mod_init() выполняется сразу после того как Kamailio инициализирует параметры вашего модуля, установленные из конфига с помощью директив modparam(). Очень важно обратить внимание на то, что mod_init() выполняется только один раз. mod_init() подходящее место для инициализации переменных находящихся в общей (разделяемой) памяти. Для распараллеливания вычислений используется старый-добрый fork() т.е. Kamailio создаёт несколько копий процесса, часть из этих копий используются для служебных целей, а остальные – обрабатывают SIP сообщения в соответствии с конфигурационным файлом. Сразу после форка, вызывается функция child_init(rank). В отличие от mod_init(), child_init(rank) выполняется не 1 раз а несколько – по одному разу для каждого нового процесса. Для того, что бы отличить, что за процесс вызвал child_init(rank) используется единственный параметр этой функции – целочисленный rank. В «KAMAILIO (OPENSER) Devel Guide» – опущен вопрос о том, какие значения он может принимать. Но, как известно, лучшая документация это исходный код. Возможные специальные значения параметра rank перечислены в файле sr_module.h:

#define PROC_MAIN      0  /* Main ser process */
#define PROC_TIMER    -1  /* Timer attendant process */
#define PROC_RPC      -2  /* RPC type process */
#define PROC_FIFO      PROC_RPC  /* FIFO attendant process */
#define PROC_TCP_MAIN -4  /* TCP main process */
#define PROC_UNIXSOCK -5  /* Unix socket server */
#define PROC_ATTENDANT -10  /* main "attendant process */
#define PROC_INIT     -127 /* special rank, the context is the main ser
                                      // process, but this is guaranteed to be executed
                                      // before any process is forked, so it can be used
                                      // to setup shared variables that depend on some
                                      // after mod_init available information (e.g.
                                      // total number of processes).
                                      // WARNING: child_init(PROC_MAIN) is again called
                                      // in the same process (main), but latter
                                      // (before tcp), so make sure you don't init things
                                      // twice, bot in PROC_MAIN and PROC_INT */
#define PROC_NOCHLDINIT -128 /* no child init functions will be called
                              //  if this rank is used in fork_process() */
 
#define PROC_MIN PROC_NOCHLDINIT /* Minimum process rank */

Кроме специальных значений rank <= 0, так же имеются положительные, последовательно начиная с 1. Эти значения получают процессы работники – которые заняты непосредственно обработкой SIP сообщений. Таким образом, если для работы вашего модуля необходимо соединение с БД, целесообразно открыть его из функции child_init(rank) для процессов, у которых rank > 0. Например вот так:

static int child_init(int rank) {
        srand((11+rank)*getpid()*7);
 
        if (rank > 0) {
                if(init_db()!= 0) {
                        LM_ERR("could not initiate a connection to the database\n");
                        return -1;
                }
 
                LM_ERR("Rank: %d, PID: %d. Connecting to DB.\n", rank, getpid());
                if (db_bind_mod(&db_url, &dbf) < 0) {
                        LM_ERR("Unable to bind to a database driver\n");
                        return -1;
                }
                db_handle = dbf.init(&db_url);
        } else {
                LM_ERR("Rank: %d, PID: %d. NOT Connecting to DB.\n", rank, getpid());
        }
        return 0;
}

При запуске Kamailio с модулем содержащим подобную инициализацию, мы увидим в сислоге:

Aug 25 13:21:04 sipproxy /usr/local/sbin/kamailio[21995]: ERROR: lb [lb.c:345]: Rank: -127, PID: 21995. NOT Connecting to DB.
Aug 25 13:21:04 sipproxy /usr/local/sbin/kamailio[21996]: ERROR: lb [lb.c:338]: Rank: 1, PID: 21996. Connecting to DB.
Aug 25 13:21:04 sipproxy /usr/local/sbin/kamailio[21999]: ERROR: lb [lb.c:338]: Rank: 3, PID: 21999. Connecting to DB.
Aug 25 13:21:04 sipproxy /usr/local/sbin/kamailio[22001]: ERROR: lb [lb.c:345]: Rank: -1, PID: 22001. NOT Connecting to DB.
Aug 25 13:21:04 sipproxy /usr/local/sbin/kamailio[22002]: ERROR: lb [lb.c:345]: Rank: -1, PID: 22002. NOT Connecting to DB.
Aug 25 13:21:04 sipproxy /usr/local/sbin/kamailio[21995]: ERROR: lb [lb.c:345]: Rank: 0, PID: 21995. NOT Connecting to DB.
Aug 25 13:21:04 sipproxy /usr/local/sbin/kamailio[21998]: ERROR: lb [lb.c:338]: Rank: 2, PID: 21998. Connecting to DB.
Aug 25 13:21:04 sipproxy /usr/local/sbin/kamailio[22000]: ERROR: lb [lb.c:338]: Rank: 4, PID: 22000. Connecting to DB.

Вначале было слово SER! SIP Express Router был разработан в Германии в институте Fraunhofer (известным разработкой MP3) в 2001 году. Компания разработчиков подобралась весьма пёстрая – румыны, венгры, испанцы и даже, что удивительно, немцы. В 2004 году проект был выделен из под крыла института и пущен в свободное плавание. Для этого была создана компания iptel.org. Но, как известно любому LOR-овцу – если тебе что-то не нравится в проекте – его надо тут же форкнуть, к чему это общение, обсуждение проблем и компромисы с недостойными?

Что может не нравится в проекте созданом на деньги немецких налогоплательщиков? ну хотя бы то, что генеральных директоров в новой компании не 5 и даже не 3. Так проект SER был форкнут и появился параллельный проект OpenSER. Почти 4 года оба проекта находились в анабиозе. Различия между этими проектами и сегодня минимальны, не смотря на то, что 4 года – приличный срок. И вот настал август 2008 года. Чего же удалось достичь проекту OpenSER за 4 года? Ну во-первых выяснилось, что название OpenSER – нарушает торговые знаки, а во-вторых, что два генеральных директора тоже многовато. По этому в августе 2008 года OpenSER был форкнут и переименован. Из OpenSER-а вышли две ветки: Kamailio и OpenSIPS. Каждая из веток претендует считаться наследницей OpenSER-а. По моему мнению, из всех перечисленных продуктов, Kamailio обладает наибольшей пользовательской базой, а значит меньше шансов, что Ваши вопросы остануться без ответа. Недавно было объявлено о «совместной инициативе» проектов SER и Kamailio. Пока инициатива выглядит в виде централизованного сайта для двух проектов: sip-router.org, но видя любовь авторов к форкам, можно предположить, что рано или поздно будит мёрдж.

• Минимизация отклонений от стандартной конфигурации Asterisk-realtime.
• Вся аутентификация — внутри Kamailio.
• Все звонки, в т.ч. и локальные — проходят через Asterisk.
• Все media потоки — проходят через Asterisk.
• Обработка SIP сообщений не связанных со звонками выполняется с помощью Kamailio.

Согласно предложенной схеме, регистрация выглядит следующим образом:

Аппарат А, отправляет запрос REGISTER и после успешной аутентификации регистрируется на Kamailio. Kamailio регистрируется на сервере Asterisk от имени клиента, указав в качестве котакта свой IP адрес. Таким образом при звонке с Asterisk к абоненту A, Asterisk отправит INVITE к Kamailio, а тот в свою очередь передаст его клиенту. Кстати о звонках, звонок между абонентами A и B выглядит следующим образом:

Для установки соединения между аппаратами A и B, аппарат A отправляет запрос INVITE по IP адресу сервера Kamailio. После успешной аутентификации, Kamailio отправляет INVITE к Asterisk. Asterisk, отправляет INVITE к абоненту B, однако в качестве контакта для абонента B указан IP адрес Kamailio. Получив INVITE от Asterisk для абонента B, Kamailio проверяет базу зарегистрированных пользователей (usrloc) и пытается перенаправить INVITE для абонента B по его фактическому адресу.

На мой взгляд: просто, элегантно, и, самое главное, масштабируемо. Я обычно использую несколько иную балансировку нагрузки, однако предложенная схема заслуживает самого тщательного изучения. Автор документа, Daniel-Constantin Mierla, обещает регулярно обновлять инструкцию, поддерживая её в актуальном состоянии.

• Исправлено падение TLS из-за некорректного выделения памяти.
• return() теперь работает внутри цикла while().
• Исправлено падение mediaproxy, в случае когда ответ содержит больше media потоков чем оригинальный INVITE.
• Исправлено падение lib/srdb1, вызванное отсутствием проверки RES_ROW(res) на NULL.
• Исправлено падение avp_copy() при использовании флага ‘g’.
• Исправлено падение в модуле carrierroute.
• Исправлена утечка памяти в модуле topoh.

Довольного много падений для стабильной версии. Радует частота выхода исправленных версий — команда Kamailio взяла за правило выпускать релиз с исправлениями раз в 2 месяца и пока успешно следует ему. Так же хочу отметить, что все исправления, кроме выхода из цикла while() – касаются модулей. В ядре Kamailio серьёзных проблем вроде утечек памяти или падений — не исправлялось. Будем надеяться, что их там нет.

8 марта, тихо и незаметно (c), вышел очередной релиз замечательного SIP сервера Kamailio, в прошлом известного как OpenSER. Для тех кто не в курсе, Kamailio это SIP сервер с открытым исходным кодом. Благодаря тому, что он не занимается обработкой медиа-потоков, Kamailio, по заявлениям авторов, способен обслуживать более 300 000 пользователей, совершающих звонки со скоростью свыше 5000 звонков в секунду (в stateless режиме). Kamailio обладает множеством интересных возможностей, из наиболее интересных можно выделить: Поддержка всех транспортных протоколов (UDP, TCP, TLS и SCTP), поддержка IPv6, конвертация траспорта (например UDP в TLS), поддержка DNS SRV и ENUM, интеграция с net-snmp, CPL – Call Processing Language (RFC3880) и многое другое. Подробный список можно изучить здесь.

Kamailio v3.0.1 – это версия исправляющая ошибки обнаруженные в недавно вышедшей 3.0.0. За 2 месяца с момента выхода 3.0.0 в Kamailio внесено 44 изменения. Из серьёзных изменений можно выделить лишь исправление segfault-а при чтении некорректного конфигурационного файла. Рекомендую обновиться все пользователям Kamailio v3.0.0.

Наконец-то прочитал португальско-индусскую книгу Building Telephony Systems with OpenSER. Впечатление книга оставила двоякое. С одной стороны, в книге большое количество разнообразных ошибок (лексических, орфографических, опечаток в конфигурационных файлах и тому подобного) с другой стороны, других книг по SIP прокси – просто нет.

Кроме проблем с орфографией, выделю ещё несколько моментов, которые мне не понравились. Книга посвящена построению сети VoIP провайдера, на базе OpenSER/Kamailio. По мнению автора, OpenSER/Kamailio это основа сети SIP провайдера, тогда как для Asterisk, отводится роль голосовой почты и шлюза в ТФОП. С таким подходом я не согласен. По моему мнению, время, когда провайдеры зарабатывали исключительно на терминации трафика – уходит в прошлое. Доля доходов от дополнительных видов обслуживания (голосовая почта, конференции, виртуальные частные АТС и т.п.) – растёт из года в год. Реализация ДВО с помощью OpenSER/Kamailio представляется мне неоправданно сложной и неестественной. С развитием Asterisk как мультисервисной платформы, единственным применением OpenSER/Kamailio в сети ITSP остаётся – балансирование нагрузки и, надо отдать должное, с этим он справляется превосходно.

К сожалению, в книге никак не затронут вопрос использования OpenSER/Kamailio в качестве диспетчера нагрузки (loadbalancer) и это – третий недостаток.

Не совсем понятно, на кого рассчитана данная книга? В предисловии написано:

This book is intended for Linux and networking professionals, who want to understand SIP and OpenSER from a practical perspective, or are interested in IP telephony and call routing.

Совсем не понятно, зачем профессионалам объяснять со скриншотами процесс установки Debian. И сделано это, в ущерб разделу о протоколе SIP. В главе «Introduction to SIP» нет ни одного слова об основных методах протокола SIP (REGISTER, INVITE, CANCEL и т.д.). Как можно опустить столь значимую информацию в пользу скриншотам с Debian – мне не ясно.

Ну и последнее, что сильно цепляется за глаза, это отсутствие в книге описания конфигурационного языка OpenSER/Kamailio и его основных команд. Из книги, вы никогда не узнаете, что делают команды lookup(«location»), fix_nated_register() и любых других.

Не смотря на все недостатки данной книги, рекомендую её к прочтению всем, кто профессионально занимается IP телефонией. Если у вас нет опыта работы с OpenSER/Kamailio эта книга, хоть и с натяжками, позволит вам составить своё впечатление об этом программном продукте.