Лично я не особо боюсь того, что к моей системе подберут пароль одного из клиентов. Вероятность данного события мала, поскольку все пароли в системе стойкие. И даже если пароль подберут, у большинства клиентов установлено ограничение на 1-2 одновременных вызова. Для меня неприятность SIP брутфорса заключается в другом. Дело в том, что в Asterisk вся SIP UDP сигнализация обрабатывается одним единственным тредом. Обработка SIP трафика – ресурсоёмкий процесс, 7-8 мегабит мусорных запросов заставляют Asterisk полностью скушать ядро процессора (например Intel E5335, E5405). Когда ядро полностью съедено, происходит вытеснение полезного SIP трафика – мусорным. Перестают работать DTMF у клиентов использующих SIP INFO. Начинаются проблемы с установкой новых и завершением существующих соединений. И вот это – основная угроза которую несут роботы-брутфорсеры.

Так как же бороться с проблемами о которых нет сообщений в логах? Очень просто – необходимо сгенерировать сообщение о проблеме самому, тогда всю остальную часть нашей системы противодействия (например программу fail2ban) можно будет оставить без изменений. Характерным признаком брутфорса является большое количество SIP пакетов в единицу времени. Посчитать количество пакетов в единицу времени можно с помощью модуля iptables под названием recent. В интернете есть много примеров как с помощью модуля recent отбрасывают пакеты приходящие с частотой выше определённой. Мы, вместо отбрасывания, будем генерировать сообщения для нашей системы обнаружения атак (например fail2ban). Такой подход имеет свои недостатки и преимущества. Основным недостатком является, то что на обработку сообщений будут тратиться ресурсы системы, тогда как отбрасывание пакета условно бесплатное. Преимуществ чуть больше: мы сможем воспользоваться всеми возможностями нашей системы обнаружения атак, такими как белые списки IP адресов, единообразный учёт всех обнаруженных атак и так далее.

От теории – к практике! Подготовим скелет из правил iptables:

-A INPUT -p udp --dport 5060 -j SCAMBLOCK
-A INPUT -p udp --dport 5060 -m recent --set --name SIP
-A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix "SIP flood detected: "

Первое правило проверяет наш пакет по цепочке SCAMBLOCK. В данной цепочке хранятся заблокированные IP адреса, если пакет совпадает с одним из адресов этой цепочки – он отбрасывается. Если пакет не отброшен, то во втором правиле он помечается для учёта под именем SIP. Третье правило считает не превысил ли данный пакет указанное количество (60) за указанное время (2 секунды). Если количество не превышено – правило игнорируется, если превышено – выполняется действие. В нашем случае в системный лог пишется детальная информация о пакете начинающаяся со строки «SIP flood detected: «. Количество пакетов и время считаются отдельно для каждого источника. Таким образом получается, что мы ограничили скорость приёма SIP пакетов от каждого незаблокированного IP адреса на уровне 30 пакетов в секунду. Для меня данное ограничение является комфортным, с одной стороны все клиенты, даже самые крупнные, шлют пакеты с одного IP адреса со скоростями ниже 30 пакетов/с, с другой стороны, 30 пакетов в секунду практически не отражаютя на работе системы. Возможно, что эту величину следует подправлять в ту или иную сторону в зависимости от производительности сервера, количества и типа абонентов.

В некоторых системах встроенное ограничение модуля recent на параметр hitcount весьма небольшое, например в CentOS это ограничение составляет 20 пакетов. Если вы попробуете выполнить приведенную выше команду, то получите следующую ошибку:

iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix "SIP flood detected: "
iptables: Unknown error 4294967295

Или вот так, для 64 битных систем:

iptables -A INPUT -p udp --dport 5060 -m recent --update --seconds 2 --hitcount 60 --name SIP \
-j LOG --log-prefix "SIP flood detected: "
iptables: Unknown error 18446744073709551615

Изменить максимальное ограничение можно передав модулю recent специальный параметр при загрузке. Для этого создадим файл /etc/modprobe.d/ipt.conf и пропишем в нём интересующий нас параметр:

options ipt_recent ip_pkt_list_tot=60

Будьте осторожны увеличивая данное ограничение, помните что вместе с ним увеличивается память, требуемая для хранения последних пакетов, а также количество циклов процессора требуемые на их обработку.

