FreeSWITCH users via LDAP

Потребовалось авторизовать пользователей FreeSWITCH через LDAP вместо XML Directory. Оба имевшихся в комплекте модуля оказались со странностями:

• mod_ldap вообще не похож на рабочий, код просто недописан
• mod_xml_ldap пытается быть слишком универсальным и предполагает использование собственной схемы, в которой для одного пользователя предполагается иметь по записи для каждого параметра вместо очевидного, казалось бы, решения - добывать необходимую для авторизации информацию прямо из имеющихся атрибутов записей с objectClass=person

Впрочем, у FreeSWITCH есть универсальное решение для 99% интеграционных задач - mod_xml_curl + внешний HTTP-сервер (или один из поддерживаемых встраиваемых скриптовых языков). Беда в том, что это решение затягивает. Меня затянуло до встраивания LDAP-сервера :).

Затем я пришел в себя и решил все же еще раз вчитаться в код нативных модулей и исправить/переписать тот, который окажется более вменяемым. Все оказалось проще - второй модуль уже почти переписали и, видимо следуя общей традиции поддержки LDAP, таки бросили уже почти на финише.

Сделать последний шаг оказалось несложно. Оно работает, хотя и нуждается в более тщательном тестировании.

Король умер, да здравствует король ...

CallWeaver медленно, но верно впадает в анабиоз (критерий - количество новых коммитов в SVN), и потому я давно стал приискивать ему такую замену, которая не называется Asterisk.

Остановился в итоге на FreeSWITCH, который соблазнил меня:

• Красивой архитектурой с честной модульностью и возможностью масштабироваться от софтфона до софтсвитча
• Использованием уже зарекомендовавших себя свободных фреймворков (Apache Portable Runtime для обеспечения переностимости между различными платформами, SofiaSIP в качестве SIP-стека и т.д.)
• Конфигурацией в XML (по мне это значительно удобнее ini-файлов) с возможностью перечитывать фрагменты конфигурации с HTTP-сервера в процессе работы

Правда размер дефолтной конфигурации совершенно безумен, да сама она скорее сборник примеров, чем то, от чего можно отталкиваться в процессе настройки системы для промышленной эксплуатации. Поэтому по аналогии с CallWeaver я выпилил для себя минимально работоспособный вариант, который дальше по мере необходимости уже можно наращивать дополнительными возможностями. Хотел было даже подбить текущего майнтейнера FreeSWITCH в ALT Linux сделать этот вариант конфигурации одним из коробочных - да тот оказался слишком несговорчивым :(

Fax/SMTP gateway для CallWeaver

Задача: отправить факс путем отправки письма с вложенным ps/pdf/tif, принять факс в виде почтового сообщения с вложением. Инструменты - CallWeaver и какой-то враппер для ОGI и Manager API на Python, который я вовремя не опакетил, таская с собой, а теперь уж и забыл, откуда взял (да, я понимаю, что я неправ, но вот только сейчас руки дошли хотя бы до публикации решения). Архив со скриптами можно взять здесь.

Работает оно следующим образом. От локального отправителя письмо с вложением получает MTA и передает его на stdin скрипту fax-send.py. Скрипт делает из файла tiff и с помощью Originate коммутирует вызываемого внешнего абонента (контекст [call-fax-send], если не дозвонились, вызывается fail-fax.py) и факс(контекст [fax-send], о результате прохождения факса отправителю сообщает check-fax.py). Параметры передаются через Variable.

Упомянутые контексты описаны так:

[call-fax-send]
exten => 0,1,NoOp(Calling ${RECIPIENT} for sending fax)
exten => 0,2,Dial(SIP/${RECIPIENT}@${PEER},25)
exten => 0,3,NoOp(${DIALSTATUS})
exten => 0,4,DeadOGI(fail-fax.py)

[fax-send]
exten => 0,1,NoOp(Sending file ${FILE} as fax from ${SENDER} to ${RECIPIENT}@${PEER} with NOTIFY=${NOTIFY})
exten => 0,2,GotoIf($[${NOTIFY}=Yes]?3:6)
exten => 0,3,Playback(fax)
exten => 0,4,Playback(beep)
exten => 0,5,Wait(2)
exten => 0,6,Set(LOCALSTATIONID=CallWeaver)
exten => 0,7,Set(LOCALHEADERINFO=CallWeaver Fax)
exten => 0,8,TxFAX(${FILE})
exten => h,1,NoOp(RX: REMOTESTATIONID is ${REMOTESTATIONID})
exten => h,2,NoOp(RX: PHASEESTATUS is ${PHASEESTATUS})
exten => h,3,NoOp(RX: PHASEESTRING is ${PHASEESTRING})
exten => h,4,DeadOGI(check-fax.py)

Локальный же получатель факсов переадресует внешнего отправителя в контекст [fax-receive], там получившийся файл подбирает read-fax.py, он же сообщает о неудаче.

Контекст для приема факсов:

[fax-receive]
exten => _0.,1,Set(SENDER=${CALLERID(num)})
exten => _0.,2,Set(RECIPIENT=${EXTEN:1})
exten => _0.,3,Set(LOCALSTATIONID=Vertol EXPO)
exten => _0.,4,Set(LOCALHEADERINFO=Vertol EXPO Fax)
exten => _0.,5,Set(FILE=/data/callweaver/fax-receive/${UNIQUEID}.tif)
exten => _0.,6,RxFAX(${FILE})
exten => h,1,NoOp(RX: REMOTESTATIONID is ${REMOTESTATIONID})
exten => h,2,NoOp(RX: PHASEESTATUS is ${PHASEESTATUS})
exten => h,3,NoOp(RX: PHASEESTRING is ${PHASEESTRING})
exten => h,4,DeadOGI(read-fax.py)

Отлов исключений сделан только там, где без него совсем грустно (например, MTA лучше не знать, что внутри fax-send.py приключилось что-то нехорошее). В OGI невозможность удалить файл, например, ни к чему плохому не приводит.

Да, о поддержке факсов в CallWeaver читать здесь.

CallWeaver из коробки

В дополнение к предыдущему сообщению хочу добавить, что ALT Linux 4.0 Server Lite - один из немногих дистрибутивов, в которых CallWeaver работает практически из коробки и не слишком устарел (ну а если вдруг, то я его майнтейнер :) ). После установки достаточно, не вынимая установочного диска, сказать:

