Встраивание Asterisk в другие системы

Skip to end of metadata
Go to start of metadata

Встраивание Asterisk в другие системы

Использование .conf файлов

Asterisk - это система, реализующая широкий набор телефонных функций-примитивов, и предоставляющая гибкие интерфейсы для управления ими из других приложений. Это позволяет встраивать Asterisk в различные сложные системы, в которых необходим прием и осуществление звонков. Конфигурация Asterisk представляет собой реализацию телефонной бизнес-логики определенной системы (бизнес-требований). Например, требование записи всех входящих звонков, идущих на пользователя с номером 123, должно быть преобразовано в различные разделы разных конфигурационных файлов, а именно - мы должны определить пользователя в файле sip.conf, номер в файле extensions.conf, и написать план набора на языке AEL, который будет вызывать приложение Monitor для записи разговоров. Таким образом, мы как бы надстраиваемся над Asterisk для реализации нашей бизнес-логики.

Однако, надстройка над .conf файлами имеет ряд недостатков. Назовем некоторые из них:

  • Классически основная бизнес-логика приложения реализуется на уровне базы данных в виде набора сущностей и взаимосвязей между ними. Поэтому было бы очень удобно иметь возможность определения бизнес-логики всех компонентов в едином месте, а именно в базе данных, включая и asterisk.
  • Работа с .conf файлами требует либо "ручной" настройки администратором, либо создания дополнительного промежуточного приложения, которое будет преобразовывать запросы на чтение/изменение конфигурации в чтение/запись файлов. Использование администратора сильно затрудняет автоматизацию, а написание дополнительного компонента требует доп. затрат на разработку промежуточного ПО, которое не такое простое как может показаться на первый взгляд, так как данное ПО будет решать вопросы аутентификации и авторизации (что уже есть часть бизнес-логики), проблемы одновременного доступа.
  • Изменения в конфигурациооных файлах тербует перезагрузки конфигурации всей системы или отдельно модуля (sip reload, reload, extentions reload, etc). Это может оказаться неприемлимым при большом количестве изменений. Пример тому
    - система, обслуживающая десятки тысяч пользователей. Изменение SIP пароля потребует вызова sip reload. Конечно же, можно ставить в очередь запросы на перезагрузку конфигурации, чтобы исключить возможные проблемы, однако это уже не система реального времени.

Несмотря на трудности, использование .conf файлов имеет один очень большой плюс - нет никаких ограничений. Можно привести следующую аналогию. В Windows можно сделать только то, что предусмотрели программисты Microsoft и вписали в меню окон. В UNIX можно из тысяч комманд shell собрать приложение любой функциональной сложности.

Таким образом, использование .conf файлов для хранения конфигурации - вполне рабочее решение.

Конфигурация из базы данных

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

  • Упрощение архитектуры - сервер Asterisk "голый", на нем нет никаких доп. приложений, операций чтения/записи конфигурации, база в другом месте, доступ к базе по сети, в базе все правила.

Однако есть также и ряд отрицательных сторон.

  • Чрезмерная нагрузка на базу. Например, realtime sip для каждой новой регистрации, при каждом звонке вызывает запрос к базе данных для определения адреса пользователя (SELECT ipaddr FROM sip_peers WHERE name='vasea_pupkin'). В случае использования sip.conf Asterisk держит всю информацию о пользователе во внутренних структурах данных.
  • Вопросы безопасности. Некоторые администраторы баз данных жестко контролируют даже физическую возможность подключения к базе. Такие одминистраторы будут против того, чтобы система Asterisk подключалась к внутренней базе данных. Однако, при правильном подходе, а именно тонкой подстройке прав, можно решить эту проблему. Например, позводлив астериску "видеть" только свои таблицы в базе данных.

Asterisk поддерживает два принципиально отличающихся способа (engine) чтения конфигурации из базы данных.

  • Realtime.
  • Static.

Realtime

Static

Заключение

Итак, архитектор любого проекта с использованием Asterisk должен решить вопрос о применении одной из 3-х нижеследующих технологий хранения конфигурации:

  • .conf файлы
  • Realtime
  • Static
    Они не являются взаимоисключющими и могут сочетаться в любом виде. Например, данные о пользователях (пирах) могут храниться в realtime, конфигурация ISDN PRI соединения в .conf файлах, настройки очередей в Static.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.