По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В сегодняшней статье подробно рассмотрим как настроить IVR(Interact Voice Responce) на IP - АТС Asterisk на примере новой версии FreePBX 13
Нужно отметить, что изменения, которые претерпел интерфейс настройки FreePBX с 12 версии, носят часто косметический характер. Интерфейс стал более симпатичным, современным, но в то же время удобным и интуитивным
Если Вы хотите побольше узнать о принципах работы IVR и что это такое, предлагаем прочитать соответствующую статью в нашей базе знаний.
Итак, перейдём непосредственно к настройке. В данном примере, как было сказано выше, будем пользоваться FreePBX 13 и Asterisk 13 версии
Из основного меню необходимо перейти по следующему пути Applications -> IVR
Перед нами откроется страница добавления нового голосового меню IVR, нажимаем Add IVR
Открывается достаточно обширный список параметров, настраивая которые можно создать подходящее Вам голосовое меню. Кратко пробежимся по каждой опции:
IVR Name –Название IVR:
IVR Description – Описание данного IVR:
Announcement – Самое первое голосовое сообщение, которое будет проиграно, когда звонящий попадет в данное голосовое меню. Сразу надо сказать, что это не те Announcement’ы, которые создаются во вкладке Application -> Announcement и которые можно применять, например для Time Conditions, нет. Эти записи доступны в Admin -> System Recordings:
Enable Direct Dial – Данная опция, позволяет звонящему сразу набрать внутренний номер сотрудника и соединиться с ним, не дожидаясь конца голосовой записи :
Timeout – Время, после которого звонок сбрасывается:
Alert Info – Может использоваться для условного звонка с SIP устройства :
Invalid Retries – Количество повторных попыток при получении недопустимых/неверных цифр от вызывающего абонента:
Invalid Retry Recording –Сообщение, которое проигрывается при получении неправильных цифр от вызывающего абонента. Опять же, записи берутся из System recordings:
Append Announcement to Invalid – Будет ли проигрываться самое первое голосовое сообщение после Invalid Retry Recording :
Return on Invalid – Возвращает звонящего на “родительский” IVR, который предшествовал неправильно набранному номеру или отправляет по указанному пути:
Invalid Recording – Запись, которая будет играть перед отправкой вызывающего абонента на альтернативное назначение если вызывающий абонент нажал 0 или исчерпал максимальное количество недопустимых/неверных попыток набора ( как определено в Invalid Retries ):
Invalid Destination – Путь, по которому будет отправлен звонящий после того, как будет проиграно Invalid Recording:
Timeout Retries – Количество повторных попыток при отсутствии DTMF:
Timeout Retry Recording – Запись, проигрывающаяся, когда происходит тайм-аут перед запросом вызывающего абонента повторить попытку:
Append Announcement on Timeout – Будет ли проигрываться самое первое голосовое сообщение после Timeout Retry Recording:
Return on Timeout – Возвращает звонящего на “родительский” IVR, который предшествовал неправильно набранному номеру или отправляет по указанному пути после тайм-аута:
Timeout Recording – Запись, которая будет играть перед отправкой вызывающего абонента на альтернативное назначение если вызывающий абонент нажал 0 или исчерпал максимальное количество недопустимых/неверных попыток набора ( как определено в Invalid Retries ):
Timeout Destination – Путь, по которому будет отправлен звонящий после того, как будет проиграно Timeout Recording:
Return to IVR after VM Return – При выходе из голосовой почты абонент будет возвращен к этому IVR :
Digits – Цифры, которые отправляют абонента по выбранному пути:
Destination – Путь, по которому абонент отправляется после нажатия цифр из Digits :
Return – Возвращать ли звонящего на данный IVR:
Нужно просмотреть текст внутри двоичного файла или файла данных? Команда Linux strings извлечет и выведет на терминал биты текста, которые называются "строками".
Linux полон команд, которые могут выглядеть как решения в поисках проблем. Команда strings одна из них. Так, зачем же она нужна? Есть ли похожая команда, которая перечисляет строки для печати из двоичного файла?
Давайте вернемся назад. Двоичные файлы, такие как программные файлы, могут содержать строки читаемого человеком текста. Но как мы их видим? Если использовать cat или less, то, скорее всего, зависнет окно терминала. Программы, предназначенные для работы с текстовыми файлами, не могу обрабатывать исполняемые файлы, содержащие непечатаемые символы.
Большая часть данных в двоичном файле нечитабельна и не могут быть выведены в окно терминала каким-либо образом, так как нет знаков или стандартных символов для представления двоичных значений, которые не соответствуют буквенно-цифровым символам, знакам пунктуации или пробелам. В совокупности они называются "печатаемыми" символами. Остальные - "непечатаемые" символы.
Поэтому попытка просмотра или поиска текстовых строк в двоичном файле или файле данных является проблемой. И вот здесь на помощь спешит strings. Он извлекает строки печатаемых символов из файлов, чтобы другие команды могли использовать эти строки без необходимости контактировать с непечатаемыми символами.
Использование команды strings
На самом деле нет ничего сложного в этой команде: просто передаем команде название файла.
Как пример, мы попробуем просмотреть содержимое исполняемого файла jibber с помощью strings.
strings jibber
На скриншоте ниже список строк, извлечённых из указанного файла:
Установка минимальной длины строки
По умолчанию, команда strings ищет строки, содержащие четыре и более символов. Чтобы изменить значение по умолчанию используется ключ –n.
Имейте ввиду, что чем короче минимальная длина, тем больше шансов получить на выводе бесполезного материала.
Некоторые двоичные значения имеют то же числовое значение, что и значение, представляющее печатаемый символ. Если два из этих числовых значений находятся рядом в файле, а минимальная длина, равна двум, эти байты будут отображаться как строки.
Чтобы установить длину строки равной двум, используйте следующую команду:
strings -n 2 jibber
Теперь у нас на выводе есть строки, длина который равна двум и более символам. Учтите, что пробел тоже считается печатаемым символом.
Ограничение вывода команды strings командой less
Чтобы ограничить объем выведенной информации вывод команды strings можно передать команде less, а затем прокруткой просматривать всю информацию:
strings jibber | less
Теперь мы видим список, выводимый командой less, где начало списка отображено первым:
Использование strings с файлами объектов
Обычно исходный код программ компилируется в файлы объектов. Они в свою очередь связаны с файлами библиотек, чтобы создать исполняемый файл. У нас есть файл объектов jibber, давайте посмотрим, что в нем:
jibber.o | less
Данные выводятся в таблице по 8 колонок, каждая из строк которой заканчивается на букву “H”. В данном примере у нас SQL запрос.
Но если прокрутить ниже, то можно заметить, что форматирование не относится ко всему файлу.
Думаю, интересно видеть разницу между текстовыми строками файла объектов и конечного исполняемого файла.
Поиск в конкретной области файла
Скомпилированные программы имеют различные области, которые используются для хранения текста. По умолчанию, strings ищет текст во всем файле. Это так же, как если бы вы использовали параметр -a (all). Для поиска строк только в инициализированных, загруженных разделах данных в файле используйте параметр -d (data).
strings -d jibber | less
Если нет особой причины, то вполне можно обойтись значением по умолчанию.
Вывод номера строки
Иногда бывает необходимо узнать точное смещение, расположение строки в файле. В этом нам поможет ключ –o (offset).
strings -o parse_phrases | less
В данном случае номера строки показаны в восьмеричной системе.
Для получения значений в других системах исчисления, достаточно использовать опцию –t, а затем передать нужный ключ: d (десятичная система), x (шестнадцатеричная) или o (восьмеричная). Опция –t с ключом o равнозначна запуску команды strings с ключом –o.
strings -t d parse_phrases | less
Теперь номера строк показаны в десятичной системе:
strings -t x parse_phrases | less
А тут в шестнадцатеричной:
Вывод управляющих символов
Команда strings принимает знаки табуляции и пробела, как часть строки, игнорируя при этом символ начала новой строки - /r или возврата каретки - /r. Чтобы включить их отображение нужно добавить ключ –w.
strings -w add_data | less
Ниже мы видим пустую строку. Это результат работы управляющих символов: либо символа новой строки, либо символ возврата каретки.
Мы не ограничены только файлами
Мы можем использовать строки с любым, что есть или может создать поток байтов.
С помощью этой команды мы можем просмотреть содержимое оперативной памяти (RAM) нашего компьютера.
Нам нужно использовать >sudo, потому что мы получаем доступ /dev/mem. Это символьного файл устройства, в котором хранится изображение оперативной памяти компьютера.
sudo strings /dev/mem | less
В списке не все содержимое оперативной памяти, а лишь то, что команда strings смогла извлечь.
Поиск нескольких файлов сразу
Маски можно использовать для выбора групп файлов для поиска. Символ * обозначает нуль и больше символов, а символ «?» означает любой отдельный символ. Можно также указать в командной строке множество имен файлов.
Мы будем использовать маску для поиска всех исполняемых файлов в каталоге /bin. Поскольку список будет содержать результаты из многих файлов, будет использоваться параметр -f (имя файла). Имя файла будет напечатано в начале каждой строки. Затем можно просмотреть файл, в котором была найдена данная строка.
Затем передадим результаты через grep и выведем строки, содержащие слово "Copyright":
strings -f /bin/* | grep Copyright
Мы получаем упорядоченный список с об авторских правах каждого файла в каталоге /bin, с именем файла в начале каждой строки.
Команда strings распутана
Команда strings – это не какая-то тайная команда. Это обычная команда Linux. Он делает выполняет конкретные задачи и делает это очень хорошо.
Это еще один из преимуществ Linux, и действительно мощных в сочетании с другими командами. Когда вы видите, как он может оперировать двоичными файлами и другими инструментами, такими как grep, начинаете по-настоящему ценить функциональность этой слегка непонятной команды.
В обычной корпоративной сети доступ к серверам из филиалов организации может осуществляться, чаще всего, подключением к серверам, расположенным в центральном офисе. Но при расположении серверной инфраструктуры в облаке параметры связи рабочих станций с серверами будут зависеть уже не от канала связи от каждого конкретного филиала до центрального офиса, а от канала связи всех отделений организации с ЦОД облачного провайдера, чьими услугами пользуется организация для формирования облачной инфраструктуры.
Переход в облака поставил перед разработчиками ПО и сетевыми инженерами ряд новых условий, вызывающих задержку сигнала, которые им приходится учитывать для формирования качественного доступа к данным в облаке. Например, задержка длительностью 500мс приводит к снижению трафика Google на 20%, а задержка в 100мс сокращает продажи Amazon на 1%.
Время задержки может быть очень важным аспектом во время работы с виртуальными рабочими столами (VDI), потоковым вещанием, трейдингом, передовыми web-сервисами, базами данных, терминальными приложениями. Но задержка не столь критична для таких сервисов как электронная почта или работа с документами.
QoS и SLA
Существует проблема обеспечения необходимого качества обслуживания (QoS). Разные виды трафика имеют различные требования к рабочим характеристикам сети. Чувствительность видов трафика была взята из и показана в таблице 1
Таблица 1. Чувствительность различных приложений сетевым характеристикам
Тип трафика
Уровень чувствительности к сетевым характеристикам
Полоса
пропускания
Потери
Задержка
Джиттер
Голос
Очень низкий
Средний
Высокий
Высокий
Электронная коммерция
Низкий
Высокий
Высокий
Низкий
Транзакции
Низкий
Высокий
Высокий
Низкий
Электронная почта
Низкий
Высокий
Низкий
Низкий
Telnet
Низкий
Высокий
Средний
Низкий
Поиск в сети "от случая
к случаю"
Низкий
Средний
Средний
Низкий
Постоянный поиск в
сети
Средний
Высокий
Высокий
Низкий
Пересылка файлов
Высокий
Средний
Низкий
Низкий
Видеоконференция
Высокий
Средний
Высокий
Высокий
Мультикастинг
Высокий
Высокий
Высокий
Высокий
Рекомендации МСЭ-Т по обеспечению QoS для сетей описываются в рекомендациях Y.1540 - стандартные сетевые характеристики для передачи пакетов в сетях IP, и Y.1541 нормы для параметров, определенных в Y.1540.
Данные рекомендации важны для всех участников сети: провайдеров и операторов, пользователей и производителей оборудования. При создании оборудования, планировании развертывания и оценке сетей IP, оценка качества функционирования сети все будут опираться на соответствие характеристик требованиям потребителей.
Основные характеристики, рассматриваемые в рекомендации Y.1540:
производительность сети;
надежность сети/сетевых элементов;
задержка;
вариация задержки (jitter);
потери пакетов.
Подробнее о данных характеристиках следует прочитать в вышеназванных рекомендациях. В таблице 2 указаны нормы на определенными в Y.1540 характеристики и распределены по классам качества обслуживания (QoS).
Таблица 2 - Нормы для характеристик сетей IP с распределением по классам QoS
Сетевые
характеристики
Классы QoS
0
1
2
3
4
5
Задержка доставки пакета
IP, IPTD
100 мс
400 мс
100 мс
400 мс
1 с
Н
Вариация задержки
пакета IP, IPDV
50 мс
50 мс
Н
Н
Н
Н
Коэффициент потери
пакетов IP, IPLR
1х10 3
1х10 3
1х10 3
1х10 3
1х10 3
Н
Коэффициент ошибок
пакетов IP, IPER
1х10 4
1х10 4
1х10 4
1х10 4
1х10 4
Н
Примечание: Н не нормировано. Рекомендация Y.1541 устанавливает соответствие между классами QoS и приложениями:
Класс 0 приложения реального времени, чувствительные к джиттеру, характеризуемые высоким уровнем интерактивности (VoIP, видеоконференции);
Класс 1 приложения реального времени, чувствительные к джиттеру, интерактивные (VoIP, видеоконференции);
Класс 2 транзакции данных, характеризуемые высоким уровнем интерактивности (например, сигнализация);
Класс 3 транзакции данных, интерактивные;
Класс 4 приложения, допускающие низкий уровень потерь (короткие транзакции, массивы данных, потоковое видео)
Класс 5 традиционные применения сетей IP.
Таким образом некоторые из облачных сервисов вполне могут попадать в классы 0 и 1, а значит следует учитывать время задержки и стараться сделать так, чтобы она не превышала 100 мс.
Задержки в сетях
Подключение к облаку через VPN аналогично подключению к центральному офису организации по VPN, за исключением лишь того, что если в обычной корпоративной сети все филиалы организации подключались к центральному офису, то теперь подключение филиалов и центрального офиса в том числе будет осуществляться к ЦОД облачного провайдера.
Для проверки задержки в большинстве ОС используется команда ping, а для проверки пути прохождения пакета команда tracert, которые подробнее рассмотрим ниже.
Предположим, что домашняя сеть является подобием корпоративной сети малого предприятия. В таблице в приложении А собраны данные из статьи с указанием расположения ЦОД.
Воспользуемся этими данными чтобы проверить задержку сигнала от текущей домашней сети, расположенной в городе Москва, без учета VPN, до web-сервера некоторых компаний, владеющих, ЦОД, расположенных в разных городах, тем самым проверяя разницу в задержке в зависимости от расположения ЦОД облачного провайдера.
Для проверки задержки воспользуемся "Командной строкой" Windows и командами ping и tracert. Команда ping используется для проверки целостности и качества соединения в сети на основе протоколов TCP/IP. Команда tracert строит маршрут через коммутационные узлы между компьютером и конечным сервером и выводит их IP-адреса и время
задержки. На рисунках 1 и 2 представлена системная справка по командам, соответственно, tracert и ping.
Проведем тест проверки задержки до домена DataLine dtln.ru, расположенного ближе всего к домашней сети (рисунки 3 и 4).
Как видно из результатов на рисунке 5.3, было передано и получено 4 пакета объемом 32 байта. Время обмена одним пакетом составило 1 миллисекунду.
Команда tracert вывела следующие данные:
1, 2, 3 - номер перехода;
<1 мс <1 мс <1 мс время ответа для 3-х попыток (в данном случае все попытки менее 1 мс);
185.3.141.232 IP-адреса (в данном случае IP-адрес домена
dtln.ru)
Согласно проверке данного IP на сайте 2ip.ru, данный домен базируется по тому же адресу на карте, что и указано в таблице в приложении Б. Таким образом можно сделать вывод, что web-сервер большинства компаний из списка вероятнее всего находится на территории одного из их ЦОД, но даже если и нет, то позволяет сделать выводы о доступности ресурса.
Аналогично проверим ping для остальных компаний, результаты представим на рисунке 5.5. В качестве опорного времени задержки будет использовано среднее и максимальное время приема-передачи.
Из данных рисунка 5 можно сделать вывод, что среднее значение времени задержки в пределах Москвы из сети, также находящейся в пределах Москвы, чаще всего не превышает 10мс.
Можно сравнить данные значения с ping до серверов Amazon Web Services в разных регионах с сайта cloudping.info (рисунок 6).
VPN без шифрования теоретически позволил бы сократить эту задержку в связи с использованием "прямого туннеля" между "офисом" и ЦОД. Шифрование будет вносить уже свою задержку, проверить которую в данных условиях нет возможности.
В локальных сетях корпоративной сети и сети ЦОД задержка исчисляется в микросекундах. В сети ЦОД предъявляются высокие требования к быстродействию сети, современные решения Ethernet для ЦОД должны быть широкополосными и поддерживать скорости 10, 25, 40, 50, 100 Гбит/с, обеспечивать низкие задержки до 1-2 мкс для связи серверов (через три коммутатора), и многие другие.
Скорость интернет-канала
Передача видео через сети связи, будь то видео с камер наблюдения или же видеоконференции, являются одними из самых требовательных с скорости передачи данных. Если для работы с документами может быт достаточно скорости в 100 Кбит/с, то для передачи видео понадобится уже примерно 2 Мбит/с.
Для некоторых приложений, таких как IP-телефония, желательно, чтобы уровень задержек был низким, а мгновенная пропускная способность канала была больше определенного порогового значения: не ниже 24 Кбит/с для ряда приложений IP-телефонии, не ниже 256 Кбит/с для приложений, обрабатывающих видеопоток в реальном времени. Для некоторых приложений задержки не так критичны, но, с другой стороны, желательна высокая пропускная способность, например, для передачи файлов.
Например, компания Ivideon предлагает услуги облачного видеонаблюдения, и у них на сайте даются следующие требования к интернет-каналу для разного качества видеопотока. Данные представлены в таблице 3.
Таблица 3 Требования к интернет-каналу для одной камеры видеонаблюдения при разных разрешения при частоте 25 кадров/сек
Разрешение Качество изображения
Рекомендуемая скорость
1280х720 (1Mpx) /25к/с
1 Мбит/с
1920x1080 (2Mpx) /25к/с
2 Мбит/с
2048x1536 (3Mpx) /25к/с
2 Мбит/с
2592x1728 (4Mpx) /25к/с
2 Мбит/с
Но для работы с терминальными сессиями достаточно канала в 128-256 Кбит/с на пользователя. Для 50 пользователей понадобится 6.25 Мбит/с.
Компания 1cloud.ru при выборе ширины канала связи предлагает скорость соединения в диапазоне от 10 до 100 Мбит/с для доступа к виртуальному серверу.
Внутри облака сетевые соединения между виртуальными машинами имеют пропускную способность в 1 Гбит/с.
RDP-сессия
Для теста потребления трафика при использовании удаленного подключения RDP был проведен эксперимент.
Два персональных компьютера находятся в одной локальной сети и подключены к интернету. Один выступает сервером удаленного доступа, второй подключается к нему посредством встроенной в Windows программы
"Подключение к удаленному рабочему столу" по протоколу RDP. На сервере запускается видео в интернете. Для захвата трафика и анализа используется ПО Wireshark
Параметры подключения:
размер удаленного рабочего стола 1920х1080
глубина цвета 15 бит
выбранная скорость соединения 56 Кбит/с
дополнительные возможности отключены (рисунок 7)
Wireshark программа для захвата и анализа сетевого трафика. Данная программа работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс, и мощнейшую систему фильтров.
Во время подключения к удаленному рабочему столу программа замеряла отправленные и поступившие пакеты данных. Эти пакеты были отфильтрованы по IP-адресу сервера, а также по протоколу RDP. Интерфейс программы представлен на рисунке 8.
График ввода/вывода данных по IP-адресу сервера по протоколу RDP представлен на рисунке 9.
На графике на рисунке 9 видно два "всплеска" данных, т.е. две сессии подключения к серверу. Во время первой сессии проводилась работа с тяжеловесным графическим приложением. Во время второй сессии было включено видео, затем производился web-серфинг в браузере машины с некоторыми графическими материалами на странице.
Как видно по графику, в пиковый момент была передача данных 5.5 Мбит/с. В последние моменты web-серфинга 0,65 Мбит/с.
Таким образом можем сделать вывод, что протокол RDP не укладывается в ранее заявленный диапазон до 128 Кбит/с. Однако стоит учитывать, что RDP-сессия изначально очень требовательна к сети и является, по сути, передачей видеотрафика.
Общедоступной информации в сети для анализа влияния облачной инфраструктуры на сеть, по крайней мере в русскоязычном сегменте интернета, чрезвычайно мало. Исследований по теме облачных вычислений недостаточно для заключения результата, и, в основном, это анализы финансовых затрат или производительности серверов.
Наиболее подходящей темой для дискуссий на тему влияния облачной инфраструктуры на сеть могут служить только качество обслуживания (QoS) и договор о предоставлении услуг SLA, но данные темы слишком обширны и требует более углубленного внимания, а вопросы, связанные с ними, требуют внимания соответствующих специалистов.