Напомню, что Asterisk 1.8.0 позиционируется как LTS – Long Term Support, т.е. как долговременное решение пришедшее на смену Asterisk 1.4 в отличие от Asterisk 1.6.x которые были тестовыми площадками. Основными нововведениями в Asterisk 1.8 являются:

• SRTP – технология позволяющая шифровать медиа потоки.
• Поддержка IPv6
• Поддержка Connected Party Identification
• Интеграция с разнообразными календарями
• CEL (Channel Event Logging) – новая подсистема логирования событий в канале. Данная подсистема предназначена для качественного биллинга сложных звонков (коллцентры, несколько трансферов и т.д.)
• Распределённый учёт состояния устройств (DevState) с помощью Jabber/XMPP PubSub
• Поддержка AOC (Advice of Charge)

Платы 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.

• Минимизация отклонений от стандартной конфигурации 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, обещает регулярно обновлять инструкцию, поддерживая её в актуальном состоянии.

[May 14 14:16:15] WARNING[31798]: chan_sip.c:8749 process_sdp_c: Unable to lookup
RTP Audio host in c= line, 'IN IP4 8000'
[May 14 14:16:15] WARNING[31798]: chan_sip.c:8397 process_sdp: Insufficient information
in SDP (c=)...

Дело в том, что Zoiper нарушает RFC4566 – SDP: Session Description Protocol. Согласно этому документу, параметр SDP ‘c=’ должен быть использован для указания адреса соединения:

5.7.  Connection Data ("c=")

      c=<nettype> <addrtype> <connection-address>

   The "c=" field contains connection data.

   A session description MUST contain either at least one "c=" field in
   each media description or a single "c=" field at the session level.
   It MAY contain a single session-level "c=" field and additional "c="
   field(s) per media description, in which case the per-media values
   override the session-level settings for the respective media.

   The first sub-field ("<nettype>") is the network type, which is a
   text string giving the type of network.  Initially, "IN" is defined
   to have the meaning "Internet", but other values MAY be registered in
   the future (see Section 8).

   The second sub-field ("<addrtype>") is the address type.  This allows
   SDP to be used for sessions that are not IP based.  This memo only
   defines IP4 and IP6, but other values MAY be registered in the future
   (see Section 8).

   The third sub-field ("<connection-address>") is the connection
   address.  OPTIONAL sub-fields MAY be added after the connection
   address depending on the value of the <addrtype> field.

   ...

В действительности же Zoiper пытается в поле ‘c=’ указать порт, не смотря на то, что он уже указан в поле ‘m=’:

s=Zoiper_session
c=IN IP4 8000
t=0 0
m=image 8000 udptl t38

а вот Linksys SPA2102 (прошивка 5.1.12) заполняет все поля корректно:

s=-
c=IN IP4 10.10.10.201
t=0 0
m=image 16474 udptl t38

Zoiper заполняет неверно поле ‘c=’ только для сообщения re-INVITE, которое должно запустить t38 сессию. Сообщение INVITE, инициирующее голосовое соединение, составляется корректно:

s=Zoiper_session
c=IN IP4 10.10.10.202
t=0 0
m=audio 8000 RTP/AVP 8 3 101

Самое интересное заключается в том, что Asterisk 1.6.0 отлично передавал факсы отправленные с помощью Zoiper, не смотря на нарушение RFC. Вероятно Asterisk стал чувствительным к ошибке, после внедрения нового алгоритма обработки SDP Asterisk 1.6.2 revision 227760.

Кроме тестирования сигнализации (SIP) sipp способен тестировать и медиа нагрузку. Для этого существуют два модуля: PCAP play и RTP echo. PCAP play – проигрывает заранее записанный сетевым анализатором (например wireshark) медиа файл. RTP echo – позволяет sipp отсылать обратно все полученные RTP потоки.

Пример использования sipp

sipp 10.10.10.1 -s 12345 -i 10.10.10.2 -d 2h -l 60 -aa -mi 10.10.10.2 -rtp_echo -nd -r 10