Ну вот и всё, теперь любой флуд на порт 5060 будет обнаружен с помощью модуля recent пакета iptables. Сообщение об обнаруженном флуде будет направлено в системный лог где его сможет увидеть наша любимая система обнаружения атак (например fail2ban). iptables не ограничивает нас одним лишь системным логом, действию LOG можно указать уровень (level) и facility сообщения, а в настройках Syslog перенаправить данные сообщения в отдельный файл. Сами же сообщения о SIP флуде будут выглядеть вот так:

Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=370 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=350
Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=369 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=349
Jun 17 23:54:44 sip2 kernel: SIP flood detected: IN=eth0 OUT= MAC=00:21:5e:db:15:b8:00:0f:34:f8:28:7f:08:00 SRC=184.172.62.3 DST=192.168.224.217 LEN=370 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=5495 DPT=5060 LEN=350

В качестве исходных данных были взяты CDR трёх Российских операторов связи, предоставляющих возможность подключиться к ТФОП по протоколу SIP. CDR были взяты за период с 1 ноября 2009 года по 1 ноября 2010 года. Исходные данные были подвергнуты простейшей обработке – агрегации. Так, например, записи содержащие в Useragent значения CUCM, Cisco-CCM4.1, Cisco-CCM5.1 – были объединены под общим названием CUCM/Cisco Call Manager, различные версии оборудования Linksys – Linksys/SPA1001-3.1.19(SE), Linksys/SPA8000-6.1.3 и прочие – под общим названием Linksys и так далее.

После агрегации – настало время раздавать призовые места. Критерий места – очень простой, кто сделал больше всех трафика – тот и молодец. На картинке наша двадцатка лидеров выглядит вот так:

По оси Х отложены % от Совокупного трафика. Кому недостаточно картинки, тот может посмотреть на конкретные цифры:

Серьёзные пацаны на ЛОРе решают – дорос ли Asterisk до ентерпрайза или нет, и на сколько далёк он ещё от CUCM/Cisco Call Manager, а тем временем, этот самый недорощенный Asterisk забрал на себя 42% трафика, а значит реальных денег. Богато представлено оборудование под названием Linksys – российские пользователи IP телефонии по достоинству оценили высокое качество при минимальной цене. Судя по тому что в двадцатку попал T38Modem – каждый 150ый звонок совершаемые в России по IP телефонии – это отправка спама по факсу :) Удивил чрезвычайно низкий процент трафика приходящийся на оборудование D-Link. Судя по частоте упоминания в рунете, железки D-Link должны встречаться на порядок чаще оборудования Linksys. Вероятно голосовые шлюзы D-Link, в отличие от Linksys, предназначены не для передачи голоса по IP, а для общения в соответствующих форумах :)

                                 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.

• Linksys 3102 for Dummies

Платы USRP поддерживают установку расширений (дочерних плат). Дочерние платы позволяют USRP принимать и передавать сигнал на различных частотах. Например, для работе в стандарте GSM850/900 потребуется два модуля RFX900. Для взаимодействия OpenBTS с железом, используется библиотека libusrp. Далее, с помощью библиотек oSIP и oRTP, OpenBTS создаёт SIP звонки, которые, в свою очередь, направляются в Asterisk. В качестве имени пользователя, OpenBTS подставляет уникальный номер IMSI (International Mobile Subscriber Identity), записанный на SIM-карту.

Более подробно о проекте The OpenBTS Project можно кзнать в его wiki, которая является частью проекта GNU Radio.

Как говорится: имеющий глаза да увидит! Тем не менее коротко пробежимся по перечисленным технологиям. H.264 и AAC – кодеки для видео и аудио. Многие блогеры пишут про H.263 – нагло врут. Другая часть блогеров распинается в стенаниях по поводу несвободности H.264 – полностью игнорируя несвободный AAC. SIP – малоизвестный протокол сигнализации IP телефонии. STUN, TURN и ICE – технологии для работы с NAT-ом. Кстати то, как связываются два iPhone4, находящиеся за NAT-ом – большая загадка, но об этом позже. RTP и SRTP – протоколы передачи медиа (звук и видео) – обычный и «безопасный» – с поддержкой шифрования.

Смешно читать комментарии вроде «FaceTime – бяка, лучше буду пользоваться IP телефонией». Друзья, FaceTime это и есть IP телефония. Другой смешной шуткой является сравнение 3G видео звонков, которые действительно не новы и FaceTime от Apple. Это технологии разного уровня и разного времени. 3G видео звонки это H.324M – наследие ISDN видеоонференций разработанных в 90е. FaceTime это SIP и H.264 – наиболее прогрессвиные технологии связи и кодирования видео на сегодня.

