Системы связи на базе ПО Asterisk

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

Рисунок 5 Архитектура Asterisk

 

 

 

 

 

2.3 Выбор оборудования

 

 

2.3.1 Серверное оборудование

 

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

Для больших установок Asterisk функциональность обычно распределяют между несколькими серверами. Один или более центральных модулей будут заниматься обработкой вызовов; их дополнят один или более вспомогательных серверов, обслуживающих периферийные устройства (такие, как система баз данных, система голосовой почты, система конференц-связи, система управления, веб-интерфейс, межсетевой экран и т. д.). Asterisk, как и многие Linux-системы, может расширяться с ростом требований к ней: малая система, которая прекрасно справлялась со всеми задачами по обработке вызовов и обслуживанию периферийных устройств, может быть распределена между несколькими серверами, когда требования возрастут и превысят ее текущие возможности. Гибкость – основная причина, по которой Asterisk исключительно рентабельна для быстро растущего бизнеса; для нее не существует эффективного максимального или минимального размера, который следует учитывать при составлении сметы на покупку.

В табл. 2.1 представлены некоторые основные рекомендации к планированию системы.

 

Назначение	Количество каналов	Рекомендуемые минимальные параметры
Любительская система	Не более 5	400 МГц ×86, 256 Mб  оперативной памяти
SOHO-система (малый офис  и дом – менее трех линий  и пяти телефонных аппаратов)	От 5 до 10	1 ГГц ×86, 512 Mб  оперативной памяти
Малая бизнес-система	До 25	3 ГГц ×86, 1 Гб оперативной  памяти
Средняя или большая  система	Более 25	Два ЦП, возможно также  несколько серверов в распределенной архитектуре

Таблица 2.1 – Рекомендации по выбору технических характеристик системы

 

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

 

2.3.2 Оборудование для телефонии

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

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

Интерфейс PSTN, скорее всего (если не требуется  обеспечение многоканальной линии  или нет денег на то, чтобы каждый месяц менять телекоммуникационное оборудование), будет состоять из одной или более аналоговых схем, для каждой из которых потребуется порт FXO.

Если требуется более 10 телефонных линий или обеспечение возможности  подключения к цифровым линиям, используются платы T1 или E11. Однако не стоит забывать, что ежемесячные расходы на обслуживание цифровых PSTN-линий варьируются в широких пределах. В некоторых регионах окупаемость будет обеспечена всего пятью линиями; в других эта технология может вообще не быть экономически эффективной.

Банк каналов обеспечивает возможность объединять аналоговые телефоны и линии в систему через линию T1.

Несмотря на дороговизну, многие считают, что использование банка каналов  – это единственно правильный способ объединения аналоговых линий  и устройств с Asterisk. Для подключения банка каналов к Asterisk понадобится плата T1.                                                                                                                                

 

 

2.4 Примеры Asterisk топологий

 

Asterisk обладает чрезвычайной гибкостью  при построении сети, но вероятно, полезно представить несколько примеров сетевых графиков. На следующих рисунках мы можем наблюдать некоторые схемы Asterisk топологий. На первом рисунке изображена простейшая мини-АТС с Asterisk. Она состоит из одного порта PSTN, одного аналогового порта и IP-телефона. Такая АТС может обеспечивать голосовую почту, использоваться в качестве шлюза или выполнять некоторые базовые IVR сценарии.

 

Рисунок 6 Простейшая мини-АТС с Asterisk

 

Более типичным сценарием в офисе является внедрение Asterisk в уже существующую телефонную сеть. На следующем рисунке восемь телефонных линий и 16 аналоговых телефонов подключены к банку каналов с интерфейсом E1, который, в свою очередь, подключен к компьютеру под управлением Asterisk. Кроме того, VoIP-телефоны могут быть подключены через Ethernet, увеличив число телефонов, которые могут быть использованы. Даже с такой сравнительно небольшой установкой, вы можете пользоваться преимуществами конференц-связи, голосовой почты, возможностью проверить голосовую почту через Интернет, реализовать пользовательские IVR сценарии и многие другие функции.                                                                                                                                                                                                 

Рисунок 7 Asterisk в уже существующей телефонной сети

 

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

Рисунок 8 Организация связи между удаленными офисами

 

2.5 Соединение двух серверов Asterisk

 

Для связи двух серверов Asterisk между  собой можно использовать протоколы IAX, SIP или H.323, однако, использование IAX протокола - это самый простой  путь для решение этой задачи. Для создания общего плана набора можно использовать следующие рекомендации:

• Спроектировать план набора для каждого сервера, чтобы было сразу понятно, какому из серверов принадлежит то или иное приложение, при наборе номера на любом из серверов. Например, использовать номера 3xxx для сервера A, 4xxx - для сервера B и 5xxx - для номеров приложений, подключенных к серверу C.
• Использовать директиву "switch", для того, чтобы сервер A искал на сервере B те приложения, которые не известны на сервера A (оба сервера должны всегда быть в рабочем состоянии и доступны, иначе будут присутствовать большие задержки между моментом набором номера и какой-либо реакции на это действие)
• Можно использовать DUNDILOOKUP: Distributed Universal Number Directory (DUNDi)
• Можно использовать ENUMLOOKUP (e.164)

ITU определил план нумерации  в своей спецификации E.164. До появления общедоступного VoIP никто не заботился о E.164, кроме телефонных компаний. В этом просто не было необходимости.

