По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Если Вы когда-либо звонили в службу технической поддержки большого провайдера или оператора, то наверняка сталкивались с ситуацией, когда автоответчик, приятным голосом, сообщает Вам что-то типа “В настоящий момент, все операторы заняты, пожалуйста, оставайтесь на линии, мы обязательно Вам ответим” и потом начинает играть приятная музыка, до тех пор, пока кто-нибудь на другом конце не освободится и не ответит Вам. По такому принципу работает любой современный Колл-центр (call-center). Дело в том, что иногда в компанию поступает так много входящих звонков, что сотрудники чисто физически не могут ответить на каждый из них. В этом случае в кол-центрах организуются очереди (queues) входящих звонков. В данной статье, мы рассмотрим принципы организации очередей на примере Asterisk и FreePBX 13.
/p>
Пошаговое видео
Настройка
Основными составляющими частями очередей являются:
Входящие (Callers) - Входящие звонки, направляемые в очередь
Агенты (Agents) - Операторы, которые отвечают на звонки из очереди
Статика (Static)) –Настройка, при которой Агент не может покинуть очередь, будучи залогиненым
Динамика (Dynamic) - Настройка, при которой Агент может входить и выходить из очереди самостоятельно
Стратегия Звонков (Ring Strategy) - Стратегия обработки звонков, поступающих из очереди и их дальнейшего распределения между Агентами
Музыка на удержании (MoH) - Музыка или объявление, которое будет проигрываться в трубке у ожидающих в очереди абонентов
Оповещения (Announcements) - Голосовое оповещение, которое проигрывается в трубке у членов очереди (Агентов или ожидающих абонентов). Например, периодически, ожидающий абонент будет слышать, сколько минут ему осталось ждать: “Оператор ответит Вам через 5/4/3/2 минут”
Ниже будет показано, как создать очередь во FreePBX 13. Из главного меню нашей IP-АТС, необходимо перейти по следующему пути Applications -> Queues -> Add Queue
Откроется достаточно обширное меню General Settings, в котором настраиваются составляющие элементы очереди
Кратко опишем каждую опцию
Queue Number-Номер очереди. Используется для перевода входящих в очередь или Агентами, для того чтобы попасть в очередь
Queue Name - Имя очереди.
Queue Password - Пароль для очереди. Используется, когда нужно ограничить доступ в очередь каким-либо агентам
Generate Device Hints-Опция, позволяющая генерировать подсказки и даилпланы для телефонных устройств Агентов
Call Confirm- Опция, позволяющая Агенту подтверждать вызов, прежде чем принимать его
Call Confirm Announce - Сообщение, которое услышит Агент, когда подтвердит, что готов принять вызов из очереди. Голосовые сообщения можно добавлять самостоятельно через System Recordings
CID Name Prefix - Префикс для входящих звонков в очереди, который может подсказывать, откуда пришёл вызов. Например: Tech_sup1: <номер>
Wait Time Prefix - Префикс, показывающий, сколько времени абонент ожидает ответа в очереди
Alert Info- Информация для разных SIP устройств
Restrict Dynamic Agents- Ограничивает доступ в очередь всем, кроме Агентов указанных как dynamic в Queue Agents
Agent Restrictions - Специфические настройки доступа и обработки вызовов Агентами
Ring Strategy - Настройки стратегий распределения вызовов из очереди между Агентами
Autofill - Настройки распределения звонков, в случае, когда доступно несколько Агентов
Skip Busy Agents- Настройки обхода занятых Агентов
Queue Weight- Приоритет очереди. Необходим, если Агент принадлежит нескольким очередям
Music on Hold Class - Музыка на удержании. Можно добавлять самостоятельно через System Recordings
Join Announcement -Сообщение, которое проигрывается, прежде чем вызов поступает в очередь
Call Recording - Настройки записи звонков в очереди и их формата
Mark calls answered elsewhere- Помечает не отвеченные вызовы
Fail Over Destination - Куда отправить вызов, если очередь переполнена, истекло время и так далее.
Во вкладке Queue Agents можно настроить динамических или статических Агентов, которые будут обрабатывать звонки данной очереди
Во вкладке Timing&Agent Options настраиваются максимальное время ожидания абонента в очереди, тайм-ауты Агентов, время повторной попытки перевода вызова Агенту, голосовое сообщение, которое проигрывается перед тем, как Агент ответит на звонок
Вкладка Capacity Options позволяет настроить емкость очереди, количество абонентов, которые могут находиться в очереди, а также условия превышения лимита абонентов
Во вкладке Caller Announcements настраивается периодичность проигрывания сообщений абоненту, например сколько минут ему осталось ждать: “Оператор ответит Вам через 5/4/3/2 минут”, а также настройка объявления ожидающему абоненту его позиции в очереди
Вкладка Advanced Options предназначена для настройки уровня обслуживания и фильтрации различных параметров.
Reset Queue Stats сбрасывает всю статистическую информацию данной очереди
Other Options настройка доступности очереди для кросс-платформенных решений, таких как iSimphony
Public Key Infrastructure (PKI) - это набор различных технологий, которые используются для обеспечения аутентификации источника, целостности данных и конфиденциальности для пользователя в сети. PKI использует преимущества асимметричного шифрования и использует пары открытого и закрытого ключей для шифрования данных.
В PKI открытый ключ обычно связан с цифровой подписью, чтобы добавить доверие и проверить сведения о владельце сертификата. Ниже приведен ключевой жизненный цикл в PKI:
Генерация ключа: Этот процесс определяет шифр и размер ключа.
Генерация сертификата: Этот процесс создает цифровой сертификат и назначает его человеку или устройству.
Распространение: Процесс распространения отвечает за безопасное распространение ключа пользователю или устройству.
Хранение: Этот процесс отвечает за безопасное хранение ключа, чтобы предотвратить любой несанкционированный доступ к нему.
Отзыв: Сертификат или ключ могут быть отозваны, если они скомпрометированы субъектом угрозы.
Срок действия: Каждый сертификат имеет срок службы.
Каждый день мы посещаем различные веб-сайты, такие как социальные сети, стрим, новости, спорт, блоги и другие платформы. Однако задумывались ли вы когда-нибудь о проверке подлинности веб-сайтов, которые вы посещаете? Вы, наверное, думаете, что всему, что находится в Интернете, нельзя доверять. Хотя это отчасти правда, мы можем доверять только ограниченному числу веб-сайтов, например, доверять веб-сайту вашего банка. Главный вопрос заключается в том, как мы можем проверить подлинность веб-сайтов, которые мы посещаем? Именно здесь как PKI, так и цифровые сертификаты помогают установить доверие между хостом в Интернете и нашим компьютером.
Центр сертификации
PKI играет жизненно важную роль в Интернете, поскольку многим пользователям и устройствам требуется метод установления доверия в самой ненадежной сети в мире – Интернете. Понимание компонентов, которые помогают PKI обеспечить доверие, необходимую как пользователям, так и устройствам, имеет важное значение для любого специалиста по кибербезопасности.
Вы можете рассматривать PKI как набор процедур, правил, аппаратного и программного обеспечения, а также людей, которые работают вместе для управления цифровыми сертификатами. Цифровой сертификат-это официальная форма идентификации объекта, которая проверяется доверенной стороной. Эти цифровые сертификаты выдаются доверенной стороной в сети или Интернете. Они известны как Центр сертификации (Certificate Authority - CA).
В каждой стране существует государственное учреждение, которое обычно отвечает за проверку личности своих граждан и выдачу удостоверений личности, такой как паспорт.
Этот паспорт будет содержать важную информацию о владельце и сроке действия, например, дату окончания срока действия. В сети и в Интернете центр сертификации выполняет похожую роль и функции. В Интернете есть множество поставщиков, которые являются доверенными центрами сертификации, которые позволяют вам приобретать цифровой сертификат для личного использования. Примеры доверенных центров сертификации включают GoDaddy, DigiCert, Let's Encrypt, Comodo, Cloudflare и многие другие.
Важное примечание! Цифровой сертификат создается при объединении ключа и цифровой подписи. Сертификат будет содержать сведения о владельце сертификата, например, об организации.
ЦС выдаст объекту цифровой сертификат только после того, как его личность будет проверена. После того, как ЦС создает цифровой сертификат, он сохраняется в базе данных сертификатов, которая используется для безопасного хранения всех утвержденных ЦС цифровых сертификатов.
Важное примечание! По истечении срока действия цифрового сертификата он возвращается в ЦС, который затем помещается в список отзыва сертификатов (Certificate Revocation List - CRL), который поддерживается ЦС.
Цифровой сертификат форматируется с использованием стандарта X.509, который содержит следующие сведения:
Номер версии
Серийный номер
Идентификатор алгоритма подписи
Название эмитента
Срок годности
Не раньше, чем
Не после
Имя субъекта
Информация об открытом ключе субъекта
Алгоритм открытого ключа
Открытый ключ субъекта
Уникальный идентификатор эмитента (необязательно)
Уникальный идентификатор субъекта (необязательно)
Расширения (необязательно)
Алгоритм подписи сертификата
Подпись сертификата
Регистрирующий орган (RA)
Следующий рисунок - это цифровой сертификат, который используется для проверки веб-сайта Cisco:
Как показано на предыдущем рисунке, видно, что CA - это HydrantID SSH ICA G2, который выдает сертификат на www.cisco.com на срок действия с 20 сентября 2019 года по 20 сентября 2021 года.
Как показано на следующем рисунке, цифровой сертификат содержит дополнительную информацию, которая хранится с использованием стандарта X.509:
Далее давайте рассмотрим, как создается цифровая подпись и ее роль в PKI.
Цифровая подпись
При совершении деловых операций на документах требуется подпись, чтобы гарантировать, что сделка санкционирована соответствующим лицом. Такая же концепция требуется в сети, так что цифровая подпись отправляется вместе с сообщением на конечный хост. Затем узел назначения может использовать цифровую подпись для проверки подлинности сообщения.
При использовании PKI используются следующие алгоритмы для создания и проверки цифровых подписей:
DSA
RSA
Elliptic Curve Digital Signature Algorithm (ECDSA)
Чтобы создать цифровую подпись, между Алисой (отправителем) и Сергеем Алексеевичем (получателем) происходит следующий процесс:
1) Алиса будет использовать алгоритм хеширования для создания хэша (дайджеста) сообщения:
2) Затем Алиса будет использовать свой закрытый ключ для шифрования хэша (дайджеста) сообщения:
Цифровая подпись используется в качестве доказательства того, что Алиса подписала сообщение.
Чтобы лучше понять, как используются цифровые подписи в реальной жизни, давайте представим, что в сети есть два пользователя. Алиса хочет отправить Сергею Алексеевичу сообщение. Алиса может использовать цифровую подпись с сообщением, чтобы заверить Сергея Алексеевича в том, что сообщение исходило именно от нее. Это шаги, которые Алиса будет использовать для обеспечения подлинности, целостности и неотрицания:
Алиса создаст пару открытых и закрытых ключей для шифрования данных.
Алиса даст Сергею Алексеевичу только открытый ключ. Таким образом, закрытый ключ хранится у Алисы.
Алиса создаст сообщение для Сергея Алексеевича и создаст хэш (дайджест) сообщения.
Затем Алиса будет использовать закрытый ключ для шифрования хэша (дайджеста) сообщения для создания цифровой подписи.
Алиса отправит сообщение и цифровую подпись Сергею Алексеевичу.
Сергей Алексеевич будет использовать открытый ключ Алисы для расшифровки цифровой подписи, чтобы получить хэш сообщения.
Сергей Алексеевич также сгенерирует хэш сообщения и сравнит его с хэшем, полученным из цифровой подписи Алисы. Как только два значения хэша (дайджеста) совпадают, это просто означает, что сообщение подписано и отправлено Алисой.
Цифровые подписи используются не только для проверки подлинности сообщений. Они также используются в следующих случаях:
Цифровые подписи для цифровых сертификатов: это позволяет отправителю вставить цифровую подпись в цифровой сертификат.
Цифровые подписи для подписи кода: это позволяет разработчику приложения вставить свою цифровую подпись в исходник приложения, чтобы помочь пользователям проверить подлинность программного обеспечения или приложения.
На следующем рисунке показан пример приложения, содержащего цифровой сертификат:
На следующем рисунке показана дополнительная проверка цифровой подписи подписавшего:
Система доверия PKI
Ранее мы узнали, что организация может получить цифровой сертификат от доверенного центра сертификации в Интернете. Однако во многих крупных организациях вы обычно найдете корневой ЦС и множество промежуточных ЦС. Корневой ЦС отвечает за создание первичного цифрового сертификата, который затем делегируется каждому подчиненному ЦС или промежуточному ЦС. Промежуточный ЦС будет использовать цифровой сертификат корневого сервера для создания новых цифровых сертификатов для конечных устройств, таких как внутренние серверы.
На следующем рисунке показана иерархия корневого и промежуточного ЦС:
Использование этого типа иерархической структуры снимает нагрузку с корневого центра сертификации по управлению всеми цифровыми сертификатами в организации. Некоторые из этих обязанностей делегированы промежуточным серверам ЦС в сети. Представьте, что в вашем головном офисе вы развернули корневой ЦС, а в каждом удаленном филиале развернули промежуточные ЦС. Следовательно, каждый промежуточный ЦС отвечает за управление сертификатами своего собственного домена или филиала. Это также снижает риски взлома корневого ЦС злоумышленником, так что в случае взлома промежуточного ЦС корневой ЦС может быть отключен от сети, не затрагивая другие конечные устройства или промежуточные ЦС.
В небольших сетях можно развернуть один корневой ЦС для предоставления цифровых сертификатов каждому конечному устройству, как показано на следующем рисунке:
Как показано на предыдущем рисунке, одним ЦС легко управлять. Однако по мере роста сети наличие единственного центра сертификации в сети не позволит легко масштабироваться, поэтому необходимо использовать иерархическую структуру с корневым центром сертификации и промежуточными (подчиненными) центрами сертификации.
Технология TTS (text-to-speech) служит для преобразования текстовой информации в голос. Проще говоря, вы пишите – система проговаривает. В системах телефонной связи такая технология может быть полезна, если необходимо произнести баланс клиента или для озвучивания прочих голосовых сообщений. О том, как настроить TTS в FreePBX 13 с помощью командной строки Asterisk расскажем в статье.
Встроенный TTS
В FreePBX предусмотрен встроенный движок для TTS, который носит название filte. Движок хорошо отрабатывает английскую речь, но не умеет работать с русской. Вкратце ознакомимся с его настройкой. Тут все достаточно тривиально, переходим в Applications -> Text to Speech
Name - дайте имя для TTS механизма
Text - укажите произносимый системой набор слов
Choose an Engine - выберите движок для воспроизведения. По умолчанию, единственным доступным является filte
Destination - куда будет отправлен звонок, после проговаривания фразы указанной в поле Text
На этом этапе система произнесет набор слов по-английски. Писать методом транслитерации – плохая идея. Движок конечно произнесет указанные слова, но это вряд ли можно будет отправить в «продакшн». Итак, как же бесплатно настроить русскоговорящий TTS в FreePBX? Легко, с помощью системы синтеза речи festival
Русский язык FreePBX Festival
Установку будем производить на примере последней сборки FreePBX Distro на базе CentOS 6. Переходим к установке. Скачиваем исходные файлы
cd /usr/src
wget http://www.cstr.ed.ac.uk/downloads/festival/2.1/speech_tools-2.1-release.tar.gz
wget http://www.cstr.ed.ac.uk/downloads/festival/2.1/festival-2.1-release.tar.gz
Распаковываем архивы и инсталлируем необходимые файлы
tar zxvf festival-2.1-release.tar.gz
tar zxvf speech_tools-2.1-release.tar.gz
cd speech_tools
./configure
make
make install
cd ..
cd festival
./configure
make
make install
Система может потребовать установить пакет ncurses-devel. Сделайте это с помощью команды yum install ncurses-devel
Создаем переменную PATH, которая описывает путь до исполняемых файлов в директории festival/bin/
export PATH=$PATH:/usr/src/festival/bin/
Создадим директорию для хранения русскоязычных файлов. Для этого, последовательно в директории festival/lib/ создадим папки /voices и /russian:
mkdir /usr/src/festival/lib/voices/
mkdir /usr/src/festival/lib/voices/russian/
Скачиваем русскоязычный бандл:
wget http://sourceforge.net/projects/festlang.berlios/files/msu_ru_nsh_clunits-0.5.tar.bz2
Далее, распаковываем скачанный архив в созданную директорию:
tar xjf msu_ru_nsh_clunits-0.5.tar.bz2 -C ./festival/lib/voices/russian
Открываем через редактор vim файл /usr/src/festival/lib/languages.scm
vim /usr/src/festival/lib/languages.scm
В самом начале файла вставляем следующие строки:
(define (language_russian)
"(language_russian)
Set up language parameters for Russian."
(set! male1 voice_msu_ru_nsh_clunits)
(male1)
(Parameter.set 'Language 'russian)
)
В файле находим строки указанные ниже:
(language_british_english))
((equal? language 'british_english)
После указанных выше строк, добавляем следующее:
(language_russian))
((equal? language 'russian)
Далее открываем файл /usr/src/festival/lib/siteinit.scm и в самый конец добавляем строку ниже:
(set! voice_default 'voice_msu_ru_nsh_clunits)
Создаем кэш – директорию. Для этого, скопируйте команду ниже:
mkdir /var/lib/asterisk/festivalcache/ && chown asterisk:asterisk /var/lib/asterisk/festivalcache/
Открываем файл /etc/asterisk/festival.conf и добавляем следующие строки:
[main]
host=localhost
port=1314
usecache=yes
cachedir=/var/lib/asterisk/festivalcache/ \созданный выше файл
festivalcommand=(tts_textasterisk "%s" 'file)(quit)
Запускаем сервер festival
festival --server
Если все успешно, то вы увидите строки ниже:
[pbx@localhost ~]#festival --server
server Fri Aug 12 13:00:32 2016 : Festival server started on port 1314
Приступаем к тестам. Открываем файл /etc/asterisk/extensions_custom.conf и создаем тестовый диал – план как указано ниже:
[festival]
exten => s,1,Answer
exten => s,n,Festival('Привет. Все. работает.')
exten => s,n,Hangup
Сохраняем изменения. Для того, чтобы настроить воспроизведение из графического интерфейса FreePBX мы воспользуемся модулем Custom Destinations. Для его настройки перейдите во вкладку Admin -> Custom Destinations . Нажимаем на кнопку Add Destination
Разберем каждую из опций:
Target - укажите здесь festival,s,1, согласно созданному ранее диал-плану. Синтаксис заполнения следующий - [имя_контекста],[экстеншен],[приоритет]
Description - описание создаваемого правила
Notes - заметки. Если вы создаете много подобных правил, советуем создавать подробные заметки, чтобы избежать дальнейшей путаницы.
Return - если ваш контекст заканчивается командой Return (команда возвращает вызов в родительский контекст), то в поле Destination укажите назначение для вызова после отработки TTS.
По окончанию настроек нажмите Submit и затем Apply Config.
Теперь необходимо настроить маршрутизацию на кастомный контекст, который мы только что создали в FreePBX. Например, можно настроить маршрутизацию из IVR меню по нажатию цифры 5 на телефоне, как указано ниже:
Звоним на IVR и нажимаем 5 и слышим синтезированный голос. Параллельно смотрим на запущенный через CLI сервер Festival:
client(1) Fri Aug 12 13:00:54 2016 : accepted from localhost
client(1) Fri Aug 12 13:01:04 2016 : disconnected
client(2) Fri Aug 12 13:01:20 2016 : accepted from localhost
client(2) Fri Aug 12 13:01:20 2016 : disconnected
Google TTS в FreePBX
Еще пару лет назад можно было бы легко воспользоваться Google TTS для синтеза речи. Для этого надо было добавить движок во вкладке Settings -> Text To Speech Engines и отредактировать файл /var/lib/asterisk/agi-bin/propolys-tts.agi. Но, к сожалению, Google начал использовать капчу, чем перекрыл автоматизированный и бесплатный доступ к своему сервису.
Дополнительно про настройку TTS от Festival вы можете прочитать здесь.