• 10.10.10.1 – IP адрес SIP сервера, на который следует слать запросы.
• -s 12345 – Указывает номер который будет вызван. Может быть числом или текстом. Значение по умолчанию – service
• -i 10.10.10.2 – Локальный IP адрес. Этот адрес будет использован в SIP сообщениях в качестве адреса источника сообщений. По умолчанию используется адрес 127.0.0.1.
• -d 2h – Устанавливает длительность звонков. В данном случае звонки будут длиться 2 часа. Длительность по умолчанию – 1 секунда.
• -l 60 – Ограничивает максимальное количество одновременных звонков – 60.
• -aa – Включает автоматические ответы 200 OK на сообщения INFO, UPDATE и NOTIFY.
• -mi 10.10.10.2 – Устанавливает локальный IP для RTP.
• -rtp_echo – Включает режим RTP эха. Все RTP пакеты полученные от удалённой стороны – отправляются обратно.
• -nd – Отключает стандартную обработку неожиданных ситуаций – sipp будет прерывать звонки в случае получения неправильных SIP сообщений.
• -r 10 – Устанавливает максимальную «скорость звонков» (CPS) в данном случае – не более 10 звонков в секунду.

Максимальной скоростью вызовов можно управлять во время работы sipp с помощью клавиш «+» и «-» – повышая и понижая её соответственно. Вообще, опустив параметры -aa -mi 10.10.10.2 -rtp_echo -nd – мы получаем отличное средство для тестирования отказоустойчивости и максимального CPS у SIP proxy.

Настройка Asterisk

Для того, что бы Asterisk принимал звонки от sipp, необходимо создать в SIP.conf специальный SIP-peer с именем sipp. К сожалению, заставить sipp совершать вызовы от имени существующего пользователя – нельзя. В стандартных сценариях sipp всегда представляется как sipp. Добавляем в SIP.conf запись:

[sipp]
type=friend
context=in
username=sipp
host=10.10.10.2
dtmfmode=rfc2833
disallow=all
allow=ulaw,alaw
insecure=port,invite

Важными моментом, является наличие кодека ulaw в списке разрешенных т.к. именно его анонсирует sipp. Если 711u не будет в списке разрешённых кодеков, то Asterisk отклонит вызов от sipp. Вторым важным моментом, является строка insecure=port,invite. Данная строка заставляет Asterisk авторизовать sipp не по паролю, а по IP адресу указанному в поле host. Кроме записи в SIP.conf, можно создать специальный контекст в extensions.conf для обработки тестовых звонков от sipp. Следующий пример принимает звонки на «номер» service – именно этот идентификатор используется по умолчанию:

[in]
exten => service,1,MusicOnHold()

Вот и всё. Успехов в стресс тестах!

• Документация для sipp версии 3.0

Unknown signalling method 'pri_cpe'

Значит вы забыли установить библиотеку libpri. Установите библиотеку libpri, а затем перекомпилируйте Asterisk.

Дополнительно, вводится термин LTS (Long Term Support). При создании ветки в репозитории, она будет помечаться либо как стандартная, либо как LTS. Основное отличие между LTS и стандартными релизами – время в течении которого в них принимаются исправления. Для стандартного релиза это 1 год на общие исправления и 1 год на исправления связанные с безопасностью – всего 2 года. Для LTS, это 4 года на общие и 1 год на безопасность итого 5 лет.

На данный момент как LTS помечены ветки 1.4 и грядущая 1.8. Таким образом, поддержка веток 1.6.х закончится уже в этом году (2010-04-01 для 1.6.0 и 1.6.2 для 2010-12-18) – раньше, чем поддержка ветки 1.4 (2010-12-23).

Первые беты/кандидаты в релиз Asterisk 1.8 появятся во втором квартале этого года. Вот некоторые новшества которые нас ждут:

