По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Когда клиент ожидает ответа специалиста, ждет окончания трансфера или поставлен в очередь он привык слышать из своей трубки какие-либо звуки. Определенные компании предпочитают выжимать из этого времени максимум и озвучивать клиенту рекламный ролик, а другие просто дают клиенту возможность послушать приятную музыку. В статье поговорим о том, как работает модуль Music on Hold (музыки ожидания) и как его настроить в FreePBX 13.
Теория
В целом, данный модуль предназначен для уведомления звонящих о том, что они всё еще находятся на линии звонка. Он позволяет легко добавлять вашу собственную музыку или звуковые файлы в систему в .wav или .mp3 формате, или же просто «стримить» их в режиме онлайн. Добавление music on hold является отличным способом персонализации вашей АТС. FreePBX позволяет использовать два различных способа настройки мелодии при удержании вызова – с помощью файлов, которые должны быть загружены на ваш сервер и далее проигрываются при звонке, или при помощи стриминга – АТС подключается к какому-либо аудио источнику через сеть. Как пример источника – любой интернет стрим, стрим со звуковой карты или любого другого записывающего устройства. Различные категории MoH могут быть наложены на любой входящий маршрут, так же как и на очередь, ринг-группу, исходящий маршрут или конференцию. Важный момент – категории, назначенные локально на уровне ринг-группы или очереди, смогут переопределить значение MoH для целого маршрута, но как только звонок покинет ринг-группу – для него снова будет установлено такое значение MoH, как настроено для входящего или исходящего маршрута.
Настройка музыки в ожидании
Порядок настройки Music on Hold приведен далее.
Для начала во вкладке Settings необходимо выбрать Music on Hold и нажать «Add Category»
Далее необходимо присвоить имя и тип - файл или стрим
Затем нужно нажать Submit и кликнуть на иконку редактирования созданной категории MoH. Таким образом, вы попадете в поле редактирования категории, где можно загрузить аудиофайлы, выбрать формат для их конвертации и так далее
По умолчанию, IP - АТС проигрывает загруженные файлы в порядке очереди. Включенная опция Enable Random Play позволяет озвучивать аудио - файлы поставленному на удержание абоненту в случайном порядке.
Важный момент – при загрузке аудиофайла возможно настроить уровень громкости.
Если же используется тип Streaming, то в поле тип необходимо указать «Custom Application»
Поле Application заполняется в соответствии с источником стрима – будь это онлайн стрим или путь к скрипту для использования линейного порта на звуковой карте.
Как пример заполнения строки:
/usr/bin/testmpg -q -s --mono -r 8000 -f 8192 -b 1024 http://urlofyourlivestreamformoh/
Использование стриминга для MoH может серьезно повлиять на производительность АТС – по причине повышенного использования полосы пропускания или проблем с кодированием. Как пример – при множестве одновременных звонков с их попаданием под одну стриминговую категорию, нагрузка будет существенно возрастать. Если же эти звонки будут использовать иной, нежели ulaw кодек, такой, как, например G.722, АТС будет вынуждена транскодировать все потоки в G.722 – в случае маломощных серверов это может оказаться критичным.
В предыдущих статьях мы познакомились как управлять ресурсами AWS с помощью Terraform, в данной статье мы посмотрим, как создавать работающий web-сервер с помощью Terraform. Для развертывания настоящего боевого Web сервера, нам понадобится создать с помощью Terraform два ресурса. Инстанс EC2 и группу безопасности для того, чтобы открыть порт 80 во внешний мир. Для начала создадим новую директорию Lesson-2 и файл WebServer.tr. Вспоминаем именно данный файл с данным расширением является основным для написания кода и управления.
Напоминаю, что это обычный текстовый файл, который редактируется с помощью любого текстового редактора в нашем случае мы будем использовать текстовый редактор nano.
Mkdir Lesson-2
cd Lesson-2
nano WebServer.tr
Сразу будем привыкать к оформлению кода и добавим в код комментарии, комментарии добавляются следующим образом. Ставим знак решетки # и за ней пишем комментарий.
#-----------------------------------------------
# Terraform
#
#Build WebServer during BootStrap
#--------------------------------------------------
Для начала пишем, кто провайдер и регион для размещения наших ресурсов.
provider "aws" {
region = "eu-central-1"
}
Кстати, есть интересный сайт awsregion.info на котором можно посмотреть название регионов и место размещение. Сайт на момент написания статьи обновляется и поддерживается в актуальном состоянии.
Так первый ресурс это инстанс EC2. Resource служебное слово, далее название ресурса в кавычках и имя, которое мы ему даем в кавычках, далее открываются и закрываются фигурные скобки. Именно между ними мы и будем описывать наш ресурс.
Далее добавляем ami – который показывает, какой образ мы будем использовать.
Instance_type – тип и размер ресурса, который мы будем использовать.
В итоге смотрим, что у нас получилось в первой итерации кода:
resource "aws_instance" "WebServer_my" {
ami = "ami-0767046d1677be5a0" #Amazon Linux ami
instance_type = "t2.micro"
}
В результате исполнения данной части у нас будет создан инстанс EC2.
Далее создадим 2-й ресурс aws_security_group, фактически это правило сети для брандмауэра.
Так же описание начинаем со служебного слова resource, далее название ресурса и имя ресурса в кавычках, а в конце открывающаяся и закрывающаяся скобка в которой пойдет описание ресурса. Указываем параметр name - этот параметр обязательный для корректного отображения, description – параметр не обязательный, но можем указать, vpc_id мы не указываем т.к используем ресурс vpc по умолчанию. Далее идет описание правил сетевых на языке Terraform. Служебный параметр ingress для входящего трафика с фигурными скобками где мы вставим порты и другие параметры данного параметра. И второй служебный параметр engress для исходящего трафика с фигурными скобками. Cidr_blocks = [“подсеть”], указывают откуда или куда разрешен данный поток трафика т.е подсеть 0.0.0.0/0 означает весь интернет или все подсети.
Обратите внимание:
Мы разрешили входящий трафик на 80 порт, тот порт на котором будет работать наш веб сервер.
Мы разрешили входящий трафик на 22 порт, тот порт, который может принимать соединение для подключения по SSH протоколу.
Мы разрешили ICMP трафик до нашего сервера, чтобы можно было из интернета проверить его доступность.
Мы разрешили трафик на 443 порт, если мы в будущем захотим сделать защищенное HTTPS соединение.
И мы разрешили весь исходящий трафик с сервера указав protocol “-1”
В такой конфигурации кода Terraform мы получим два отдельных ресурса Инстанс EC2 и группу безопасности, но нас такой вариант не устроит. Нам необходимо, чтобы данная группа безопасности была автоматически присоединена к нашему серверу. Это можно сделать с помощью нового параметра, который мы добавим в первую часть кода, где мы описывали aws_instance. Данный параметр называется vpc_security_group_id, с помощью данного параметра можно сразу присоединить несколько групп безопасности, через знак равенства и скобки “= [“номер группы безопасности”]”. Например, номер группы безопасности можно взять той, что создается по умолчанию.
Все остальные указываются, через запятую. Но в нашем случае данный вариант не подойдет, потому что у нас должно все подключиться автоматически, т.е присоединить ту группу безопасности, которая создастся и которую мы описали ниже. А делается это достаточно просто после знака = в квадратных скобках без кавычек вставляем aws_security_group – то что это группа безопасности, затем . – разделитель, затем вставляем имя группы безопасности, которую мы создали mywebserver, опять разделитель символ точки ., и мы ходим взять id. В итоге получается следующий параметр и его значение:
vpc_security_group_ids = [aws_security_group.mywebserver.id]
Этой самой строчкой мы привязали группу безопасности к нашему создаваемому инстансу. И как следствие возникла зависимость инстанса от группы безопасности. Следовательно, Terraform создаст сначала группу безопасности, а затем уже создаст инстанс.
Код Terraform не выполняется сверху вниз, зачастую он исполняется в зависимости от зависимостей или вообще одновременно, когда многие части зависят друг от друга. Следовательно, вот в таком коде мы создали зависимость. По коду вы можете заметить, что если необходимо еще дополнительный порт открыть, например, в группе безопасности, то необходимо скопировать часть кода, отвечающую за открытие порта и добавить необходимые настройки, порт и протокол, подправить cidr_blocks. После корректировки вставить в правильное место, как параметр.
И для того, чтобы завершить настройку нашего Web сервера, нам необходимо написать параметр user_data. В амазоне это называется bootstrapping, т.е начальная загрузка.
User_data = <<EOF
Скрипт
EOF
Как вы видите сам скрипт будет находится между EOF, а знак << говорит о том, что скрипт мы подаем на ввод.
Далее, как любой скрипт в Linux системе мы пишем сначала интерпретатор или shell который будет исполнять и на языке понятном для bash. Поэтому в скрипте не должно быть никаких отступов! Это важно, даже если плагин текстового редактора пытается поправить.
Теперь сам скрипт:
user_data = <<EOF
#!/bin/bash
apt -y update
apt -y install apache2
myip=`curl http://169.254.169.254/latest/meta-data/local-ipv4`
echo "<h2>WebServer with IP: $myip</h2><br> Build by Terraform!" > /var/www/html /index.html
sudo service httpd start
chkconfig httpd on
EOF
Сначала обновляем систему apt –y update, далее команда apt –y install apache2 устанавливаем apache веб сервер непосредственно. Следующая строка присваиваем значение переменной myip, с помощью получения данных из самого амазона curl http://169.254.169.254/latest/meta-data/local-ipv4. Далее просто добавляем в индексную страницу по умолчанию вывод того что мы получили с подстановкой IP. Следующая строка стартует сервис, и последняя строка проверяет конфигурацию апача.
Таким образом, мы получаем полностью готовый скрипт. Нам остается его сохранить в файле и инициализировать Terraform, командой terraform init и даем команду на применение terraform apply.
В результате команды мы видим, что будет создано 2 ресурса, все, как и планировалось. Инстанс и группа безопасности.
Как мы видим сначала, из-за зависимости создается группа безопасности. А затем поднимается инстанс, к которому и будет привязана данная группа. Спустя пару минут мы можем видеть, что у нас веб сервер поднялся.
IP-адрес можно найти в консоли.
Далее, если нам более данный Web сервер не нужен, то мы его можем уничтожить простой командой terraform destroy. И мы увидим, что из-за зависимостей ресурсы будут уничтожаться в обратном порядке тому, в котором они запускались. Сначала инстанс, потом группа безопасности.
Скрипт вы можете легко модифицировать и добавить более сложные детали установки и настройки веб сервера – это полностью рабочая конфигурация.
Управление временем, в любой операционной системе, очень тесно связанно с понятием часовой зоны. Ранее мы рассказывали про работу с утилитой настройки часовой зоны tzselect. В данной утилите с помощью мастера настраивали зону. Но, по сути, утилита нам выдала только переменную для настройки и описание, как настроить для постоянного использования. Можно пойти несколькими путями:
Первый путь:
TZ=’Europe/Moscow’ - задать переменную
export TZ – экспортировать данную переменную.
Для того, чтобы применились параметры нужно перелогинится или перезагрузиться.
И после этого мы можем посмотреть текущую TZ (timezone) в файле - cat /etc/timezone
Вывод будет таким: Europe/Moscow
Второй путь это использовать утилиту timedatectl:
timedatectl list-timezones - смотрим доступные временные зоны
sudo timedatectl set-timezone Europe/Moscow
Значение времени в операционных системах определяется 4 частями:
Значение времени
Стандарт времени или универсальное время
Часовой пояс
Переход на летнее время
Для любой операционной системы есть 2 вида часов – это системные время, которое работает в рамках операционной системы с кучей параметров и аппаратные часы, работа которых определяется схемой на материнской плате и поддерживаются эти часы в работе, благодаря батарейке на материнской плате. Аппаратные часы после включения сервера или компьютера передают свое значение времени операционной системе, а далее система уже сама работает с часами. Аппаратные часы по факту нужны только для старта операционной системы. В настоящее время этот момент стал не столь важным, т.к. практически все сервера имеют доступ в интернет и могут со специальными сайтами синхронизировать время. В случае работы операционной системы на виртуальной машине, время синхронизируется с материнской машиной.
Как мы в прошлой статье уже рассматривали, есть утилита для управления и изменения системного времени - date, а есть утилита hwclock для того, чтобы посмотреть аппаратное время. Для работы данной утилиты необходимы права суперпользователя - sudo hwclock
Вот такой вывод получается, у нас в примере виртуализация на ESXI vmware и виртуализация позволяет синхронизировать часы дочерней операционной системы с аппаратными часами материнского сервера. В вашем же случае, если операционная система будет развернута на Virtualbox, то синхронизации этой происходить не будет (только при старте виртуальной машины) и будет отображаться разница во времени в результате вывода команды. Далее операционная система виртуальной машины и материнского хоста идут независимо друг от друга.
Хотелось бы отметить, что время важно не только для самой операционной системы, но и так же для взаимодействия с другими серверами, например, при использовании авторизации с помощью протокола Kerberos, в котором сервис генерирует токены опираясь на метку времени в операционной системе и, если будет слишком большое расхождение между серверами, токен не будет принят. Исходя из этого команду hwclock можно использовать и для установки времени.
sudo hwclock --set --date=[”нужное_время”] – нужное время задаем в виде dd/mm/yyyy hh:mm
То есть мы можем задать любое аппаратное время. Синхронизация пройдет только при старте операционной системы в нашем случае. Для синхронизации времени одних, часов с другими необходимо выполнить команду sudo hwclock -w.
Но в таком формате синхронизировать время не удобно, в настоящее время практически на всех серверах используется автоматическая синхронизация времени по протоколу NTP.
Данный протокол, обеспечивает синхронизацию системного времени с удаленным сервером в интернете. NTP протокол на транспортном уровне работает, через UDP на 123 порту. В интернете есть такой проект, как NTP Pool Project у которого есть сервера точного времени. Его страничка https://www.ntppool.org/ru/, по данной страничке можно подобрать ближайший к вам сервер точного времени и сделать настройку на него своего сервера или группы серверов.
Вот сервера, актуальные для России:
server 0.ru.pool.ntp.org
server 1.ru.pool.ntp.org
server 2.ru.pool.ntp.org
server 3.ru.pool.ntp.org
Для разовой синхронизации можно использовать следующую утилиту, предварительно установив ее:
sudo ntpdate [адрес_сервера]
В нашем случае получится следующее:sudo ntpdate 0.ru.pool.ntp.org
В результате время синхронизировалось, и утилита показала расхождение, которое было.
Теперь настроим автоматическую синхронизацию времени для этого необходимо установить ntpd демон. Делается это стандартным способом.
sudo apt-get install ntp -y
И отредактировать файл /etc/ntp.conf. Данный демон умеет и сам раздавать время в сети, мы можем настроить другие сервера на синхронизацию с ним, но сейчас необходимо просто настроить синхронизацию текущего сервера с временем сервера в интернете - sudo nano /etc/ntp.conf.
Добавляем сервера в файл, сохраняем и перезапускаем демона - sudo service ntp restart.
И мы можем посмотреть с какими серверами теперь наш сервер может синхронизироваться: ntpdq -pn
Получим вот такой вывод сервером с которыми у нас будет происходить синхронизация.