По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет! Сегодня в статье мы расскажем про настройку Point-to-Point GRE VPN туннелей на оборудовании Cisco и о том, как сделать их защищенными при помощи IPsec. Generic Routing Encapsulation (GRE) - это протокол туннелирования, разработанный компанией Cisco, который позволяет инкапсулировать широкий спектр протоколов сетевого уровня в point-to-point каналах.
Туннель GRE используется, когда пакеты должны быть отправлены из одной сети в другую через Интернет или незащищенную сеть. В GRE виртуальный туннель создается между двумя конечными точками (маршрутизаторами Cisco), а пакеты отправляются через туннель GRE.
Важно отметить, что пакеты, проходящие внутри туннеля GRE, не шифруются, поскольку GRE не шифрует туннель, а инкапсулирует его с заголовком GRE. Если требуется защита данных, IPSec должен быть настроен для обеспечения конфиденциальности данных - тогда GRE-туннель преобразуется в безопасный VPN-туннель GRE.
На приведенной ниже схеме показана процедура инкапсуляции простого незащищенного пакета GRE, проходящего через маршрутизатор и входящего в туннельный интерфейс:
Хотя многие могут подумать, что туннель GRE IPSec между двумя маршрутизаторами похож на VPN-соединение IPSec между сайтами, это не так. Основное отличие состоит в том, что туннели GRE позволяют multicast пакетам проходить через туннель, тогда как IPSec VPN не поддерживает multicast пакеты.
В больших сетях, где необходимы протоколы маршрутизации, такие как OSPF, EIGRP, туннели GRE - ваш лучший выбор. По этой причине, а также из-за того, что туннели GRE гораздо проще в настройке, инженеры предпочитают использовать GRE, а не IPSec VPN.
В этой статье объясняется, как создавать простые незащищенные (unprotected) и безопасные (IPSec encrypted) туннели GRE между конечными точками. Мы объясним все необходимые шаги для создания и проверки туннеля GRE (незащищенного и защищенного) и настройки маршрутизации между двумя сетями.
Создание Cisco GRE туннеля
Туннель GRE использует интерфейс «туннель» - логический интерфейс, настроенный на маршрутизаторе с IP-адресом, где пакеты инкапсулируются и декапсулируются при входе или выходе из туннеля GRE.
Первым шагом является создание нашего туннельного интерфейса на R1:
R1(config)# interface Tunnel0
R1(config-if)# ip address 172.16.0.1 255.255.255.0
R1(config-if)# ip mtu 1400
R1(config-if)# ip tcp adjust-mss 1360
R1(config-if)# tunnel source 1.1.1.10
R1(config-if)# tunnel destination 2.2.2.10
Все туннельные интерфейсы участвующих маршрутизаторов всегда должны быть настроены с IP-адресом, который не используется где-либо еще в сети. Каждому туннельному интерфейсу назначается IP-адрес в той же сети, что и другим туннельным интерфейсам.
В нашем примере оба туннельных интерфейса являются частью сети 172.16.0.0/24.
Поскольку GRE является протоколом инкапсуляции, мы устанавливаем максимальную единицу передачи (MTU - Maximum Transfer Unit) до 1400 байт, а максимальный размер сегмента (MSS - Maximum Segment Size) - до 1360 байт. Поскольку большинство транспортных MTU имеют размер 1500 байт и у нас есть дополнительные издержки из-за GRE, мы должны уменьшить MTU для учета дополнительных служебных данных. Установка 1400 является обычной практикой и гарантирует, что ненужная фрагментация пакетов будет сведена к минимуму.
В заключение мы определяем туннельный источник, который является публичным IP-адресом R1, и пункт назначения - публичный IP-адрес R2.
Как только мы завершим настройку R1, маршрутизатор подтвердит создание туннеля и сообщит о его состоянии:
R1#
*May 21 16:33:27.321: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
Поскольку интерфейс Tunnel 0 является логическим интерфейсом, он останется включенным, даже если туннель GRE не настроен или не подключен на другом конце.
Далее мы должны создать интерфейс Tunnel 0 на R2:
R2(config)# interface Tunnel0
R2(config-if)# ip address 172.16.0.2 255.255.255.0
R2(config-if)# ip mtu 1400
R2(config-if)# ip tcp adjust-mss 1360
R2(config-if)# tunnel source 2.2.2.10
R2(config-if)# tunnel destination 1.1.1.10
Интерфейс туннеля R2 настроен с соответствующим IP-адресом источника и назначения туннеля. Как и в случае с R1, маршрутизатор R2 сообщит нам, что интерфейс Tunnel0 работает:
R2#
*May 21 16:45:30.442: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
Маршрутизация сетей через туннель GRE
На этом этапе обе конечные точки туннеля готовы и могут «видеть» друг друга. Echo icmp от одного конца подтвердит это:
R1# ping 172.16.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#
Опять же, этот результат означает, что две конечные точки туннеля могут видеть друг друга. Рабочие станции в любой сети по-прежнему не смогут достичь другой стороны, если на каждой конечной точке не установлен статический маршрут:
R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.0.2
На R1 мы добавляем статический маршрут к удаленной сети 192.168.2.0/24 через 172.16.0.2, который является другим концом нашего туннеля GRE. Когда R1 получает пакет для сети 192.168.2.0, он теперь знает, что следующим переходом является 172.16.0.2, и поэтому отправит его через туннель.
Та же конфигурация должна быть повторена для R2:
R2(config)# ip route 192.168.1.0 255.255.255.0 172.16.0.1
Теперь обе сети могут свободно общаться друг с другом через туннель GRE.
Защита туннеля GRE с помощью IPSec
Как упоминалось ранее, GRE является протоколом инкапсуляции и не выполняет шифрование. Создание туннеля GRE точка-точка без какого-либо шифрования чрезвычайно рискованно, поскольку конфиденциальные данные могут быть легко извлечены из туннеля и просмотрены другими.
Для этого мы используем IPSec для добавления уровня шифрования и защиты туннеля GRE. Это обеспечивает нам необходимое шифрование военного уровня и спокойствие. Наш пример ниже охватывает режим туннеля GRE IPSec.
Настройка шифрования IPSec для туннеля GRE (GRE over IPSec)
Шифрование IPSec включает в себя два этапа для каждого маршрутизатора. Эти шаги:
Настройка ISAKMP (ISAKMP Phase 1)
Настройка IPSec (ISAKMP Phase 2)
Настройка ISAKMP (ISAKMP Phase 1)
IKE существует только для установления SA (Security Association) для IPsec. Прежде чем он сможет это сделать, IKE должен согласовать отношения SA (ISAKMP SA) с партнером.
Для начала, мы начнем работать над R1.
Первым шагом является настройка политики ISAKMP Phase 1:
R1(config)# crypto isakmp policy 1
R1(config-isakmp)# encr 3des
R1(config-isakmp)# hash md5
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 2
R1(config-isakmp)# lifetime 86400
Приведенные выше команды определяют следующее (в указанном порядке):
3DES - метод шифрования, который будет использоваться на этапе 1 Phase 1
MD5 - алгоритм хеширования
Authentication pre-share - использование предварительного общего ключа в качестве метода проверки подлинности
Group 2 - группа Диффи-Хеллмана, которая будет использоваться
86400 - время жизни ключа сеанса. Выражается в килобайтах или в секундах. Значение установлено по умолчанию.
Далее мы собираемся определить Pre Shared Key (PSK) для аутентификации с партнером R1, 2.2.2.10:
R1(config)# crypto isakmp key merionet address 2.2.2.10
PSK ключ партнера установлен на merionet. Этот ключ будет использоваться для всех переговоров ISAKMP с партнером 2.2.2.10 (R2).
Создание IPSec Transform (ISAKMP Phase 2 policy)
Теперь нам нужно создать набор преобразований, используемый для защиты наших данных. Мы назвали это TS:
R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
R1(cfg-crypto-trans)# mode transport
Вышеуказанные команды определяют следующее:
SP-3DES - метод шифрования
MD5 - алгоритм хеширования
Установите IPSec в транспортный режим.
Наконец, мы создаем профиль IPSec для соединения ранее определенной конфигурации ISAKMP и IPSec. Мы назвали наш профиль IPSec protect-gre:
R1(config)# crypto ipsec profile protect-gre
R1(ipsec-profile)# set security-association lifetime seconds 86400
R1(ipsec-profile)# set transform-set TS
Теперь мы готовы применить шифрование IPSec к интерфейсу туннеля:
R1(config)# interface Tunnel 0
R1(config-if)# tunnel protection ipsec profile protect-gre
Ну и наконец пришло время применить ту же конфигурацию на R2:
R2(config)# crypto isakmp policy 1
R2(config-isakmp)# encr 3des
R2(config-isakmp)# hash md5
R2(config-isakmp)# authentication pre-share
R2(config-isakmp)# group 2
R2(config-isakmp)# lifetime 86400
R2(config)# crypto isakmp key merionet address 1.1.1.10
R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
R2(cfg-crypto-trans)# mode transport
R2(config)# crypto ipsec profile protect-gre
R2(ipsec-profile)# set security-association lifetime seconds 86400
R2(ipsec-profile)# set transform-set TS
R2(config)# interface Tunnel 0
R2(config-if)# tunnel protection ipsec profile protect-gre
Проверка GRE over IPSec туннеля
Наконец, наш туннель был зашифрован с помощью IPSec, предоставляя нам столь необходимый уровень безопасности. Чтобы проверить и проверить это, все, что требуется, это попинговать другой конец и заставить туннель VPN IPSec подойти и начать шифрование/дешифрование наших данных:
R1# ping 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Используя команду show crypto session, мы можем быстро убедиться, что шифрование установлено и выполняет свою работу:
R1# show crypto session
Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 2.2.2.10 port 500
IKE SA: local 1.1.1.10/500 remote 2.2.2.10/500 Active
IPSEC FLOW: permit 47 host 1.1.1.10 host 2.2.2.10
Active SAs: 2, origin: crypto map
Поздравляю! Мы только что успешно создали Point-to-point GRE over IPSec VPN туннель между двумя маршрутизаторами Cisco.
В этой первой части статьи мы сначала рассмотрим некоторые методы обслуживания сетей. Существуют различные модели, которые помогут вам поддерживать ваши сети и сделать вашу жизнь проще. Во второй части статьи мы рассмотрим некоторые теоретические модели, которые помогут вам в устранении неполадок.
Ну что давайте начнем рассматривать техническое обслуживании сети! Обслуживание сети в основном означает, что вы должны делать все необходимое для поддержания сети в рабочем состоянии, и это включает в себя ряд задач:
Устранение неполадок в сети;
Установка и настройка аппаратного и программного обеспечения;
Мониторинг и повышение производительности сети;
Планирование будущего расширения сети;
Создание сетевой документации и поддержание ее в актуальном состоянии;
Обеспечение соблюдения политики компании;
Обеспечение соблюдения правовых норм;
Обеспечение безопасности сети от всех видов угроз.
Конечно, этот список может отличаться для каждой сети, в которой вы работаете. Все эти задачи можно выполнить следующим образом:
Структурированные задачи;
Interrupt-driven задачи.
Структурированный означает, что у вас есть заранее определенный план обслуживания сети, который гарантирует, что проблемы будут решены до того, как они возникнут. Как системному администратору, это сделает жизнь намного проще. Управляемый прерыванием означает, что вы просто ждете возникновения проблемы, а затем исправляете ее так быстро, как только можете. Управляемый прерыванием подход больше похож на подход "пожарного" ...вы ждете, когда случится беда, а затем пытаетесь решить проблему так быстро, как только можете. Структурированный подход, при котором у вас есть стратегия и план обслуживания сети, сокращает время простоя и является более экономичным.
Конечно, вы никогда не сможете полностью избавиться от Interrupt-driven, потому что иногда все "просто идет не так", но с хорошим планом мы можем точно сократить количество задач, управляемых прерываниями.
Вам не нужно думать о модели обслуживания сети самостоятельно. Есть ряд хорошо известных моделей обслуживания сети, которые используются сетевыми администраторами. Лучше всего использовать одну из моделей, которая лучше всего подходит для вашей организации и подкорректировать, если это необходимо.
Вот некоторые из известных моделей обслуживания сети:
FCAPS:
Управление неисправностями.
Управление конфигурацией.
Управление аккаунтингом.
Управление производительностью.
Управление безопасностью.
Модель обслуживания сети FCAPS была создана ISO (Международной организацией стандартизации).
ITIL: библиотека ИТ-инфраструктуры - это набор практик для управления ИТ-услугами, который фокусируется на приведении ИТ-услуг в соответствие с потребностями бизнеса.
TMN: сеть управления телекоммуникациями - это еще одна модель технического обслуживания, созданная ITU-T (сектор стандартизации телекоммуникаций) и являющаяся вариацией модели FCAPS. TMN нацелена на управление телекоммуникационными сетями.
Cisco Lifecycle Services: конечно, Cisco имеет свою собственную модель обслуживания сети, которая определяет различные фазы в жизни сети Cisco:
Подготовка
Планирование
Проектирование
Внедрение
Запуск
Оптимизация
Выбор модели обслуживания сети, которую вы будете использовать, зависит от вашей сети и бизнеса. Вы также можете использовать их в качестве шаблона для создания собственной модели обслуживания сети.
Чтобы дать вам представление о том, что такое модель обслуживания сети и как она выглядит, ниже приведен пример для FCAPS:
Управление неисправностями: мы будем настраивать наши сетевые устройства (маршрутизаторы, коммутаторы, брандмауэры, серверы и т. д.) для захвата сообщений журнала и отправки их на внешний сервер. Всякий раз, когда интерфейс выходит из строя или нагрузка процессора превышает 80%, мы хотим получить сообщение о том, чтобы узнать, что происходит.
Управление конфигурацией: любые изменения, внесенные в сеть, должны регистрироваться в журнале. Чаще всего используют управление изменениями, чтобы соответствующий персонал был уведомлен о планируемых изменениях в сети. Изменения в сетевых устройствах должны быть зарегистрированы и утверждены до того, как они будут реализованы.
Управление аккаунтингом: Мы будем взимать плату с (гостевых) пользователей за использование беспроводной сети, чтобы они платили за каждые 100 МБ данных или что-то в этом роде. Он также обычно используется для взимания платы с людей за междугородние VoIP-звонки.
Управление производительностью: производительность сети будет контролироваться на всех каналах LAN и WAN, чтобы мы знали, когда что-то пойдет не так. QoS (качество обслуживания) будет настроено на соответствующих интерфейсах.
Управление безопасностью: мы создадим политику безопасности и реализуем ее с помощью брандмауэров, VPN, систем предотвращения вторжений и используем AAA (Authorization, Authentication and Accounting) для проверки учетных данных пользователей. Сетевые нарушения должны регистрироваться, и должны быть приняты соответствующие мероприятия.
Как вы видите, что FCAPS - это не просто "теоретический" метод, но он действительно описывает "что", "как" и "когда" мы будем делать.
Какую бы модель обслуживания сети вы ни решили использовать, всегда есть ряд рутинных задач обслуживания, которые должны иметь перечисленные процедуры, вот несколько примеров:
Изменения конфигурации: бизнес никогда не стоит на месте, он постоянно меняется. Иногда вам нужно внести изменения в сеть, чтобы разрешить доступ для гостевых пользователей, обычные пользователи могут перемещаться из одного офиса в другой, и для облегчения этой процедуры вам придется вносить изменения в сеть.
Замена оборудования: старое оборудование должно быть заменено более современным оборудованием, и также возможна ситуация, когда производственное оборудование выйдет из строя, и нам придется немедленно заменить его.
Резервные копии: если мы хотим восстановиться после сетевых проблем, таких как отказавшие коммутаторы или маршрутизаторы, то нам нужно убедиться, что у нас есть последние резервные копии конфигураций. Обычно вы используете запланированные резервные копии, поэтому вы будете сохранять текущую конфигурацию каждый день, неделю, месяц или в другое удобное для вас время.
Обновления программного обеспечения: мы должны поддерживать ваши сетевые устройства и операционные системы в актуальном состоянии. Обновления позволяют исправлять ошибки ПО. Также обновление проводится для того, чтобы убедиться, что у нас нет устройств, на которых работает старое программное обеспечение, имеющее уязвимости в системе безопасности.
Мониторинг: нам необходимо собирать и понимать статистику трафика и использования полосы пропускания, чтобы мы могли определить (будущие) проблемы сети, но также и планировать будущее расширение сети.
Обычно вы создаете список задач, которые должны быть выполнены для вашей сети. Этим задачам можно присвоить определенный приоритет. Если определенный коммутатор уровня доступа выходит из строя, то вы, вероятно, захотите заменить его так быстро, как только сможете, но нерабочее устройство распределения или основного уровня будет иметь гораздо более высокий приоритет, поскольку оно влияет на большее число пользователей Сети.
Другие задачи, такие как резервное копирование и обновление программного обеспечения, могут быть запланированы. Вы, вероятно, захотите установить обновления программного обеспечения вне рабочего времени, а резервное копирование можно запланировать на каждый день после полуночи. Преимущество планирования определенных задач заключается в том, что сетевые инженеры с меньше всего забудут их выполнить.
Внесение изменений в вашу сеть иногда влияет на производительность пользователей, которые полагаются на доступность сети. Некоторые изменения будут очень важны, изменения в брандмауэрах или правилах списка доступа могут повлиять на большее количество пользователей, чем вы бы хотели. Например, вы можете установить новый брандмауэр и запланировать определенный результат защиты сети. Случайно вы забыли об определенном приложении, использующем случайные номера портов, и в конечном итоге устраняете эту проблему. Между тем некоторые пользователи не получат доступ к этому приложению (и возмущаются, пока вы пытаетесь его исправить...).
Более крупные компании могут иметь более одного ИТ-отдела, и каждый отдел отвечает за различные сетевые услуги. Если вы планируете заменить определенный маршрутизатор завтра в 2 часа ночи, то вы можете предупредить парней из отдела "ИТ-отдел-2", о том, что их серверы будут недоступны. Для этого можно использовать управление изменениями. Когда вы планируете внести определенные изменения в сеть, то другие отделы будут проинформированы, и они могут возразить, если возникнет конфликт с их планированием.
Перед внедрением управления изменениями необходимо подумать о следующем:
Кто будет отвечать за авторизацию изменений в сети?
Какие задачи будут выполняться во время планового технического обслуживания windows, linux, unix?
Какие процедуры необходимо соблюдать, прежде чем вносить изменения? (например: выполнение "copy run start" перед внесением изменений в коммутатор).
Как вы будете измерять успех или неудачу сетевых изменений? (например: если вы планируете изменить несколько IP-адресов, вы запланируете время, необходимое для этого изменения. Если для перенастройки IP-адресов требуется 5 минут, а вы в конечном итоге устраняете неполадки за 2 часа, так как еще не настроили. Из-за этого вы можете "откатиться" к предыдущей конфигурации. Сколько времени вы отводите на устранение неполадок? 5 минут? 10 минут? 1 час?
Как, когда и кто добавит сетевое изменение в сетевую документацию?
Каким образом вы создадите план отката, чтобы в случае непредвиденных проблем восстановить конфигурацию к предыдущей конфигурации?
Какие обстоятельства позволят отменить политику управления изменениями?
Еще одна задача, которую мы должны сделать - это создать и обновить вашу сетевую документацию. Всякий раз, когда разрабатывается и создается новая сеть, она должна быть задокументирована. Более сложная часть состоит в том, чтобы поддерживать ее в актуальном состоянии. Существует ряд элементов, которые вы должны найти в любой сетевой документации:
Физическая топологическая схема (физическая карта сети): здесь должны быть показаны все сетевые устройства и то, как они физически связаны друг с другом.
Логическая топологическая схема (логическая карта сети): здесь необходимо отобразить логические связи между устройствами, то есть как все связано друг с другом. Показать используемые протоколы, информация о VLAN и т. д.
Подключения: полезно иметь диаграмму, которая показывает, какие интерфейсы одного сетевого устройства подключены к интерфейсу другого сетевого устройства.
Инвентаризация: вы должны провести инвентаризацию всего сетевого оборудования, списков поставщиков, номера продуктов, версии программного обеспечения, информацию о лицензии на программное обеспечение, а также каждое сетевое устройство должно иметь инвентарный номер.
IP-адреса: у вас должна быть схема, которая охватывает все IP-адреса, используемые в сети, и на каких интерфейсах они настроены.
Управление конфигурацией: перед изменением конфигурации мы должны сохранить текущую запущенную конфигурацию, чтобы ее можно было легко восстановить в предыдущую (рабочую) версию. Еще лучше хранить архив старых конфигураций для дальнейшего использования.
Проектная документация: документы, которые были созданы во время первоначального проектирования сети, должны храниться, чтобы вы всегда могли проверить, почему были приняты те или иные проектные решения.
Это хорошая идея, чтобы работать с пошаговыми рекомендациями по устранению неполадок или использовать шаблоны для определенных конфигураций, которые все сетевые администраторы согласны использовать.
Ниже показаны примеры, чтобы вы понимали, о чем идет речь:
interface FastEthernet0/1
description AccessPoint
switchport access vlan 2
switchport mode access
spanning-tree portfast
Вот пример интерфейсов доступа, подключенных к беспроводным точкам доступа. Portfast должен быть включен для связующего дерева, точки доступа должны быть в VLAN 2, а порт коммутатора должен быть изменен на "доступ" вручную.
interface FastEthernet0/2
description VOIP
interface FastEthernet0/2
description ClientComputer
switchport access vlan 6
switchport mode access
switchport port-security
switchport port-security violation shutdown
switchport port-security maximum 1
spanning-tree portfast
spanning-tree bpduguard enable
Вот шаблон для интерфейсов, которые подключаются к клиентским компьютерам. Интерфейс должен быть настроен на режиме "доступа" вручную. Безопасность портов должна быть включена, поэтому допускается только 1 MAC-адрес (компьютер). Интерфейс должен немедленно перейти в режим переадресации, поэтому мы настраиваем spanning-tree portfast, и, если мы получаем BPDU, интерфейс должен перейти в err-disabled. Работа с предопределенными шаблонами, подобными этим, уменьшит количество ошибок, потому что все согласны с одной и той же конфигурацией. Если вы дадите каждому сетевому администратору инструкции по ""защите интерфейса", вы, вероятно, получите 10 различных конфигураций
interface GigabitEthernet0/1
description TRUNK
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk nonegotiate
Вот еще один пример для магистральных соединений. Если вы скажете 2 сетевым администраторам "настроить магистраль", вы можете в конечном итоге получить один интерфейс, настроенный для инкапсуляции 802.1Q, а другой-для инкапсуляции ISL. Если один сетевой администратор отключил DTP, а другой настроил интерфейс как "dynamic desirable", то он также не будет работать. Если вы дадите задание им настроить магистраль в соответствии с шаблоном, то у нас будет одинаковая конфигурация с обеих сторон.
На просторах Интернет можно найти много инструкций по настройке Asterisk с использованием графического интерфейса FreePBX. И они помогают настраивать и управлять АТС в большинстве случаев. Но гораздо больше возможностей дает настройка «чистого» Asterisk.
В статье мы сделаем базовую настройку Asterisk через конфигурационные файлы.
Предполагается, что у нас уже установлена и первоначально настроена ОС, скачены и установлены модули dahdi, libpri, iax2, необходимые голосовые файлы и кодеки и проинсталлирован Asterisk.
Если вы еще не ничего не установили, то посмотрите в нашей статье как установить Asterisk на CentOS 7
А еще вам понадобится установить sngrep для трассировки и отладки SIP-сообщений. Погнали?
Теория
Итак, приступаем к внедрению Asterisk. Структура используемых Астериском директорий следующая:
/usr/lib64/asterisk/modules – тут находятся загружаемые модули;
/var/log/asterisk – тут находятся лог-файлы, в том числе и лог звонков (если не настроено другое);
/var/spool/asterisk – тут находятся подпапки, в которых находятся бэкапы, записи разговоров, голосовая почта, факсы и так далее;
/var/lib/asterisk – тут находятся подпапки, в которых находятся звуковые файлы для музыки на удержании, звуковые файлы для выбранных языков (например для проигрывания голосовых сообщений в IVR), записанные голосовые сообщения для приветствия и так далее.
Конфигурационные файлы находятся в папке /etc/asterisk. Для работы каждого модуля Asterisk необходим конфигурационный файл. Эти файлы (с расширением .conf), содержат определения каналов, описывают различные внутренние сервисы, определяют местоположения других модулей, устанавливают связь с диалпланом. Необязательно настраивать все файлы. Требуют настройки только те, которые необходимы для вашей конфигурации.
Основные конфигурационные файлы:
asterisk.conf – определяет глобальные параметры, директории и опции для запуска Asterisk;
cdr.conf – определяет настройки для записи параметров вызовов в файл или базу данных;
sip.conf – определяет настройки для использования SIP-протокола (как общие, так и параметры для регистрации провайдеров, внутренних пользователей и так далее);
rtp.conf – определяет порты для голоса (RTP);
iax.conf – определяет настройки для использования IAX-протокола (как общие, так и параметры для регистрации провайдеров, внутренних пользователей и так далее);
extensions.conf – основной файл, в котором описывается весь диалплан, то есть правила обработки всех вызовов;
features.conf – описывает дополнительные функции (переадресации, парковка вызова, включение записи по запросу и так далее);
logger.conf – определяет тип и детальность сообщений, записываемых в файлы журналов;
modules.conf – определяет какие модули будут или наоборот не будут загружаться при запуске Asterisk;
musiconhold.conf – используется для конфигурации разных классов музыки, используемых в приложениях музыки во время ожидания, и их местоположений;
Напомним, что это только часть конфигурационных файлов. Необходимые файлы можно добавлять в любой момент по мере необходимости. Примеры и содержание таких файлов можно найти в архиве по кнопке ниже:
Скачать архив
Сразу после установки asterisk, если не была выбрана установка базовой конфигурации, в ней нет ни одного файла.
Для подключения к asterisk в режиме командной строки необходимо ввести
asterisk –rvvvvv
r – подключение к уже запущенному процессу;
vvvvv – уровень логирования, то есть вывода информации (от слова verbose - v). Чем больше v выставляем, тем более детальная информация будет выдаваться в командную строку;
Создаем и редактируем необходимые файлы
Начнем с файла asterisk.conf:
[directories](!) – указываем расположение необходимых директорий. Знаком (!) указывается признак шаблона. В шаблоне указываются общие настройки, на которые можно ссылаться дальше.
[options] – указываем необходимые опции, одна из необходимых maxcalls указывает на количество одновременных вызовов, разрешенных на Asterisk;
transmit_silence_during_record = yes - передавать тишину SLINEAR во время записи канала;
languageprefix = yes | no - Должен ли код языка быть последним или первым компонентом имени звукового файла? Если выключен, поиск звуковых файлов ведется в формате // Если включен, поиск ведется в формате //;
execincludes = yes | no - Разрешить записи #exec в конфигурационных файлах;
hideconnect = yes | no - Показывать сообщение о подключении удаленных консолей;
dontwarn = yes | no - Отключить предупреждения (warning messages);
debug = no - Отладка: No или значение (1-4);
maxcalls = 10 - Максимальное число одновременных вызовов;
Приступаем к файлу cdr.conf. Комментарии к опциям в конфиге:
[general]
enable=yes ; включаем саму возможность логирования звонков
unanswered=no ; неотвеченные звонки не логируем
safeshutdown=yes ; при выключении сервера будем ждать, пока не допишутся ВСЕ логи
[csv]
usegmtime=yes ;лог date/time в формате GMT. По умолчанию NO
loguniqueid=yes
loguserfield=yes
Закончили. Теперь файл features.conf:
[general]
[featuremap] ; тут описываем используемые функции и их параметры
blindxfer => ## ; безусловный перевод
atxfer => *2 ; условный перевод
automon => *1
disconnect => **
parkext => 700 ; парковка
parkpos => 710-780 ; диапазон портов для парковки
context => parkedcalls ; контекст для обработки запаркованных звонков
parkingtime => 180 ; время парковки
comebacktoorigin => no ; возвращать звонок на инициатора, когда закончилось время парковки вызова
parkedplay => both ; кому играть courtesytone когда вызов снимается с парковки. Опции: callee, caller, both или no(по умолчанию)
parkedcalltransfers => caller ; Кто может сделать трансфер припаркованного вызова с помощью DTMF. Опции: callee, caller, both или no(по умолчанию)
parkedcallrepark => caller ; Кто может перепарковать, припаркованный вызов с помощью DTMF. Опции: callee, caller, both или no(по умолчанию)
parkedcallhangup => no ; Кто может закончить, припаркованный вызов с помощью DTMF Опции: callee, caller, both или no(по умолчанию)
parkedcallrecording => no ; Кто может инициировать запись, с помощью DTMF. Опции: callee, caller, both или no(по умолчанию)..
parkedmusicclass => default ; Класс музыки ожидания для припаркованного,
adsipark => no ; Передавать или нет ADSI инфо о припаркованном вызове тому кто припарковал
findslot => first
pickupexten => *8 ; перехват звонка
[applicationmap] ; тут описываем используемые приложения
sendsms => *99,peer/both,Macro,sendsms
pitch => *00,self/both,Macro,pitch
Теперь конфигурируем RTP в файле rtp.conf
[general]
rtpstart=36600
rtpend=39999
Музыка на ожидании в здании. Открываем файл musiconhold.conf
[default]
mode=files
directory=/var/lib/asterisk/moh/
Следом открываем файл logger.conf:
[general]
[logfiles]
console => notice,warning,error,dtmf,verbose(5) ; уровень детализации сообщений, выводимых в консоль
full => debug,notice,warning,error,verbose(9),dtmf,fax,security ; уровень детализации сообщений, выводимых в лог-файл
Для удобства работы рекомендуется ограничивать уровень детализации сообщений, выводимых в консоль, но для вывода в файл выставить максимальный уровень детализации.
И напоследок - файл modules.conf. Есть 2 варианта: либо читаем все модули и указываем те, которые не надо читать:
[modules]
autoload=yes
noload => codec_g723-ast110-gcc4-glibc-x86_64-core2-sse4.so
Либо указываем конкретные модули, которые необходимо прочитать и запрещаем чтение всех. В этом случае для удобства лучше поделить модули на секции. Ниже приведена часть такого варианта:
[modules]
autoload = no
; Applications
load = app_bridgewait.so
load = app_dial.so
load = app_playback.so
; Bridging
load = bridge_builtin_features.so
load = bridge_builtin_interval_features.so
load = bridge_holding.so
; Call Detail Records
load = cdr_custom.so
; Channel Drivers
load = chan_bridge_media.so
load = chan_sip.so
; Codecs
load = codec_gsm.so
load = codec_ulaw.so
load = codec_alaw.so
load = codec_g722.so
; Formats
load = format_gsm.so
load = format_pcm.so
load = format_wav_gsm.so
load = format_wav.so
; Functions
load = func_callerid.so
load = func_cdr.so
load = func_pjsip_endpoint.so
; Core/PBX
load = pbx_config.so
; Resources
load = res_musiconhold.so
load = res_pjproject.so
load = res_pjsip_acl.so
В данной статье мы используем первый вариант. На этом с настройкой основных файлов закончим. В дальнейшем по мере необходимости в них можно вносить изменения. Все последующие настройки мы будем вносить в файлы sip.conf и extensions.conf. Погнали к созданию и регистрации внутренних абонентов.
Создание и регистрация внутренних абонентов
В sip.conf указываем сначала общие параметры SIP для Asterisk:
[general]
bindaddr=0.0.0.0 ; указываем IP-адрес и порт, на котором будет приниматься bindport=5060 ; SIP-трафик
language=ru ; используемый язык для голосовых сообщений
alwaysauthreject=yes
allowguest=no ; запрещаем принимать «гостевые» звонки, то есть вызовы от незарегистрированных пользователей
Так же в этой секции можно указать поддерживается ли видео, время регистрации, перечислить локальные сети, указываем внешний IP-адрес в случае использования NAT и так далее.
В случае, когда у нас есть разные группы абонентов (например, есть несколько отделов, подразделений либо другие какие-то признаки группировки абонентов или абонентов большое количество), рекомендуется использовать шаблоны, в которые можно выносить обобщенные настройки.
Имя шаблона берется в скобки [ ] и следом указывается (!). В шаблоне можно указать контекст для этих абонентов, используемые кодеки, разрешенные/запрещенные сети для регистрации этих абонентов, использование NAT и так далее. Пример шаблона приведен ниже:
[office](!)
type=friend
deny=0.0.0.0/0.0.0.0
permit=192.168.10.0/255.255.255.0
host=dynamic
context=from-internal
nat=no
qualify=yes
directmedia=no
disallow=all
allow=alaw
allow=ulaw
dtmfmode=info
И таких шаблонов можно может быть несколько. Теперь для создания записи для регистрации абонентов нам достаточно указать только отличительные параметры, такие как внутренний номер, имя абонента, пароль для регистрации и так далее.
[НОМЕР](ШАБЛОН)
callerid=ИМЯ
secret=ПАРОЛЬ
callgroup=5 ; номер группы вызова
pickupgroup=1,2,3,4,5 ; номера групп перехвата вызовов
Пример настройки:
В результате, по команде sip show peers мы видим зарегистрированных пользователей
Абоненты зарегистрировались, но позвонить даже между собой они пока не могут. Для того, чтобы они могли совершать и принимать звонки необходимо настроить маршрутизацию (или диалплан). Делать это мы будем в файле extensions.conf, там тоже есть своя структура. И тут мы снова немного погружаемся в теорию:
Диалплан состоит из следующих основных элементов:
контексты;
добавочные номера;
приоритеты;
приложения;
Контекст – часть (раздел) диалплана, описывающая алгоритм обработки вызова и изолированная от остального диалплана. Содержит дополнительные номера (extension). Дополнительные номера, определенные в одном контексте, полностью изолированы от добавочных номеров в другом контексте, если это не разрешено специально. Так же с помощью контекстов можно ограничивать доступ к различным функциям (например к междугородним или международным звонкам). Имя контекста заключается в квадратные скобки []. Рекомендуется создавать разные контексты для внутренних абонентов и для транков.
В начале диалплана находятся два специальных контекста, [general] и [globals]
[general] – содержит список общих настроек диалплана;
[globals] – содержит глобальные переменные;
Эти два контекста являются специальными. Контекст является одним из обязательных параметров как для абонента, так и для транка.
Asterisk определяет контекст для обработки по тому принципу откуда пришел вызов, а не куда он пришел, то есть если пришел вызов на мобильный номер от абонента, то применяться будет тот контекст, который прописан у конкретного абонента, а не указанный в транке.
Добавочные номера – это широкое понятие, которое определяет уникальные последовательности шагов (каждый шаг включает приложение), которые Asterisk будет применять к вызову по этой линии. В каждом контексте может быть задано столько добавочных номеров, сколько требуется. При вызове конкретного добавочного номера (входящим или внутренним звонком) Asterisk будет выполнять шаги, определенные для этого добавочного номера. Поэтому именно добавочные номера определяют, что происходит со звонками при их обработке соответственно диалплану.
Полный добавочный номер состоит из трех компонентов:
Имени (или номера). В качестве имени может быть использованы любые комбинации цифр и букв;
Приоритета (каждый добавочный номер может включать множество шагов; порядковый номер шага называется его приоритетом);
Приложения (или команды), которое выполняет некоторое действие над вызовом;
Эти три компонента разделяются запятыми:
exten => имя,приоритет,приложение()
Есть ещё зарезервированные добавочные номера:
s - когда в контекст поступают вызовы, для которых не указан конкретный добавочный номер, они передаются на добавочный номер s. (s - сокращение от start (начало), поскольку именно здесь начнется обработка вызова, если не передана информация о добавочном номере.;
i - когда абонент нажимает не ту кнопку (не существующий добавочный номер), вызов направляется на добавочный номер i;
t - если абонент слишком долго не нажимает кнопку после запуска приложения WaitExten(), вызовы направляются на добавочный номер t (время ожидания по умолчанию - 10 с);
h - экстеншен обрабатываемый при завершении вызова. После того как медиаканал закрылся;
Иногда можно встретить использование same вместо exten. Это применяют в основном с автоматическим выставлением приоритета, то есть same => n и означает «тоже самое, продолжение предыдущего»
Приоритеты – последовательность выполнения приложений. Каждый приоритет пронумерован последовательно, начиная с 1, и выполняет одно определенное приложение. В Asterisk есть еще приоритет n, что означает «следующий». Каждый раз, когда Asterisk встречает приоритет n, она берет номер предыдущего приоритета и добавляет 1. Это упрощает внесение изменений в диалплан, поскольку теперь не надо изменять номера всех шагов.
Приложения – выполняет определенное действие в конкретном дополнительном номере (например воспроизведение звука, прием тонального ввода, вызов канала, разрыв соединения и так далее).
Для выполнения некоторых приложений, таких как Answer() и Hangup(), не требуется никаких дополнительных инструкций. Некоторым приложениям необходима дополнительная информация. Эти данные, называемые аргументами, могут передаваться в приложения, чтобы оказывать влияние на то, как они выполняют свои действия. Чтобы передать аргументы в приложение их указывают через запятую в круглых скобках, следующих за именем приложения.
Для внесения комментариев в файл extensions.conf используют ; - вы уже могли об этом догадаться, судя по нашим комментариям прямо в конфигах :)
Таким образом можно как делать пометки для себя, так и делать невыполнимыми строки конфигурации (например, во время отладки)
Теперь давайте вернемся к нашим созданным абонентам. Создадим контекст, который указан у абонентов (context=from-internal)
В нем мы прописали что при наборе номера (ИМЯ), с приоритетом 1 выполнить приложение Dial c параметрами ПРОТОКОЛ/НОМЕР. Когда номеров немного, то можно конечно и так описывать. Но более правильно и красиво сделать тоже самое, но с использованием «маски»:
То есть при наборе любого номера из диапазона 10хх (шаблон показан нижним подчеркиванием) выполнить вызов с приоритетом 1 через приложение Dial с параметрами ПРОТОКОЛ/НАБРАННЫЙ_НОМЕР, время вызова 60 секунд и можно использовать перевод звонка (transfer).
Шаблон номера - это уникальный набор цифр, который определяет использование этого номера. Если набранный номер соответствует этому шаблону, то последующие номера не рассматриваются. Формат заполнения шаблона:
X - совпадение любой цифры от 0 - 9;
Z - любая цифра от 1 до 9;
N - совпадение любой цифры от 2 - 9;
[1237-9] - соответствует любым цифрам или буквам и скобках (в этом примере,1,2,3,7,8,9);
Перечитываем диалплан в консоли Asterisk командой dialplan reload и видим выполнение вызова.
Таким образом мы можем придумать и реализовать практически любой диалплан.
Например для запрета вызовов на международную связь достаточно прописать 3 строчки:
То есть при наборе 810 будет проиграно сообщение destination-closed (если оно было загружено в Asterisk) и будет отправлен сигнал отбоя.
Создание и регистрация транков
Ну, начнем с того, что IP-транки, используемые в Asterisk, бывают 2-х видов – SIP и IAX.
SIP-транки в основном используются для подключения провайдеров, а IAX-транки для подключения других Asterisk. Транки могут быть с регистрацией (то есть когда провайдер выдает логин, пароль и адрес или домен для регистрации у него) и без регистрации (то есть когда подключение идет по IP-адресу без логина и пароля).
В случае с регистрацией в файле sip.conf необходимо сразу после секции [general] указать строку регистрации в формате:
register => ЛОГИН:ПАРОЛЬ@SIP-ПРОВАЙДЕР/НОМЕР
Тут:
SIP-ПРОВАЙДЕР - указывается или IP-адрес провайдера или его домен;
ЛОГИН:ПАРОЛЬ - выдаются провайдером для подключения;
НОМЕР - указывается городской номер, выданный провайдером для совершения звонков;
Рассмотрим создание SIP-транка с регистрацией. Опять же если у нас несколько (до 3-5) таких транков, то можно их описать каждый отдельно. А если из больше или в дальнейшем планируется увеличить их количество, то можно использовать шаблон для подключения к оператору.
[voip-provider](!) ; имя шаблона
type=peer ; тип подключения
context=from-trunk ; используемый контекст для обработки вызовов
disallow=all ; выключаем все кодеки
allow=alaw ; указываем используемые кодеки
allow=ulaw
insecure=invite,port ; не запрашивать авторизацию на входящие звонки
qualify=yes ; проверка доступности
directmedia=no ; запрещаем установление прямых соединений для передач голоса
dtmfmode=rfc2833 ; указываем используемый тип DTMF
дальше достаточно описать конкретные настройки для конкретного оператора и указать какой шаблон использовать
[ОПЕРАТОР-1](voip-provider)
defaultuser=ЛОГИН-1
fromuser=ЛОГИН-1
secret=ПАРОЛЬ-1
host=ДОМЕН1- ИЛИ IP-АДРЕС ДЛЯ ПОДКЛЮЧЕНИЯ
fromdomain= ДОМЕН-1 ИЛИ IP-АДРЕС ДЛЯ ПОДКЛЮЧЕНИЯ
[ОПЕРАТОР-2](voip-provider)
defaultuser=ЛОГИН-2
fromuser=ЛОГИН-2
secret=ПАРОЛЬ-2
host=ДОМЕН-2 ИЛИ IP-АДРЕС ДЛЯ ПОДКЛЮЧЕНИЯ
fromdomain= ДОМЕН ИЛИ IP-АДРЕС ДЛЯ ПОДКЛЮЧЕНИЯ
Дальше указываем строки для регистрации у данных операторов:
register => ЛОГИН-1:ПАРОЛЬ-1@ДОМЕН-1/НОМЕР-1
register => ЛОГИН-2:ПАРОЛЬ-2@ДОМЕН-2/НОМЕР-2
Перечитываем файл sip.conf и проверяем регистрации:
В случае подключения транка без регистрации можно использовать тот же шаблон, а в настройках транка указать изменяемые параметры
[AST10SIP](voip-provider)
type=friend ; для транка без регистрации указываем friend (то есть мы доверяем этому подключению)
port=5060 ; указываем порт для подключения
insecure=port,invite
host=IP-АДРЕС_ПРОВАЙДЕРА
context=from-trunk-sip-AST10SIP ; если обработки вызовов через этот транк используется другой контекст, то указываем его тут.
Перечитываем файл sip.conf и проверяем регистрации:
Теперь рассмотрим создание IAX-транка. Для настройки IAX-транков используется файл iax.conf, который содержит всю информацию, необходимую Asterisk для создания и управления каналами, работающими по протоколу IAX. Структура его примерно такая же, как и у sip.conf:
[general] ; указываем глобальные параметры для протокола IAX
bindaddr=0.0.0.0
bindport=4569 ; по-умолчанию IAX-протокол использует порт 4569 можно оставить его, а можно и переопределить
language=ru
; указываем строки для регистрации транков
register => msk-spb:SuperPASS@10.10.10.10
[msk-spb]
username = msk-spb ; логин для регистрации на удаленной стороне
type = friend
trunk = yes
secret = SuperPASS ; пароль для регистрации
qualify = yes
host = 10.10.10.10 ; IP-адрес удаленной стороны
disallow= all
context = from-iax ; контекст для обработки вызовов, поступающих через этот транк
allow = alaw
allow = ulaw
Сохраняем файл iax.conf, перечитываем и проверяем регистрацию командой iax2 show peers:
Если есть абоненты, работающие по протоколу IAX, то их регистрацию описываем тоже в этом же файле аналогично SIP-регистрации.
Итак, сейчас мы имеем зарегистрированных абонентов, которые могут звонить друг другу, и зарегистрированные транки. Внутренних абонентов мы можем группировать по отделам:
exten => 500,1,Playback(it-otdel) ; проигрывается сообщение it-otdel
exten => 500,1,Dial(SIP/1001,5),Tt ; 5 секунд вызов идет на номер 1001
exten => 500,n,Dial(SIP/1002&SIP/1003) ; потом вызов идет одновременно на 1002 и 1003
Можем настраивать различные функции, запускать различные команды (в том числе и для выполнения через ОС), настраивать запись и прослушивание разговоров и так далее:
; ответить, подождать 2 секунды и положить трубку
exten => 060,1,Answer()
same => n,Wait(2)
same => n,Hangup()
; ответить, проиграть сообщение hello-world и положить трубку
exten => 061,1,Answer()
same => n,Playback(hello-world)
same => n,Hangup()
; записать сообщение в файл somefile.gsm и потом его проиграть
exten => 067,1,Record(/tmp/somefile.gsm,3,30)
same => n,Playback(/tmp/somefile)
Для совершения звонков через созданные и зарегистрированные транки SIP и IAX:
Допустим через транк IAX у нас подключен другой Asterisk с внутренней нумерацией, начинающейся с 1, 2, 3. И для вызова этих абонентов мы будем использовать префикс (код выхода на маршрут) 2. Тогда строки настройки будут следующие:
exten => _2[1-3].,1,Dial(IAX2/msk-spb/${EXTEN:1},30,r)
exten => _2.,2,Hangup()
То есть при наборе, начинающемся с 21-23, будет осуществлен вызов через транк msk-spb по протоколу IAX набранного номера, предварительно «отрезав» 1 (первую) набранную цифру. Если в течение 30 секунд не будет получен ответ, то вызов будет прекращен.
Для выхода в город мы используем транк с оператором-1 и префикс выхода будем использовать 9
exten => _9849[589]XXXXXXX,1,Dial(SIP/ОПЕРАТОР-1/${EXTEN:1}) ;то есть при наборе, начинающемся с 9, будет осуществлен вызов через транк ОПЕРАТОР-1 по протоколу SIP набранного номера, предварительно «отрезав» 1 (первую) набранную цифру
Тут важно понимать, что все, что мы реализовываем для внутренних абонентов, должно быть описано в соответствующем контексте.
Теперь перейдем к транкам и входящим звонкам. Соответственно для того, чтобы принимать входящие вызовы, необходимо прописать маршрутизацию уже в контексте транка (context=from-trunk или context = from-iax)
Для возможности через транк осуществлять вызов нашего внутреннего абонента (например через транк со встречной АТС) необходимо в контекст транка вставить
exten => _10XX,1,Dial(SIP/${EXTEN},60,tTm)
Давайте рассмотрим реализацию обработки входящего вызова от оператора (вызов на городской номер) через создание меню IVR и реализуем ещё определение рабочего и нерабочего времени. Схема обработки входящего вызова следующая:
Рабочее время у нас определено с 9:00 до 19:00 и с понедельника по пятницу.
При поступлении звонка в нерабочее время после сообщения с приветствием (01-hello) проигрывается сообщение с указанием рабочего времени (07-working-hours).
При поступлении звонка в рабочее время (проверка осуществляется в строке GoToIfTime(09:00-19:00,mon-fri)) после приветствия осуществляется переход в другой контекст ([working-time]), где предлагается выбрать необходимый пункт меню (0 – вызов секретаря, 1 – вызов на группу тех. поддержки, 2 – переход в другое меню выбора (GoTo(ivr-2,s,1)), в котором по такому же принципу осуществляется выбор.
В каждом меню реализован донабор внутренних номеров (exten => _1xхx,1,NoOp), обработка неправильного набора номера (exten => i,1,NoOp), обработка в случае, что если ничего не выбрали (exten => t,1,NoOp), вызов переводится на секретаря.
Естественно необходимо загрузить все используемые голосовые файлы в /var/lib/asterisk/sound/ru в случае использования русского языка. Тут давайте немного по-подробнее.
Как мы уже указывали выше в системе мы определили какой основной язык у нас будет использоваться для голосовых файлов (в файле sip.conf параметр language = ru). Это значит, что Asterisk будет искать имена файлов, которые мы указываем, например, в меню ivr в папке /var/lib/asterisk/sound/ru (смотрим обозначения директорий при запуске asterisk в начале статьи). Если бы мы использовали в качестве основного языка английский, то папка была бы /var/lib/asterisk/sound/en. В каждой из этих папок находятся голосовые файлы выбранных языков и в выбранных форматах, указанных при компилировании asterisk.
Если мы хотим записать свои сообщения (персональные приветствия, необходимые объявления, произносимые в создаваемых меню ivr и так далее), нам необходимо положить эти файлы в папку с соответствующим языком. Сами файлы при этом можно записать любой звукозаписывающей программой (хоть программой Звукозапись, входящей в стандартный дистрибутив любой версии Windows) и сохранить в формате wav (несжатый голос, 8кГц, 16 Бит, Моно)
Тут главное не перепутать имена файлов, находящихся в папке с голосовыми сообщениями, с именами, указанными в ivr меню. при этом в ivr меню имена указываются без расширения. Сам листинг приведен ниже.
[from-trunk]
exten => _X.,1,NoOp(Проверка времени: Если попали в диапазон - переходим в контекст working-time, если нет - продолжаем выполнение)
same => n,Answer()
same => n,Playback(01-hello)
same => n,GoToIfTime(09:00-19:00,mon-fri,*,*?working-time,s,1)
same => n,Playback(07-working-hours)
same => n,Hangup()
[working-time]
exten => s,1,Answer()
same => n,Background(01-ivr1)
same => n,StartMusicOnHold()
same => n,WaitExten(5)
;
exten => 0,1,NoOp(Если нажали "0" - звоним секретарю)
same => n,Playbacr(ostavaites-na-linii)
same => n,Dial(SIP/1005,30,mtT)
same => n,Hangup()
;
exten => 1,1,NoOp(Если нажали "1" - звоним на группу вызова: 1001+1002)
same => n,Playback(it-otdel)
same => n,Dial(SIP/1001&SIP/1002,30,mtT)
same => n,Hangup()
;
exten => 2,1,NoOp(Если нажали "2" - перенаправляем на ivr-2)
same => n,GoTo(ivr-2,s,1)
;
exten => _1xхx,1,NoOp(Прямой набор внутренних номеров)
same => n,Playback(ostavaites-na-linii)
same => n,Dial(SIP/${EXTEN}15,mtT)
same => n,Hangup()
;
exten => i,1,NoOp(Обработка ошибочного набора:i=illegal)
same => n,Playback(oshibka)
same => n,Dial(SIP/1005,30,r)
;
exten => t,1,NoOp(В случае, если не дождались нажатия)
same => n,Playback(ostavaites-na-linii)
same => n,Dial(SIP/1005,30,m)
;
[ivr-2]
exten => s,1,Background(02-ivr2)
same => n,StartMusicOnHold()
same => n,WaitExten(5)
;
exten => 1,1,NoOp(Если нажали "1" - звоним на 1001)
same => n,Dial(SIP/1001,30,mtT)
same => n,Hangup()
;
exten => 2,1,NoOp(Если нажали "2" - звоним на 1002)
same => n,Dial(SIP/1002,30,mtT)
same => n,Hangup()
;
exten => _1xхx,1,NoOp(Прямой набор внутренних номеров)
same => n,Dial(SIP/${EXTEN}15,mtT)
same => n,Hangup()
;
exten => i,1,NoOp(Обработка ошибочного набора:i=illegal)
same => n,Playback(oshibka)
same => n,Dial(SIP/1005,30,r)
;
После сохранения файла extensions.conf перечитываем диалплан в консоли (dialplan reload) и проверяем. На этом закончим с примерами.
Конфигурируя Asterisk через конфигурационные файлы, мы получаем возможность реализовать практически любую логику работы, проводить интеграции со сторонними сервисами, запускать и выполнять скрипты на уровне ОС и так далее.