• Поддержка SRTP (шифрованного RTP) в chan_sip
• Поддержка технологии PacketCable NCS 1.0 в chan_mgcp для совместимости с сетями Docsis/Eurodocsis.
• Новые опции для chan_spy, такие как:
  • c() – позволит указывать DTMF с помощью которого перебираются активные каналы.
  • x() – позволит указывать DTMF используемый для выхода.
  • S – заставит автоматически выходить из приложения, когда перебраны все активные каналы.
  • E – прикрепляет прослушивание к конкретному каналу, и завершает приложение вместе с окончанием разговора по каналу.
• MeetMe – автоматически включает функцию DENOISE() для каждого участника.
• CEL (Channel Event Logging) – новая подсистема логирования событий в канале. Данная подсистема предназначена для качественного биллинга сложных звонков (коллцентры, несколько трансферов и т.д.)
• Новый набор модулей для работы с календарём. Позволит читать и писать данные в календарь, строить сложные диалпланы, зависимые от календаря.
• Поддержка multicast для передачи RTP.
• В app_queue теперь можно будет указывать место в очереди на которое поподает звонящий.
• Информация об участниках звонка, теперь может изменяться в ходе звонка. Это будет полезно для сложных звонков с переадресацией или трансфером.

Обещанные новшества, как всегда, выглядят очень заманчиво. Остаётся лишь надеяться, что качество ветки 1.8 будет намного выше качества веток 1.6.Х.

Лично для меня, сегодня существует 3 ключевые проблемы в ветке 1.6.0 (срез за декабрь 2009 – февраль 2010), не позволяющие использовать её промышленно.

• Issue #16608 – Под большой нагрузкой (~150) звонков, Asterisk лочится. Подобное поведение, на мой взгляд, худшая из возможных проблем. Вылавливать подобные ошибки гораздо сложнее сегфолтов, кроме того, их невозможно моментально обнаружить, по этому клиенты испытывают перерывы связи до пары минут.
• Несовместимость T.38 с Mera. Во второй половине 2009 года, над стеком T.38 в Asterisk была проделана большая работа, направленная на повышение совместимости, однако результат, на мой взгляд, оказался противоположным. Возможно, виновата сама Mera, т.к. она не шлёт заголовок T38MaxBitRate, тем не менее эта же Mera (Mera DAMOS 1.3.2.20 – 1.3.2.40) Корректно работает со срезом Asterisk 1.6.0 за февраль – апрель 2009 года.
• Сегфолты на некоторых факсах. Происходят не часто – пару раз в неделю при большой нагрузке. Вероятней всего сегфолты, это ещё одно следствие перетрубаций со стеком T.38.

Таким образом, текущий срез ветки 1.6.0 серьёзно уступает транку времён Asterisk 1.4, тогда можно было смело брать trunk для production. Сейчас надо очень тщательно выбирать даже из версий ветки 1.6.0, что уж говорить про 1.6.1 и 1.6.2. Судя по всему, понимают сложившуюся ситуацию и в Digium, недавно было объявлено, об очередном изменении политики релизов. Но об этом в следующей заметке

Цена размещения Вашего продукта на год, в каталоге AsteriskExchange составляет 5000$. При размещении нескольких продуктов Digium обещает скидку. ПО с открытым кодом размещаются бесплатно (после одобрения Digium-ом). Это даёт возможность маленьким компаниям, бесплатно разместить ссылку на свой сайт рядом с такими грандами как IBM, Polycom, Aastra, Audiocodes, Dialogic и другими, уже присутствующими в каталоге AsteriskExchange. Правда взамен придётся изобрести и поддерживать какой-нибудь OpenSource проект.

Так же объявлено большое количество дополнительных услуг. Среди них такие как: размещение банеров в различных местах сайта AsteriskExchange, передвижение продукта вверх по каталогу и сертификация продукта на работоспособность с Asterisk. Сертификация, вероятно, будет самой дорогой из дополнительных услуг. Производители прошедшие сертификацию получат право на пользование торговыми марками Asterisk и Digium в своих рекламных компаниях. Цены на дополнительные услуги пока не сообщаются.