# apt-get install callweaver callweaver-sounds freemusic-signate

и прочесть файл /usr/share/doc/callweaver-1.2/QUICKSTART.ru_RU.UTF-8. Процитирую, пожалуй, его содержимое:

Введение
========

CallWeaver - это IP PBX, форк проекта Asterisk, причинами создания которого послужили 
организационные (зависимость от компании Digium, двойное лицензирование) и технические 
(зависимость от zaptel, отсутствие поддержки T.38 и т.д.) проблемы последнего. Подробнее - 
http://www.callweaver.org/wiki/CallWeaver


Описание конфигурации по умолчанию
==================================

CallWeaver реализован в виде загрузчика с минимальной функциональностью и набора модулей 
расположенных в каталоге /usr/lib/callweaver/modules, которые необходимо описать в файле 
modules.conf. В этом файле отключена автозагрузка модулей, а вместо этого явно указаны 
минимально необходимые модули.

Загрузка модуля chan_sip для поддержки протокола SIP по умолчанию закомментирована. 
При загрузке модуль chan_sip читает файл sip.conf, в котором описаны:

* общие настройки в секции [general]
* собственные абоненты в секциях [101] и [102]
* выход во внешний мир - параметры подключения к оператору sipnet.ru в секции [sipnet] 
и параметр register в секции [global] - в качестве {account} и {password} должны быть 
указаны реальные параметры, выданные оператором

Правила коммутации собственных абонентов друг с другом и с внешним миром описаны в файле 
extensions.conf. Правила оформляются в виде контестов, возможно использующих друг друга 
с помощью include. В контексте [local] описан вызов процедуры Hello с проигрыванием 
звукового файла (файлы находятся в пакете callweaver-sounds) при наборе 100 и вызов 
соответствующих внутренних абонентов при наборе 1ХХ (X - любая цифра от 0 до 9). 
Абоненты были предварительно описаны в файле sip.conf, и для них был указан контекст 
[office] - это значит, что им разрешено выполнять действия, описанные в этом контексте, 
т.е. во вложенном в него [local], а также набирать XXX. (. - любое количество любых 
цифр) - при этом вызов будет выполняться c использованием [sipnet] из sip.conf. 
В контекст [incoming] на номер 100 (как указано в параметре register в sip.conf) 
поступают входящие вызова с sipnet.ru

Более сложные примеры настройки доступны в пакете callweaver-docs в каталоге samples.


Как подключиться и начать использовать CallWeaver
=================================================

В ALT Linux есть несколько софтфонов, поддерживающих протокол SIP, с помощью которых 
можно подключиться к CallWeaver - ekiga, twinkle, sflphone. Для подключения необходимо 
сначала раскомментировать загрузку модуля chan_sip в modules.conf и запустить CallWeaver 
с помощью service callweaver start. В софтфонах необходимо создать учетную запись, указав 
в качестве SIP Proxy адрес сервера с запущенным CallWeaver, а в качестве имени и пароля - 
параметры из секций [101] и [102] файла sip.conf. После этого с каждого софтфона можно будет 
набрать 100 и услышать звуковой файл или набрать 101 или 102 и услышать друг друга. Если 
настроено подключение к sipnet.ru, можно позвонить во внешний мир или принять вызов снаружи 
и проиграть для него звуковой файл.

Для наблюдения за работой CallWeaver можно подключится к его консоли с помощью callweaver_cli. 
То, что будет видно на консоли, нельзя протоколировать стандартным образом, но, поскольку 
для подключения к серверу CallWeaver используется UNIX-сокет, можно использовать конструкцию, 
подобную socat -u UNIX-CONNECT:/var/run/callweaver/callweaver.ctl STDOUT