По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В сегодняшней статье расскажем, как организовать функцию прослушивания телефонных разговоров, как входящих, так и исходящих, которые проходят в реальном времени на нашем сервере IP-АТС Asterisk. Для этих целей будем использовать стандартное приложение Asterisk - ChanSpy(). Данная задача часто встречается при организации call-центров, когда есть группа агентов, принимающих или совершающих вызовы и группа супервайзеров, контролирующих их взаимодействие с клиентами КЦ. Для того, чтобы научить агентов грамотно общаться с клиентами, супервайзерам необходимо иметь доступ не только к записям разговоров агентов, но и к разговорам в реальном времени, в том числе, с возможностью прямо во время разговора подсказать агенту какую-либо информацию и не быть услышанным клиентом. Здесь то нам и приходит на помощь ChanSpy – своеобразный “шпионский” канал.
Работа в FreePBX
По умолчанию, данная функция доступна в графической оболочке FreePBX по средствам набора специального кода Feature Code Feature Code, а именно -комбинации цифр 555
То есть, мы можем, набрав 555, подключиться к случайному разговору, который в настоящий момент проходит на IP-АТС и прослушивать его. Если разговоров несколько, то переключаться между ними можно с помощью *. Согласитесь, это слегка неудобно. Вдруг нам нужен конкретный агент, который в настоящий момент разговаривает с конкретным клиентом? Не перебирать же все разговоры и пытаться по голосу определить нужного нам агента!
Работа в Asterisk CLI
Чтобы упростить задачу супервайзерам и расширить стандартный функционал ChanSpy на FreePBX, мы немного отредактируем конфигурационные файлы Asterisk.
Для начала давайте обратимся к синтаксису ChanSpy().
ChanSpy([chanprefix,[options]]), где:
chanprefix - специальный префикс канала. Например мы можем указать шаблон для внутренних номеров, разговоры которых мы хотим прослушивать;
options - буквенные обозначения опций с учётом регистра и параметров прослушивания канала. Рассмотрим наиболее полезные:
b – позволяет подключаться к каналам, задействованным в конференц-звонке;
d – позволяет вручную управлять режимом прослушивания канала: 4 – только прослушивание, 5 – только подсказки (шёпот), 6 – и подслушивание и подсказки;
E – отключается от прослушиваемого канала, когда тот кладёт трубку;
q – тихий режим. Не проигрывает никаких звуков, когда происходит подключение к прослушиваемому каналу;
v – позволяет настроить начальный уровень громкости от -4 до 4;
w – позволяет говорить в подслушиваемый канал. Функция подсказок или “шёпота”;
Все остальные опции, доступные в ChanSpy можно узнать из командной строки Asterisk, используя команду:
core show application chanspy
Для того, чтобы настроить новое правило ChanSpy, нужно открыть файл extension_custom.conf, который лежит в /etc/asterisk/ и открыть его любым удобным текстовым редактором, например nano:
nano /etc/asterisk/extension_custom.conf
И внесём туда следующий контекст:
[app-custom-chanspy]
exten => 555.,1,Authenticate(48151623) //48151623 – это пароль для доступа к функционалу прослушивания;
exten => 555.,n,Answer
exten => 555.,n,Wait(1)
exten => 555.,n,ChanSpy(SIP/${EXTEN:3},qw)
exten => 555.,n,Hangup
Давайте разберём что получилось: пользователь, например, супервайзер набирает комбинацию 555115, где 555 – доступ к ChanSpy, а 115 – внутренний номер агента, к разговору которого хочет подключиться супервайзер. При наборе “555” пользователя попросят ввести пароль (в нашем случае 48151623), это поможет ограничить доступ к функционалу прослушивания разговоров на нашей IP-АТС. После подтверждения пароля, пользователю будет доступен функционал прослушивания разговора и “шёпота”, причем при подключении к разговору никаких уведомлений проигрываться не будет, так как включен тихий режим.
На инсталляционном носителе Windows находится не только операционная система, но и связанные с ней драйвера и компоненты системы. Все это хранится в файле, называемом - файл образ. Во время инсталляции этот образ применяется к целевому тому. Образы Windows используют формат файлов Windows Imaging (WIM), который имеет следующие преимущества:
Методы развертывания. Можно развернуть wim-файлы с помощью загрузочного USB-накопителя, из общего сетевого ресурса или с помощью специализированных технологий развертывания, таких как Службы развертывания Windows (WDS) или System Center Configuration Manager.
Редактируемость. Можно подключить образ к текущей ОС и редактировать его, включать, отключать или удалять роли и компоненты операционной системы, если это необходимо.
Возможность обновления. Имеется возможность обновить текущий образ, не создавая захват операционной системы.
Установочный носитель Windows Server 2019 содержит два WIM-файла - это Boot.wim и Install.wim. Файл Boot.wim использует для загрузки среды предустановки, которая запускается в момент развертывания Windows Server 2019. Install.wim хранит один или несколько образов операционной системы. Например, как показано на рисунке ниже, файл Install.wim содержит четыре разных выпуска Windows Server 2019. В зависимости от специфики оборудования, бывает ситуация, в которой потребуется добавить дополнительные драйверы в файл boot.wim. Например, потребуется добавить дополнительные драйвера, если процедура установки Windows не сможет получить доступ к устройству, на которое будет устанавливаться, поскольку драйвер этого устройства не включен в образ загрузки по умолчанию.
Модификация Windows образа
Deployment Image Servicing and Management (DISM) - это приложение командной строки. Программа работает с образами в автономном состоянии. Dism используется для реализации следующих задач:
Просмотр, добавление или удаление ролей и компонентов
Добавление, удаление обновлений
Добавление, удаление драйверов
Добавление, удаление приложений Windows *.appx
К примеру, можно скопировать файл Install.wim с дистрибутива Windows Server и используя Dism.exe примонитировать образ, добавить новые драйвера и обновления программного обеспечения к этому образу и сохранить или отменить эти изменения, и все это без необходимости выполнять фактическое развертывание ОС. Преимущество заключается в том, что, когда используется этот обновленный образ для развертывания, добавленные драйвера и обновления уже применяются к образу, и не нужно устанавливать их отдельно как часть процедуры настройки после установки.
На сайте каталога Центра обновления Майкрософт (https://catalog.update.microsoft.com) хранятся все сертифицированные драйвера оборудования, обновления программного обеспечения и исправления, опубликованные Microsoft. После загрузки драйверов и обновлений программного обеспечения их можно добавить к существующим установочным образам с помощью Dism.exe или соответствующих командлетов PowerShell в модуле DISM PowerShell.
Обслуживание образа Windows
Для уменьшения времени установки и настройки системы на новых серверах, нужно убедиться в тем, чтобы образы развертывания поддерживались в актуальном состоянии. К образу должны быть применены последние обновления программного обеспечения, а также должны быть включены все новые драйверы устройств для часто используемого серверного оборудования. Если не поддерживать образ развертывания в актуальном состоянии, потребуется дополнительное время на установку драйверов и обновлений. Применение обновлений после развертывания требует значительного времени, а также существенно увеличивает сетевой трафик. Одна из целей при выполнении развертывания сервера должна заключаться в том, чтобы как можно быстрее запустить сервер и включить его в работу.
Программа DISM может использоваться для обслуживания текущей операционной системы в оперативном состоянии или для автономного обслуживания образа Windows.
Обслуживание включает в себя выполнение следующих шагов:
Монтирование образа для изменения
Обслуживание образа
Фиксация или отмена внесенных изменений
Подключение образа
Примонтировав образ, появляется возможность вносить в него изменения, такие как добавление и удаление драйверов, установка обновлений, включение компонентов системы.
Обычно WIM-файл содержит несколько образов операционных систем. Каждому образу присваивается порядковый номер, который необходимо знать, прежде монтировать образ. Номер индекса можно определить с помощью Dism.exe с параметром /Get-wiminfo. Например, если дистрибутив ОС скопирован в D:Images, можно использовать следующую команду, чтобы получить список находящихся в нем образов:
Dism.exe /get-wiminfo /wimfile:d:imagessourcesinstall.wim
Тот же самый результат можно получить, используя командлет PowerShell Get-WindowsImage.
Get-WindowsImage -ImagePath d:imagessourcesinstall.wim
Когда нужный индекс операционной системы определен, монтируем этот образ программой Dism.exe c параметром /Mount-image. Например, чтобы смонтировать редакцию Standard Edition Windows Server 2019 из файла Install.wim, который доступен в папке D:Mount, введите следующую команду:
Dism.exe /mount-image /imagefile:d:imagessourcesinstall.wim /index:2 /mountdir:c:mount
В качестве альтернативы можно использовать команду Mount-WindowsImage:
Mount-WindowsImage -ImagePath D:imagessourcesinstall.wim -index 2 -path c:mount
Интеграция драйверов и обновлений
После того, как образ подключен, можно приступить к его обслуживанию. Наиболее распространенными задачами являются добавление в образ драйверов устройств и обновлений программного обеспечения. Чтобы добавить драйвера к подключенному образу используется Dism с параметром /Add-Driver. Чтобы не добавлять каждый драйвер по отдельности, используется параметр /Recurse, чтобы все драйверы находились в папке и подпапках добавлялись в образ. Например, чтобы добавить все драйвера, расположенные в папке и подпапках D:Drivers к образу, смонтированному в папке C:Mount, используйте следующую команду:
Dism.exe /image:c:mount /Add-Driver /driver:d:drivers /recurse
Командлет Add-WindowsDriver выполнит тоже действие:
Add-WindowsDriver -Path c:mount -Driver d:drivers -Recurse
Параметр /Get-Driver используется для просмотра всех добавленных драйверов, а /Remove-Driver позволяет удалить драйвер из образа. В PowerShell это командлеты Get-WindowsDriver и Remove-WindowsDriver соответственно. Удалять можно только те драйвера, которые были добавлены в образ.
Параметр /Add-Package позволяет добавляет обновления в формате *.cab или *.msu. Обновления программного обеспечения доступны на сайте Центра обновления Майкрософт в формате *.msu. Загрузим обновление с веб-сайта каталога Центра обновления Майкрософт под названием "2019-10 Cumulative Update for Windows Server, version 1903 for x64-based Systems (KB4517389) в папку D:updates на компьютере и применим обновление к образу.
Dism.exe /image:c:mount /Add-Package /PackagePath:"d:updateswindows10.0-kb4517389-x64_6292f6cb3cdf039f01410b509f8addcec8a89450.msu "
Тоже самое можно сделать используя PowerShell команду Add-WindowsPackage:
Add-WindowsPackage -path c:mount -packagepath "d:updateswindows10.0-kb4517389-x64_6292f6cb3cdf039f01410b509f8addcec8a89450.msu"
Добавление ролей и компонентов
Для просмотра ролей и компонентов в смонтированном образе используется параметр /Get-Features. Команда выглядит следующим образом:
Dism.exe /image:c:mount /Get-Features
Используя параметры /Enable-Feature и /Disable-Feature можно включать или отключать компоненты. Пример ниже включит NetFramework в текущем образе.
Dism.exe /image:c:mount /Enable-Feature /all /FeatureName:NetFx3ServerFeatures
Сохранение изменений
После внесения всех изменений в образ, их нужно сохранить, используя параметры /Unmount-Wim и /Commit. Параметр, отменяющий изменения - /Discard. Чтобы внести изменения и затем зафиксировать образ, смонтированный в папке C:mount, выполним команду:
Dism.exe /Unmount-Wim /MountDir:c:mount /commit
После применения изменений, win файл будет обновлен. Затем его можно импортировать в Windows Deployment Services (WDS) или использовать его с загрузочным usb носителем для развертывания Windows Server 2019 с уже примененными обновлениями, изменениями и драйверами.
Виртуализация часто применяется для поиска более простого способа решения некоторых проблем, отмеченных в начальных статьях этой темы, таких как разделение трафика. Как и все в мире сетевой инженерии, здесь есть компромиссы. На самом деле, если вы не нашли компромисс, вы плохо искали. В этом разделе будут рассмотрены некоторые (хотя, конечно, не все) различные компромиссы сложности в области виртуализации сети. Основой этого обсуждения будет триада компромиссов сложности:
Состояние: количество состояний и скорость, с которой изменяется состояние в сети (особенно в плоскости управления).
Оптимизация: оптимальное использование сетевых ресурсов, включая такие вещи, как трафик, следующий по кратчайшему пути через сеть.
Поверхность: количество слоев, глубина их взаимодействия и широта взаимодействия.
Поверхности взаимодействия и группы связей общих рисков
Каждая система виртуализации, когда-либо задуманная, реализованная и развернутая, создает в некотором роде общий риск. Например, рассмотрим одну линию, по которой передается несколько виртуальных каналов, каждый из которых передает трафик. Должно быть очевидным (на самом деле тривиальным) наблюдение, что в случае отказа одного физического канала произойдет сбой всех виртуальных каналов. Конечно, вы можете просто перенаправить виртуальные каналы на другой физический канал. Правильно? Может быть, а может и нет. Рисунок 1 иллюстрирует это.
С точки зрения A и D, есть две линии, доступные через B и C, каждая из которых обеспечивает независимое соединение между хостом и сервером. В действительности, однако, и провайдер 1, и провайдер 2 приобрели виртуальные каналы через единственное соединение у провайдера 3. Когда единственное соединение в сети провайдера 3 выходит из строя, трафик может быть перенаправлен с основного пути через провайдера 1 на путь через провайдера. 2, но поскольку оба канала используют одну и ту же физическую инфраструктуру, ни одна из них не сможет передавать трафик.
Говорят, что эти два звена в этой ситуации разделяют одну общую судьбу, потому что они являются частью Shared Risk Link Group (SRLG). Можно найти и обойти SRLG или ситуации с shared fate, но это усложняет плоскость управления и/или управление сетью. Например, невозможно обнаружить эти shared fate без ручного тестирования различных ситуаций отказа на физическом уровне или изучения сетевых карт, чтобы найти места, где несколько виртуальных каналов проходят по одному и тому же физическому каналу. В ситуации, описанной на рисунке 1, найти ситуацию с shared fate было бы почти невозможно, поскольку ни один из провайдеров, скорее всего, не скажет вам, что использует линию от второго провайдера, показанного на рисунке как провайдер 3, для предоставления услуг.
Как только эти ситуации с shared fate обнаружены, необходимо предпринять некоторые действия, чтобы избежать серьезного сбоя в работе сети. Обычно для этого требуется либо вводить информацию в процесс проектирования, либо усложнять дизайн, либо вводить информацию в плоскость управления (см. RFC8001 в качестве примера типа сигнализации, необходимой для управления группами SRLG в плоскости управления, спроектированной трафиком). По сути, проблема сводится к следующему набору утверждений:
Виртуализация - это форма абстракции.
Абстракция удаляет информацию о состоянии сети с целью снижения сложности или предоставления услуг за счет реализации политики.
Любое нетривиальное сокращение информации о состоянии сети так или иначе снизит оптимальное использование ресурсов.
Единственным противодействием конечному состоянию из этих трех, является протекание информации через абстракцию, поэтому можно восстановить оптимальное использование ресурсов - в этом случае отказ одного канала не вызывает полного отказа потока трафика через сеть. Единственное решение, таким образом, - сделать абстракцию сквозной абстракцией, что снизит эффективность абстракции при контроле области действия состояния и реализации политики.
Поверхности взаимодействия и наложенные плоскости управления
В сетевой инженерии принято накладывать друг на друга два протокола маршрутизации или две плоскости управления. Хотя это не часто рассматривается как форма виртуализации, на самом деле это просто разделение состояния между двумя различными плоскостями управления для контроля количества состояний и скорости изменения состояний, чтобы уменьшить сложность обеих плоскостей управления. Это также часто встречается при запуске виртуальных наложений в сети, поскольку между головным и хвостовым узлами туннеля будет существовать нижележащая плоскость управления, обеспечивающая достижимость, и плоскость управления наложением, обеспечивающая достижимость в виртуальной топологии. Две наложенные друг на друга плоскости управления будут взаимодействовать иногда неожиданным образом. Для иллюстрации используется рисунок 2.
На рисунке 2:
Каждый маршрутизатор в сети, включая B, C, D и E, использует две плоскости управления (или, если это проще, протоколы маршрутизации, отсюда протокол 1 и протокол 2 на рисунке).
Протокол 1 (оверлей) зависит от протокола 2 (базовый) для обеспечения доступности между маршрутизаторами, на которых работает протокол 1.
Протокол 2 не содержит информации о подключенных устройствах, таких как A и F; вся эта информация передается в протоколе 1.
Протокол 1 требует гораздо больше времени для схождения, чем протокол 2.
Более простой путь от B к E проходит через C, а не через D.
Учитывая этот набор протоколов, предположим, что C на рисунке 2 удален из сети, двум управляющим плоскостям разрешено сходиться, а затем C снова подключается к сети. Каков будет результат? Произойдет следующее:
После удаления C сеть снова объединится с двумя путями в локальной таблице маршрутизации в B:
F доступен через E.
E доступен через D.
После повторного подключения C к сети протокол 2 быстро сойдется.
После повторной конвергенции протокола 2 лучший путь к E с точки зрения B будет через C.
Следовательно, у B теперь будет два маршрута в локальной таблице маршрутизации:
F доступен через E.
E достижимо через C.
B перейдет на новую информацию о маршрутизации и, следовательно, будет отправлять трафик к F через C до того, как протокол 1 сойдется, и, следовательно, до того, как C узнает о наилучшем пути к F.
С момента, когда B начинает пересылку трафика, предназначенного для F в C, и момента, когда протокол 1 сойдется, трафик, предназначенный для F, будет отброшен.
Это довольно простой пример неожиданного взаимодействия наложенных протоколов. Чтобы решить эту проблему, вам необходимо ввести информацию о состоянии конвергенции протокола 1 в протокол 2, или вы должны каким-то образом заставить два протокола сходиться одновременно. В любом случае вы по существу добавляете состояние обратно в два протокола, чтобы учесть их разницу во времени конвергенции, а также создавая поверхность взаимодействия между протоколами.
Примечание: Этот пример описывает фактическое взаимодействие конвергенции между IS-IS и BGP, или протоколом Open Shortest Path First (OSPF) и BGP. Чтобы решить эту проблему, более быстрый протокол настроен на ожидание, пока BGP не сойдется, прежде чем устанавливать какие-либо маршруты в локальной таблице маршрутизации.