Система Asterisk

Глава 1 из книги "Архитектура приложений с открытым исходным кодом", том 1.

Оригинал: Asterisk, глава из книги "The Architecture of Open Source Applications" том 1.
Автор: Russell Bryant
Перевод: Н.Ромоданов

1.4. Сценарии вызовов

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

1.4.1. Проверка голосовой почты

Одним из типичных сценариев является ситуация, когда некто звонит для того, чтобы проверить свою голосовую почту. Первым компонентом, которые участвует в этом сценарии, является драйвер канала. Драйвер будет ответственен за обработку входящего вызова, который появится в потоке мониторинга в драйвере канала. Это вызов может настраиваться по-разному в зависимости от технологии, используемой для пересылки вызова в систему. Следующим шагом настройки вызова является определение, кому отправляется вызов. Это обычно осуществляется по номеру, который набирает вызывающий. Однако, в некоторых случаях в наличии нет никакого конкретного номера, поскольку в технологии, используемой для пересылки вызова, нет спецификации, связанной с набранным номером. Примером этого может быть входящий вызов, поступающий по аналоговой телефонной линии.

Если драйвер канала определит, что для набранного номера в конфигурации Asterisk заданы расширения, определенные в dialplan-е (конфигурация маршрутизации вызова), то он создаст объект канала Asterisk (ast_channel) и создаст канальный поток. На этот канальный поток будет возложена основная обязанность обработки остальной части вызова (рис.1.5).

Рис.1.5.: Диаграмма последовательности настройки вызова

Главный цикл канального потока осуществляет выполнение dialplan-а. Он следует правилам, определенным для набранного расширения, и выполняет шаги, которые в них определены. Ниже приведен пример расширения, записанного в синтаксисе extensions.conf. В этом расширении указывается, что нужно ответить на вызов и, если кто-нибудь наберет номер *123, выполнить приложение VoicemailMain. Это то приложение, которое вызывается пользователем для проверки сообщений, оставшихся в голосовой почте.

exten => *123,1,Answer()
    same => n,VoicemailMain()

Когда канальный поток выполнит приложение Answer, Asterisk ответит на входящий вызов. Ответ на вызов требует специальной технологической обработки, поэтому в добавок к некоторой общей обработке ответа также вызывается функция обратного вызова answer, находящаяся в ассоциированной структуре ast_channel\tech, которая будет обрабатывать вызов. При этом может происходить отсылка по сети специального пакета поверх сети IP, сообщающего, что в аналоговой линии нужно снять трубку и т.д.

Следующим шагом для канального потока будет выполнение приложения VoicemailMain (рис.1.6). Это приложение предоставляется в виде модуля app_voicemail. Следует заметить, что хотя приложение Voicemail выполняет большой объем работы, необходимый при взаимодействии с вызовами, в нем ничего не известно о технологии, используемой для передачи вызова в систему Asterisk. Абстракция канала The Asterisk скрывает эти особенности от реализации приложения голосовой почты.

Есть целый ряд возможностей, которые предоставляются обратившемуся к своей голосовой почте. Однако все они, прежде всего, реализованы как операции чтения и записи звуковых файлов, выполняемые в ответ на ввод команд, поступающих от звонящего, которые, в основном, являются нажатием клавиш с цифрами. Сигналы о нажатия клавиш могут поступать в Asterisk различными способами. Но опять, с этими особенностями справляются драйверы каналов. Как только нажатие клавиши поступает в систему Asterisk, оно конвертируется в обобщенное событие о нажатии клавиши и передается в код приложения Voicemail.

Одним из важных интерфейсов в системе Asterisk, который мы уже рассматривали, является транслятор кодеков. Такие реализации кодеков важны для данного сценария вызова. Когда в коде голосовой почты потребуется вызывающему воспроизвести звуковой файл, аудиоформат в звуковом файле может не совпасть с аудиоформатом, используемым при коммуникации между системой Asterisk и вызывающим. Если потребуется преобразовать аудиоформат, то для того, чтобы из исходного формата получить целевой формат, будет создан последовательность преобразований (translation path), состоящая из одного или нескольких трансляторов кодеков.

Рис.1.6: Вызов приложения голосовой почты VoicemailMain