Теперь, когда звонки путешествуют из PSTN в Интернет и бог знает  куда еще, на E.164 необходимо обратить внимание.

В ответна эту проблему IETF профинансировал  рабочую группу по разработке протокола  отображения телефонных номеров Telephone Number Mapping (ENUM), целью которой было объединение номеров E.164 со службой  доменных имен (Domain Name System, DNS). Идея ENUM разумна, но для достижения успеха необходима поддержка со стороны телекоммуникационной отрасли. Однако желание сотрудничать никогда не входило в число добродетелей этой отрасли, поэтому проект ENUM потерпел неудачу.

DUNDi – это одноранговая система  для поиска интернет-шлюзов в  сервисы телефонии. В отличие  от традиционных централизованных  сервисов (таких, как необыкновенно  простой и лаконичный стандарт ENUM), DUNDi является полностью распределенным  и вообще не имеет никакой централизованной службы». DUNDi – это в некотором роде протокол маршрутизации для VoIP.

DUNDi можно рассматривать как  большую телефонную книгу, которая  позволяет запрашивать у равноправных  участников сети альтернативный VoIP-маршрут к добавочному номеру или телефонному номеру PSTN.

DUNDi-протокол может использоваться  и в локальной сети. Скажем, вы  администратор системы Asterisk в  очень большой корпорации и  желаете упростить процесс управления  добавочными номерами. В этой  ситуации мог бы использоваться DUNDi, обеспечивая возможность нескольким серверам Asterisk (предположительно расположенным в разных офисах компании и объединенным в одноранговую сеть) выполнять динамические поиски VoIP-адресов добавочных номеров в сети.

 

2.5.1 Метод с использованием SIP протокола

 

Рассмотрим некоторые популярные случаи:

• Сервер A - имеет статический IP адрес, сервер B - динамический IP адрес. Для сервера B нужно настроить регистрацию на сервере A.
• Оба сервера имеют статические IP адреса. В этом случае регистрация не нужна.
• Оба сервера имеют динамические IP адресацию. Можно воспользоваться динамическим DNS сервисом, например, dyndns.org, для регистрации каждого сервера на другом. В любом случае, это не самое удачное решение, использовать динамические адреса для обоих серверов, т.к. при смене IP адреса, соединение может быть потеряно, до тех пор пока информация не обновиться на динамическом DNS сервере.
• Оба сервера имеют доступ друг к другу через NAT. Рекомендуется использовать протокол IAX2.

 
2.5.2 Настройка IAX канала

 
  При использовании соединения по протоколу IAX между двумя серверами Asterisk, настройка состоит из следующих шагов:

• Настроить Asterisk сервера с обеих сторон в файле конфигурации in iax.conf, один, как peer, а другой - как user.
• Настроить план набора в файле extensions.conf для сервера с пользователем типом user так, чтобы можно было принимать вызовы с другова сервера от пользователя с типом peer.
• Не обязательно, зарегистрировать пользователя с типом peer, на сервере с пользователем типом user (для случаев, когда, например, сервер с пользователем типа peer имеет динамический ip адрес, который неизвестен второй стороне.)
• Повторить вышеуказанные шаги, поменяв местами сервер A и B (добавив пользователей, поменяв местами тип peer и user), если вы необходимо совершать вызовы в обоих направлениях.

 

2.6 Отказоустойчивый кластер для Asterisk

 

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

Рассмотрим варианты действий при решении проблемы:

• Замена системы  (например, по гарантии). Время на процесс замены и повторной настройки может составить от суток до нескольких недель, в зависимости от доступности оборудования и наличия резервных копий конфигурации. Также теряются данные с момента последнего копирования.
• Установка системы из резервной копии (на заранее приобретенное оборудование). Время восстановления составит от часа до суток. Данные с момента снятия последней копии также теряются.
• Внедрение HA-кластера. Время простоя составит от нескольких секунд до минуты с минимальным риском потери данных. Для критичных систем рекомендуется именно такой метод упреждающего решения проблемы.

Рисунок 9 Логическая схема построения HA-кластера для Asterisk

 

Реализация механизма отказоустойчивости в рассматриваемом решении выглядит следующим образом.

• Устанавливается два идентичных сервера, один из которых объявляется основным, а другой - резервным. Основной сервер обеспечивает необходимую полезную функциональность (обслуживание приложений телефонии). Резервный сервер должен принять на себя задачи основного в случае выхода того из строя.
• Для обеспечения синхронизации содержимого дисковой подсистемы серверов применяется технология DRBD, обеспечивающая репликацию данных через локальную сеть. Для повышения надежности используется резервирование сетевых интерфейсов (ethernet bonding).
• На всех узлах кластера устанавливается приложение heartbeat из пакета приложений Linux-HA, которая обеспечивает взаимный мониторинг компонент платформы и, в случае выхода из строя основного сервера, запуск всех программных компонент на резервном сервере.
• Для прозрачного переключения на сервере, активном в настоящий момент, используется единый IP-адрес, по которому функции сервера (VoIP-платформа) доступны для внешних приложений.

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

Подобная схема обеспечения  отказоустойчивости при выполнении основных требований к окружению (продуманная  топология IP-сети, резервирование электропитания и т.п.) может обеспечивать надежность на уровне 99,99% без применения какого-либо специализированного дорогостоящего оборкдования.