Это рассылка для пользователей Asterisk с более чем десятью тысячами подписчиков. В ней формируется несколько сотен сообщений в день. Сюда можно обратиться за помощью, но все-таки присылайте свои вопросы только после того, как попробовали и не смогли найти ответ самостоятельно. Asterisk-BSD
Здесь высказываются члены сообщества, реализующие Asterisk под FreeBSD (и другие диалекты BSD).
Википедия об Asterisk
Раздел Википедии по Asterisk (который существует по большей части благодаря неутомимым усилиям Джеймса Томпсона (James Thompson) - спасибо тебе, Джеймс!) - источник просвещения и путаницы. Управляемое сообществом хранилище знаний по VoIP (http://www.voip-info.org) - это просто кладезь интереснейшей, содержательной и часто противоречивой информации по многим вопросам, Asterisk является лишь одним из них.
Поскольку документация по Asterisk составляет основную массу информации на данном веб-сайте и, вероятно, на нем содержится больше сведений об Asterisk, чем во всех остальных источниках, вместе взятых (за исключением архивов рассылок), обычно этот веб-сайт указывают как основной ресурс данных об Asterisk.
Каналы IRC
Сообщество разработчиков Asterisk поддерживает каналы ретрансляции интернет-чатов (Internet Relay Chat, IRC) на сайте irc.freenode.net. Самыми активными каналами являются #asterisk и #asterisk-dev. В целях защиты от спама теперь на обоих каналах требуется регистрация.
Группы пользователей Asterisk
На многих сайтах по всему миру одинокие пользователи Asterisk начинают осознавать, что в их городах есть и другие люди, разделяющие их пристрастие. Группы пользователей Asterisk (Asterisk User Groups,
AUGs) возникают повсюду. Хотя они никак официально не взаимосвязаны, обычно они дают ссылки на сайты друг друга и всегда рады любым новым членам. Введите в Google поисковые слова "Asterisk User Group", чтобы найти группу в своем регионе.
Проект создания документации Asterisk
Проект создания документации Asterisk (Asterisk Documentation Proj ect) начали осуществлять Лейф Мадсен и Джаред Смит, но в нем участвовали и другие члены сообщества.
Цель проекта - создание структурированного хранилища письменных источников по Asterisk. В противоположность гибкой и случайной природе Википедии, проект Docs направлен на формирование более узкоспециализированного подхода к различным связанным с Asterisk вопросам.
В рамках проекта Asterisk Docs, нацеленного на то, чтобы сделать документацию доступной в Сети, данная книга представлена на вебсайте http://www.asteriskdocs.org по лицензии Creative Commons.
Экономическое обоснование
Сегодня практически невозможно найти предприятие, которому не приходилось бы перестраиваться каждые несколько лет. Так же сложно найти компанию, которая может позволить себе заменять свою инфраструктуру связи при каждой смене курса. Современному бизнесу необходима предельная гибкость во всех используемых технологиях, включая телекоммуникацию.
В своей книге "Crossing the Chasm" (HarperBusiness) Джеффри Мур (Geoffrey Moore) говорит: "Идея того, что ценность системы будет раскрываться постепенно и не будет известна на момент установки, подразумевает, в свою очередь, что гибкость и приспособляемость продукта, так же как и постоянное обслуживание клиентов, должны быть основными критериями оценки при покупке любой системы". В частности, это означает, что истинная ценность технологии порой бывает неясна вплоть до ее развертывания.
Теперь вы можете оценить привлекательность системы, в основу которой положена концепция открытости и постоянного обновления.
Об этой книге
Итак, с чего начнем? Об Asterisk можно рассказать столько, что одной книги не хватит. Мы не собираемся здесь вдаваться во все тонкости, просто рассмотрим основы.
В главе 2 обсуждаются некоторые вопросы проектирования, которые следует учитывать при планировании телекоммуникационных систем. Большую часть данного материала можно пропустить и перейти прямо к установке, но эти идеи важно понимать тем, кто планирует вводить в эксплуатацию систему Asterisk.
Глава 3 посвящена тому, как получить, откомпилировать и установить Asterisk. В главе 4 речь идет об исходной конфигурации Asterisk. Здесь рассматриваются важные конфигурационные файлы, которые должны иметься для определения каналов и функций, доступных в конкретной системе. Этот материал подготовит почву для главы 5, где представлено сердце Asterisk - диалплан. Глава 6 ознакомит вас с некоторыми более сложными концепциями диалплана.
В главе 7 мы отдохнем от Asterisk и обсудим некоторые наиболее важные технологии, используемые в PSTN. В главе 8, посвященной действующим системам телефонии, мы, естественно, обсудим технологию передачи голоса по IP-протоколу.
В главе 9 представлен один из наиболее удивительных компонентов, шлюзовой интерфейс Asterisk (Asterisk Gateway Interface, AGI). Используя языки программирования Perl, PHP и Python, мы продемонстрируем, как можно использовать внешние программы для добавления в офисную АТС практически безграничных функциональных возможностей. В главе 14 кратко рассматриваются невероятные возможности и функции, составляющие феномен Asterisk. В завершение, глава 15 "заглядывает вперед", предсказывая будущее, в котором телефония с открытым исходным кодом полностью преображает отрасль, отчаянно нуждающуюся в революционных изменениях. Также в книге можно найти массу справочной информации, которая приводится в пяти приложениях.
Эта книга только закладывает основы, но на базе почерпнутых из нее знаний вы сможете прийти к пониманию концепции Asterisk, и кто знает, что вы тогда создадите.
Глава 2 Подготовка системы к установке Asterisk
Я очень рано понял, что когда-нибудь, где-то там за горизонтом, в некотором "идеальном" будущем, все необходимые функции обработки данных будут выполняться централизованно внутри компьютеров, что приведет к значительному удешевлению, а в некоторых случаях обесцениванию внешнего оборудования, необходимого для соединения с телекоммуникационными интерфейсами.
– Джим Диксон "The History of Zapata Telephony and How It Relates to the Asterisk PBX"
Вам, должно быть, уже не терпится настроить собственную систему Asterisk. Если вы планируете создать любительскую систему, то, пожалуй, можете перейти сразу к следующей главе и начать установку. Однако, если Asterisk развертывается для решения ответственных задач, необходимо сказать несколько слов о среде, в которой она будет выполняться. Будьте уверены, Asterisk - очень гибкое ПО и успешно устанавливается практически на любую платформу Linux, а также на несколько не-Linux платформ. Но в данной главе обсуждаются вопросы, знание ответов на которые вооружит вас пониманием того, в каком операционном окружении Asterisk будет действительно эффективно функционировать, и поможет создать надежную, хорошо спроектированную систему.
С точки зрения требований к ресурсам Asterisk подобна встроенным системам реального времени преимущественно тем, что она должна иметь приоритетный доступ к процессору и системным шинам. Поэтому крайне важно, чтобы все остальные функции системы, не связанные напрямую с задачами Asterisk по обработке вызовов, если таковые вообще выполняются, должны выполняться с более низким приоритетом. Для небольших и любительских систем это может и не представлять особой проблемы. Однако для высокопроизводительных систем недостаточная производительность будет вызывать проблемы с качеством аудиосигнала, получаемого пользователем, часто в виде эха, помех и т. п. Примерно так ведут себя устройства мобильной связи при выходе из зоны обслуживания, но здесь причина этих проблем другая. По мере увеличения нагрузки на систему будут возрастать сложности с обслуживанием соединений. Для офисной АТС подобная ситуация - настоящая катастрофа, поэтому в процессе выбора платформы требования к производительности должны быть решающим критерием. В табл. 2.1 представлены некоторые самые основные рекомендации к планированию системы. В следующем разделе подробно рассматриваются различные вопросы проектирования и реализации, связанные с производительностью системы.
Размер системы Asterisk на самом деле определяется не количеством пользователей или телефонных аппаратов, а, скорее, количеством одновременных вызовов, которые система должна будет поддерживать. Эти цифры очень приблизительны, поэтому экспериментируйте и выбирайте наиболее подходящий для себя вариант.
Таблица 2.1. Рекомендации по выбору технических характеристик системы
Назначение | Количество каналов | Рекомендуемые минимальные параметры |
Любительская система | Не более 5 | 400 МГц х86, 256 M6 оперативной памяти |
SOHO-система (малый офис и дом - менее трех линий и пяти телефонных аппаратов) | От 5 до 10 | 1 ГГц х86, 512 M6 оперативной памяти |
Малая бизнес-система | До 25 | 3 ГГц х86, 1 Гб оперативной памяти |
Средняя или большая система | Более 25 | Два ЦП, возможно также несколько серверов в распределенной архитектуре |
Результаты нагрузочного тестирования
Джошуа Колп (Joshua Colp) смог получить результаты, приведенные в табл. 2.2, используя процессор AMD Athlon64 X2 4200+ с 1 Гб оперативной памяти и жестким диском SATA емкостью 80 Гб и проводя тестирования по стандартному сценарию в приложении SIPp: простое установление соединения, воспроизведение аудиофайла (приложение Playback()) и некоторый небольшой период ожидания (Wait()). Обратите внимание на существенное снижение использования ресурсов ЦП при чтении данных из оперативной памяти по сравнению с чтением с жесткого диска. Это можно истолковать так, что ЦП ожидает данные, подлежащие обработке, перед передачей их в запрашивающий канал. Однако это всего лишь простой тест, и он никоим образом не отражает, какое количество вызовов сможет обрабатывать ваша система. Определить количество одновременных вызовов, которое может быть обработано при использовании конкретного диалплана и сочетания приложений, можно, только проведя нагрузочное тестирование системы.
Таблица 2.2. Пример результатов тестирования для стандартного сценария SIPp, использующего простые приложения Wait() и Playback(); SIPp отражает обратный медиа-поток Asterisk
Количество | 330 | 330 | 550 |
одновременных | |||
вызовов | |||
Использование | 149 | 14,8 | 57,6 |
ЦП, % | |||
Средняя нагрузка | 49 | 25 | 60 |
Запоминающее | Жесткий диск | ОЗУ | ОЗУ |
устройство |
Для больших установок Asterisk функциональность обычно распределяют между несколькими серверами. Один или более центральных модулей будут заниматься обработкой вызовов; их дополнят один или более вспомогательных серверов, обслуживающих периферийные устройства (такие, как система баз данных, система голосовой почты, система конференц-связи, система управления, веб-интерфейс, межсетевой экран и т. д.). Asterisk, как и многие Linux-системы, может расширяться с ростом требований к ней: малая система, которая прекрасно справлялась со всеми задачами по обработке вызовов и обслуживанию периферийных устройств, может быть распределена между несколькими серверами, когда требования возрастут и превысят ее текущие возможности. Гибкость - основная причина, по которой Asterisk исключительно рентабельна для быстро растущего бизнеса; для нее не существует эффективного максимального или минимального размера, который следует учитывать при составлении сметы на покупку. Хотя масштабируемость свойственна большинству телефонных систем, до сих пор нам не приходилось слышать о системе, которая была бы настолько же гибкой, как Asterisk. Однако стоит отметить, что задача по проектированию распределенных систем Asterisk не по зубам новичку в Asterisk.
Тем, кто намерен настраивать распределенную систему Asterisk, рекомендуется изучить протокол DUNDi, архитектуру реального времени Asterisk (Asterisk Realtime Architecture, ARA), func_odbc и другие имеющиеся в распоряжении инструменты для работы с базами данных. Это поможет научиться извлекать из логики диалплана необходимые вашей системе данные, которые будут использоваться системой Asterisk. Это делает возможным существование универсального множества логик диалплана, которое может использоваться во множестве блоков. Тогда для масштабирования системы необходимо просто ввести в нее дополнительные блоки. Однако вопросы масштабирования выходят далеко за рамки данной книги, оставим это как упражнение для читателя. Некоторые инструменты, которые могут использоваться для масштабирования, рассмотрены в главе 12.
Выбор серверного оборудования
Задача по выбору сервера проста и сложна одновременно. Проста потому, что на самом деле подойдет любая платформа на базе х86, а сложна потому, что гарантированное обеспечение необходимой производительности системы будет зависеть от того, насколько тщательно спроектирована платформа. При выборе оборудования следует внимательно рассмотреть конструкцию системы в целом и то, какие функциональные возможности требуется поддерживать. Это поможет определить требования к ЦП, системной плате и блоку питания. Те, кто просто настраивает свою первую систему Asterisk с целью научиться это делать, могут спокойно проигнорировать информацию, приведенную в данном разделе. Однако при построении полноценной системы, пригодной к практическому применению, рассматриваемые здесь вопросы требуют проработки.
Вопросы производительности
При выборе оборудования для установки Asterisk главным соображением является то, насколько мощной должна быть полученная система. Это непростой вопрос, поскольку большую роль в данном случае
играет то, как будет использоваться система. Такого понятия, как модель управления производительностью Asterisk, не существует, поэтому, чтобы принять разумное решение о необходимых ресурсах, следует определить, как Asterisk будет использовать систему. Должны быть учтены следующие факторы:
Максимальное число одновременных соединений, которое система должна будет поддерживать
Каждое соединение будет увеличивать нагрузку на систему. Доля трафика в процентном выражении, который потребует интенсивной работы процессора для ЦОС кодеками, использующими алгоритмы сжатия (такими, как G.729 и GSM)
Работа по цифровой обработке сигнала (Digital Signal Processing, DSP), которую Asterisk осуществляет на программном уровне, может иметь огромное влияние на то, какое количество одновременных вызовов она будет поддерживать. Система, которая успешно обрабатывает 50 одновременных вызовов G.711, может потерпеть фиаско при запросе на одновременную обработку 10 каналов со сжатием, кодированных G.729. Мы подробнее поговорим о G.729, GSM, G.711 и многих других кодеках в главе 8. Будет ли обеспечиваться конференц-связь и какая интенсивность общения предполагается
Будет ли система использоваться интенсивно? Конференц-связь требует, чтобы система преобразовывала и добавляла каждый отдельный входной аудиопоток во множество выходных потоков. Смешение нескольких аудиопотоков в масштабе времени, близком к реальному, может создавать существенную нагрузку на ЦП.
Эхоподавление
Эхоподавление может потребоваться при любом вызове, в котором задействован интерфейс коммутируемой телефонной сети общего пользования (Public Switched Telephone Network, PSTN). Поскольку эхоподавление является математической функцией, чем больше системе приходится его выполнять, тем выше будет нагрузка на ЦП. Не пугайтесь. Эхоподавление - это еще одна тема для главы 8. Логика разработки сценариев диалплана
Передача Asterisk управления вызовами внешней программе всегда ведет к снижению производительности. Логика максимально должна быть реализована внутри диалплана. Если используются внешние сценарии, основными критериями при их создании должны быть производительность и эффективность.