Таким образом, мы имеем SIP телефон интегрированный в iOS4 – и это замечательно! Да, сегодня в AppStore существует большое количество SIP телефонов в т.ч. и бесплатных. Лично мне нравится Adore SIP Client. Но у всех этих приложений есть один общий недостаток – они не интегрированы в iOS, а значит нельзя позвонить из стандартной телефонной книги через SIP, для входящих звонков не отображаются фото и имя звонящего и т.п. Неизвестно, будут ли все эти возможности реализованы в новом iPhone4, ведь распространятся он будет как и предыдущие – залоченым на AT&T. Оператор врядли обрадуется уводу дорогого трафика в VoIP сети. Однако, раз SIP video клиент уже в iPhone4, не составит никакого труда интегрировать его с телефонной книгой и с другими базовыми возможностями iPhone – надеюсь так и будет сделано.

Пока нет данных о том, как именно взаимодействуют данные технологии под общим названием FaceTime – попробуем пофантазировать. Для того что бы совершить SIP звонок надо во-первых, передать SIP сообщение от абонента A к абоненту B, а во-вторых установить передачу медиа (звук и видео) между абонентами. Для усложнения задачи, предположим что каждый абонент сидит за NAT-ом на своей точке доступа. Основные вопросы к Facetime: Как устанавливается прямая медиа-сессия между абонентами за NAT-ом?, Каким образом абонент А, узнаёт IP адрес абонента B?, Если в схеме связи участвует SIP сервер (proxy или registrar) – каким образом происходит авторизация?

Для преодоления NAT-а, iPhone4 поддерживает такие замечательные технологии как STUN, TURN и ICE. Последняя, к примеру, позволяет устанавливать прямой обмен данными между абонентами, находящимися за NAT-ом. Вариант передачи медиа-трафика, с помощью третьих лиц (абонентов имеющих реальный IP адрес) – по аналогии со Skype – маловероятен. Во-первых, процессор A4, используемый в iPhone4, откровенно слаб для подобных фокусов. Во-вторых Apple заявляет о своем желании сделать FaceTime индустриальным стандартом и привлечь других вендоров. Надеяться что все вендоры которые будут использовать FaceTime – будут по честному пропускать трафик NAT-абонентов через абонентов с реальными IP – было бы слишком наивно.

Каким образом абоненты узнают адреса своих контрагентов для установки видео соединения? Первое, что приходит в голову, это специальная посылка, с помощью обычного модема своих сетевых параметров противоположной стороне. А затем попытка прямого SIP соединения двух абонентов по Wi-Fi (IP) сети.

Другой альтернативой данному подходу, может быть использование централизованного SIP сервера. Как известно протокол SIP обладает потрясающей масштабируемостью. По заявлениям автора Kamailio, их программный продукт, работающий на средненьком по современным меркам сервере, способен обслужить звонки от SanFrancisco Bay Area (население 7.5 млн чел). Компании уровня Apple не составит труда разместить десяток SIP серверов работающих в качестве регистраторов, для сообщения IP адресов абонентам, желающим установить видеосоединение.

Однако использование SIP серверов поднимает несколько вопросов. Прежде всего это авторизация. Для того что бы телефон зарегистрировался на SIP сервере, ему необходимо использовать для этого некий уникальный идентификатор. Идентификатор не проблема с ходу в голову приходят: AppleID, MAC, IMEI или, например, серийный номер SIM карты. Сложность состоит в том, что тот кто пытается установить соединение с вами, должен знать ваш идентификатор. Ситуация ещё более усложняется возможным участием других вендеров.

Некоторые обозреватели, предполагают что, для локации абонента будет использована технология ENUM. Отвечу коротко: ENUM-а не будет. ENUM, это технология заточенная под оператора связи. Вставить свою запись в DNS, без разрешения оператора, которому пренадлежит ваш номер – не получится. Даст ли мобильный оператор такое разрешение – помоему очевидно, что нет.

Что ж, ждать осталось не долго, через 2 дня iPhone4 официально поступит в продажу и мы получим возможность изучить, насколько элегантно (я надеюсь) компания Apple реализовала SIP видео телефон.

Вначале было слово 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 серьёзных проблем вроде утечек памяти или падений — не исправлялось. Будем надеяться, что их там нет.