Было решено заменить систему на дистрибутив Askozia, который так же как Astlinux можно штатно установить на Disk on Module, а так же поддерживает из коробки ISDN BRI адаптеры на базе HFC чипа.

Вся операция заняла около часа. Дольше всего занял бэкап DoM на компьютере с Windows, для чего заранее подготовленные утилиты не подошли, был найден и использован аналог утилиты dd для windows.

Запись образа с помощью physdiskwriter и запуск системы прошел без проблем. Приятно что DAHDI работает с платами на HFC чипе штатно, а Askozia не подвела и настроила плату двумя кликами. Все настройки понятны и вопросов не вызывают.

Одна особенность настройки, однако, присутствовала. При входящем вызове клиенту должно зачитываться сообщение после нескольких попыток вызова на телефон оператора. В качестве приложения был использован примерно следующий диал план:

1, Dial (SIP/101&SIP/102,8,t)
2,Answer ()
3,Playback (welcome)
4,Goto (internal,200,1)

Где 200 — номер группы вызова, настроенной внутри askozia. Однако в такой ситуации происходило странное — если оператор принимал вызов до проигрывания приветствия, то после того как трубка была положена вызов от этого номера приходил снова.

Причина оказалась проста, на основе написанного в вебе диалплана, в диалплане создавалась запись вида:

_[a-zA-z0-9],1, Dial (SIP/101&SIP/102,8,t)

При завершении вызова происходил переход на h экстенжен, который не определен отдельно, а подпадает под определенный шаблон, поэтому вызов повторно возвращался в определенный диалплан. После того как проблема найдена её просто исправить добавлением одной строки в начало определенного уже приложения:

1, ExecIf ($["${EXTEN}" = "h"]?Hangup ())

Результат изысканий: load average меньше 20, загрузка процессора и использование памяти так же сократились. И это благодаря опциям компилятора.

Ради интереса решил посмотреть, можно ли улучшить ситуацию оптимизировав сборку астериска. В результате в нижиприведенные строки были прописаны следующие значения:

Makefile:

DEBUG=-g0

Makefile.rules:

OPTIMIZE?=-O2

Первое отключает добавление отладочной информации в модули. По-умолчанию в модули добавляется информация для отладки, что увеличивает размер исполняемых файлов и модулей.

Второе — переключает режим оптимизации (важно для gcc4). В gcc3 второе действие не обязательно и может наоборот замедлить работу. В gcc4 максимальный уровень оптимизации излишне увеличивает размер файлов и чаще всего вызывает существенное замедление их выполнения.

На просторах интернета информации не так много, есть лишь несколько утилит предназначенных для внесение изменений в .pcap файлы. Я использовал утилиту bittwiste проекта Bit-Twist. Проект предназначен для отправки трафика записанного в файле в реальную сеть используя libpcap.

Меня интересовало исправление единственного пакета, который нужно было сформировать. Записав трейс вызова к серверу, который передает CNG пакеты, смотрим номер пакета в дампе — в моем случае он номер 142. Извлекаем пакет (то же можно сделать из wireshark):

bittwiste -I /home/igorg/original.cap -R 142 -O /rtp-cng.cap

Моя задача была добавить дополнительный объем полезной нагрузки в CNG пакет. Если использовать для этого HEX редактор, придется  исправлять поля IP и UDP заголовков, а так же служебную информацию в pcap файле. Здесь и пригодится bittwiste — утилита позволяет вставить в пакеты в .pcap файле произвольную информацию.

Через wireshark смотрим в шестнадцатеричном формате данные RTP пакета (они начинаются после контрольной суммы UDP пакета), выписываем в строку, добавляем произвольное количество нужных данных. При вызове bittwiste используем параметры -L 4 -T udp, чтобы переписать данные в UDP пакете, следующие после UDP заголовка.

bittwiste -I /rtp-cng.cap -X 800dce3117850593f60538ea4751a2728c8c8c8c8c8c00 -O /rtp-cng-long.cap -L 4 -T udp

В результате получен модифицированный пакет, который можно использовать в дальнейших экспериментах. По похожей схеме возможно создавать пакеты, позволяющие повторить ту или иную уязвимость в ПО. Желаю удачи в изысканиях и экспериментах!

Действия:

1. Устанавливаем chan_skype, как описано во всех мануалах. В качестве контекста в chan_skype.conf указываем from-trunk, экстенжен — имя пользователя Skype. Теперь можно используя это имя пользователя как DID маршрутизировать вызовы в Inbound Routes
2. Создаем два внутренних номера. Один — SIP (например: 101). Второй — Other (Custom) Device (201), в поле dial указывается строка вызова абонента через Skype — Skype/user_to_call
3. Модуль FollowMe позволяет осуществить поиск сотрудника по нескольким номерам с последующим переходам в голосовую почту. Выбираем абонента с номером 101, добавляем в список поиска номер 201 и сохраняем правило. Теперь при вызове на 101 будет происходить поиск сотрудника и в Skype сети.

Стоит заметить что в последней версии chan_skype была добавлена поддержка приложения Transfer (), что позволит оптимизировать использование Skype лицензий в такой схеме. Для этого вызов Skype абонента должен происходить через chan_local, где проверяются несколько условий:

1. Исходный вызов поступил из Skype канала
2. Вызываемый Skype абонент доступен
3. При соблюдении обоих условий вместо Dial () используем Transfer () для прямого соединения двух Skype пользователей

relocation error: /usr/lib/odbc/libmyodbc.so: symbol mysql_odbc_escape_string, version libmysqlclient_15 not defined in file libmysqlclient_r.so.15 with link time reference

Сообщение появляется при любой попытки обращения к ODBC, вызывает аварийное завершение приложения. В случае с астериском его можно увидеть только запустив приложение непосредственно из консоли, не используя режима демона. При падении core файл не создается.

Причина заключается в том, что при очередном обновлении системы устанавливается обновление для libmysqlclient, несовместимое с libmyodbc. Решением является удалить из системы пакет libmyodbc, поставляемый в дистрибутиве и скачать последнюю версию с сайта MySQL. распаковать и разместить в прежнем месте, либо исправить путь к драйверу в /etc/odbcinst.ini

Я наблюдал этот эффект при работе Asterisk 1.2 со станцией Avaya Definity.