В некоторый момент вызывающий завершит свое общение с системой голосовой почты и повесит трубку. Драйвер канала обнаружит, что это произошло, и преобразует это событие в обобщенное сигнальное событие канала Asterisk. Код приложения Voicemail получит это сигнальное событие и закончит свое выполнение. Управление будет возвращено в основной цикл в канальном потоке, в результате чего можно будет продолжить выполнение dialplan-а. Поскольку в этом примере в dialplan-е нет ничего, что нужно обрабатывать, драйвер канала получит возможность специальный образом, зависящим от используемой технологии, обработать шаг отключения вызова, после чего объект ast_channel будет уничтожен.

1.4.2. Вызов с созданием «моста»

Еще одним довольно общим сценарием вызовов в системе Asterisk является вызов с созданием «моста» между двумя каналами. Это сценарий, когда один телефон через систему вызывает другой телефон. Первоначальный этап процесса настройки вызова аналогичен тому, который был рассмотрен в предыдущем примере. Отличия в обработке начинаются после того, как вызов был настроен и канальный поток начинает выполнение dialplan-а.

Следующий dialplan является простым примером, результатом выполнения которого будет вызов с использованием соединения типа «мост». Когда на телефоне будет набран номер 1234, то при использовании данного расширения dialplan выполнит приложение Dial, которое является основным приложением, используемым для инициации исходящего вызова.

exten => 1234,1,Dial(SIP/bob)

Аргумент, указываемый в приложении Dial, сообщает, что система должна создать исходящий вызов на устройство, обозначаемое как SIP/bob. Часть SIP этого аргумента указывает, что для доставки данного вызова должен использоваться протокол SIP. bob будет проинтерпретировано драйвером канала, который должен реализовывать протокол SIP, т.е. chan_sip. Если предположить, что в драйвере канала был должным образом сконфигурирован аккаунт с именем bob, то будет известно, как можно будет получить доступ к телефону Боба.

Приложение Dial запросит базовую часть системы Asterisk выделить новый канал, использующий идентификатор SIP/bob. Базовая часть запросит драйвер канала SIP выполнить специальную инициализацию, соответствующую данной технологии. Драйвер канала также инициирует процесс дозвона до телефона. Как только придет ответ на этот вызов, драйвер передаст события обратно в базовую часть Asterisk, которые будут приняты приложением Dial. Эти события могут говорить о том, что поступил ответ на вызов, что направление занято, что сеть перегружена, что вызов был отклонен по некоторой причине или о ряде других событий. В идеальном случае будет получен ответ на вызов. Тот факт, что на вызов был получен ответ, вернется обратно во входящий канал. Asterisk не ответит на входящий вызов до тех пор, пока не на исходящий вызов не поступит ответ. Ка только оба канала ответят на вызов, между ними будет установлено соединение типа «мост» (рис.1.7).

Рис.1.7: Блок-схема мостового вызова внутри обобщенной абстракции типа «мост»

Когда через мост произойдет соединения каналов, аудиопоток и сигнальные события будут передаваться между каналами до тех пор, пока не возникнет некоторое событие, ведущее к разрыву мостового соединения, например, когда на одной стороне повесят трубку. На рис.1.8 приведена диаграмма, демонстрирующая ключевые операции, выполняемые с аудиофреймом при использовании соединения типа «мост».

Рис.1.8: Диаграмма последовательности действий при обработке аудио фрейма для соединения типа «мост»

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

1.5. Заключительные комментарии

Архитектуре системы Asterisk в настоящее время уже больше десяти лет. Однако фундаментальные концепции каналов и гибкой обработки вызовов, используемых в dialplan-е системы Asteris, по-прежнему позволяют поддерживать разработку сложных систем телефонии в отрасли, которая постоянно развивается. Одной из областей, с которой архитектура системы Asterisk не может достаточно хорошо справиться, является масштабирование системы на нескольких серверах. Сообщество разработки Asterisk разрабатывает в настоящее время сопутствующий проект, который называется Asterisk SCF (Scalable Communications Framework — Масштабируемый коммуникационный фреймворк), предназначенный для решения этих проблем масштабируемости. В ближайшие несколько лет мы ожидаем увидеть, что система Asterisk вместе с системой Asterisk SCF будет продолжать занимать все большую часть рынка телефонии, в том числе в области крупных систем.

Примечания

---

К началу статьи.

---

---