По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В качестве меры избыточности можно развернуть вместе несколько устройств ASA от Cisco в отказоустойчивой конфигурации, именуемой как реализация высокой доступности (High Availability). Для реализации данной схемы требуются абсолютно идентичные ASA, то есть чтобы устройства имели идентичное программное обеспечение, лицензирование, память и интерфейсы. Существует три возможных варианта реализации схемы High Availability для защиты от простоев.
Реализация отказоустойчивости Active/Standby: в этой модели только один из брандмауэров отвечает за обработку трафика, в то время как другой становиться "горячим" резервным устройством. Резервное устройство начинает обработку трафика в случае сбоя активного устройства.
Реализация отказоустойчивости Active/Active: в этой модели оба брандмауэра активно обрабатывают трафик как кластер. При выходе из строя одного из устройств, сеть будет продолжать нормально функционировать, так как они имеют одинаковые (дублирующие) настройки.
Данная реализация чуть сложнее и требует использования нескольких контекстных режимов. В режиме множественного контекста можно разделить одно устройство ASA на несколько виртуальных, известных как контексты безопасности. Каждый контекст безопасности действует как независимое устройство со своими собственными политиками, интерфейсами и администраторами. Поэтому несколько контекстов представляются как отдельные автономные устройства.
Для реализации отказоустойчивости Active/Active используются два физических брандмауэра. На каждом из этих брандмауэров настраивается несколько виртуальных брандмауэров или контекстов безопасности. В примере выше в ASA 1 настраиваются контекст безопасности 1 и контекст безопасности 2. Аналогично настраивается и ASA 2:
Следующий шаг состоит в том, чтобы взять виртуальные контексты безопасности и разделить их на отказоустойчивые группы. Отказоустойчивая группа- это просто логическая группа одного или нескольких контекстов безопасности.
Аса-1 определена в качестве основного устройства, активной для отказоустойчивой группы 1. Аналогично, ASA 2 определена как вторичное устройство, активное для отказоустойчивой группы 2. Контексты безопасности разделяются и назначаются следующим образом:
ASA 1:
Контекст безопасности 1 Назначена отказоустойчивая группа 1
Контекст безопасности 2 Назначена отказоустойчивая группа 2
ASA 2:
Контекст безопасности 1 Назначена отказоустойчивая группа 2
Контекст безопасности 2 Назначена отказоустойчивая группа 1
Нагрузка распределяется таким образом, что обе ASA активны. Таким образом достигается избыточность.
Реализация отказоустойчивого кластера: это объединение нескольких ASA в кластеры, действующих как единое логическое устройство. Интеграция и управление по-прежнему работают так, как если бы это было единое устройство, но кластеризация обеспечивает более высокую пропускную способность и избыточность. Это работает в модели slave/master аналогично тому, как работает массив RAID- дисков. Если одно устройство ASA, входящее в кластер, выходит из строя, другое берет на себя операции до тех пор, пока не будет заменен отказавший брандмауэр.
Интерфейсы соединяются с двумя различными коммутаторами, причем виртуальный канал порта соединяет коммутаторы вместе. Это должно быть сделано как на внутренней, так и на внешней зонах безопасности.
Работаете с IP – АТС Asterisk? Тогда этот материал для вас. Говорить будем про отправку уведомлений в VK (Вконтакте) при входящем звонке. От слов к делу.
Получаем access_token
Первым делом, перейдите Developers раздел VK. В хедере (верхнем меню навигации) нажмите Мои приложения после чего нажмите Создать приложение:
Название - дайте имя для вашего аппликейшна. Например, Asterisk;
Платформа - выбираем Standalone-приложение;
Переходим в раздел настроек созданного приложения. Копируем ID приложения, как показано на рисунке ниже:
Отлично. Теперь скопируйте ссылку ниже:
https://oauth.vk.com/authorize?client_id=1234567&scope= offline,messages&redirect_uri=https://oauth.vk.com/blank.html&display=page&v=5.37&response_type=token
Предварительно замените client_id на ваше значение, полученное ранее (ID приложения). VK API спросит разрешения на доступ к некоторым данным:
Если все ОК, то VK вернет нам токен:
Если вы столкнулись с ошибкой вида «{"error":"invalid_request","error_description":"Security Error"}», то перелогиньтесь в вашей учетной записи в VK и повторите попытку
Сохраняем значение и переходим к настройке скрипта на стороне Asterisk.
Адаптация на Asterisk
Реализацию скрипта сделаем на .php. Создайте файл asteriskvk.php и наполните его следующим содержимым:
#!/usr/bin/php -q
<?php
require('phpagi.php');
$agi = new AGI();
$message = "Сейчас поступит звонок с номера: ";
$message .= $agi->request['agi_callerid'];
$id = "ID получателя сообщения";
$token = "Токен";
function send($id , $message, $token)
{
$url = 'https://api.vk.com/method/messages.send';
$params = array(
'user_id' => $id,
'message' => $message,
'access_token' => $token,
'v' => '5.37',
);
$result = file_get_contents($url, false, stream_context_create(array(
'http' => array(
'method' => 'POST',
'header' => 'Content-type: application/x-www-form-urlencoded',
'content' => http_build_query($params)
)
)));
}
send($id, $message, $token);
Скачать скрипт
В скрипте вам необходимо поменять следующие переменные:
$id - идентификатор пользователя, которому будет отправлено сообщение. Помимо user_id, это может быть ID группового чата;
$token - API - токен, который вы получили ранее;
Сохраняйте файл и загрузите в директорию /var/lib/asterisk/agi-bin/ после чего дайте следующие команды в консоли сервера:
chmod 755 /var/lib/asterisk/agi-bin/asteriskvk.php
chown asterisk:asterisk /var/lib/asterisk/agi-bin/asteriskvk.php
dos2unix /var/lib/asterisk/agi-bin/asteriskvk.php
Лезем в диалплан и на входящем маршруте адаптируем простенькую конструкцию:
exten => _.,n,AGI(asteriskvk.php)
Звоним и проверяем:
Сегодня подробно разберёмся в том, как настроить запись телефонных разговоров, проходящих через нашу IP-АТС Asterisk, с помощью графической оболочки FreePBX 13. Данная статья будет так же полезна тем, у кого, по каким то причинам, не записываются телефонные разговоры и они хотят это исправить.
Заглянем в FreePBX
Множество модулей во FreePBX позволяют включить запись телефонных разговоров напрямую, к таким относятся Extensions, Queues, Ring Groups, Inbound Routes. То есть, например, при создании нового внутреннего номера или ринг группы мы можем определить, записывать ли разговоры проходящие через них.
Для этого, в каждом модуле, который позволяет настроить запись, есть раздел Recording Options или Call Recording, в котором доступно 5 режимов записи - Force, Yes, Don't Care, No и Never.
Данные режимы, позволяют определить, как именно будет идти запись в течение "жизни вызова" или call flow. Вы можете спросить - "Зачем в модулях предусмотрено целых 5 режимов? Почему бы просто не оставить: Yes - есть запись, No - записи нет?"
Все дело в том, что звонок может менять свое назначение, например, он может изначально поступить на телефон секретаря Extension, а потом его переведут, например, на отдел продаж Ring Group (цикл звонка и есть call flow), в одном модуле запись может быть включена, а в другом нет и вот чтобы определить, что будет записано и служат эти 5 режимов. Давайте разберёмся подробнее в их логике:
Force и Never заменяют друг друга и имеют высший приоритет чем Yes и No
Yes и No имеют одинаковый приоритет
Когда один и больше Yes или No встречается в call flow, в приоритете всегда будет первое значение.
Последующие опции Yes или No не переопределяют первую.
Force и Never будут всегда переопределять опции, которые установлены ранее.
Force и Never будут всегда заменять друг друга. Например если сначала был установлен Force, а потом встречается Never, то в приоритете будет Never
Force и Never будут всегда заменять предустановленные опции Yes и No
Yes и No никогда не заменять Force и Never
Don’t Care не будет изменять предыдущую опцию.
Чтобы было проще понять логику этих 5 режимов, каждый раз, когда встречается No представляйте себе такую фразу – «Я бы предпочел не записывать эту часть вызова, если раньше мне не говорили записать её», когда Yes, такую фразу – «Я хотел бы записать эту часть вызова, если только ранее я не был предупрежден не делать этого». Если встречаете Force, то представьте такую фразу – «Начать или продолжить запись сейчас же!», а если Never - «Закончить запись сейчас же!». И наконец, если встречаете Don’t Care - «Сейчас ничего менять не нужно»
Следует отметить, что некоторые модули, такие как Conference не имеют опций Force, Don’t Care и Never, а имеют только Yes и No, а некоторые, например, Ring Group наоборот, имеют только опции Force, Don’t Care и Never.
Ещё одной важной функцией записи телефонных разговоров, является запись по требованию - On Demand Recording. С помощью данной функции, администратор IP-АТС может настроить пользователю определенного внутреннего номера Extension, эксклюзивное право включать и выключать запись прямо во время разговора, используя программируемую кнопку на корпусе его телефона или специальный Feature Code, по умолчанию это *1. Для того, чтобы настроить данный функционал, необходимо открыть Applications → Extensions далее открыть вкладку Advanced, прокрутить меню до опции Recording Option и найти поле On Demand Recording
Как видите, On Demand Recording имеет следующие режимы:
Disable - Пользователь внутреннего номера не сможет использовать функцию записи по требованию, не зависимо от того, какой режим имеет вызов Force, Yes, Don't Care, No или Never.Если пользователь попробует ввести специальный Feature Code, то он услышит ответ “access denied” – “доступ запрещен”
Enable - Функция записи по требованию доступна пользователю, но только если звонок имеет режим Yes,No или Don’t Care. Если звонок в режиме Force, или Never, то он услышит “доступ запрещен”
Overrride - Пользователь всегда может включить или выключить запись по требованию, вне зависимости от режима Force, Yes, Don't Care, No или Never.
Теперь, чтобы основательно закрепить материал, давайте рассмотрим пример вызова и посмотрим, как будет меняться режим записи в этом call flow:
Допустим, мы имеем входящий звонок, в правилах входящего маршрута - Inbound Route которого установлен режим записи Yes. В результате генерируется файл записи и запись разговора начинается.
По правилам этого входящего маршрута, вызов переходит в очередь Queue, режим записи которой - Don’t Care - запись продолжается.
В очереди, звонок принимает оператор, в правилах внутреннего номера которого, стоит режим записи входящих звонков (Inbound External Calls) - No. Запись продолжается, потому что перед этим, в первом шаге, на входящем маршруте был установлен режим Yes и он имеет приоритет.
Оператор нажимает *1, в настройках его внутреннего номера On Demand Recording установлен режим - Enable. Запись останавливается.
Оператор переводит звонок на ринг-группу (Ring Group), режим записи которой - Force. Запись продолжается.
В ринг группе, звонок принимает менеджер, в правилах внутреннего номера которого, стоит режим записи входящих звонков (Inbound Internal Calls) - Never. Запись снова остановлена.
Менеджер хочет начать запись и нажимает *1 и слышит в трубке “доступ запрещен”, потому что функция записи по требованию заблокирована режимом Never
Таким образом, если Вы вдруг заметили, что у вас отсутствуют записи каких-либо телефонных разговоров или отдельных их частей, а вы вроде как её включали в настройках, то рекомендуем Вам проследить call flow звонка, в котором нет записи и посмотреть – какой режим включается на каждом из этапов.