По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Очень важно знать номера портов, используемых устройствами, с которыми мы работаем. Мы уже рассказывали про то, какие порты используются в Asterisk, a сегодня мы расскажем какие порты использует АТС и ее компоненты от компании Cisco.
Если вам известны номера портов, устранение неполадок становится немного проще. Номера портов используются для определения того, на какой протокол должен быть направлен входящий трафик. Порты назначаются при установлении сеанса и освобождаются по окончании сеанса.
Список портов Cisco Unified Communications Manager, Voice Gateway и Gatekeeper
Итак, давайте посмотрим, какие основные порты используются между голосовыми устройствами, такими как Cisco Unified Communications Manager, Voice Gateway и Gatekeeper
SIP сообщенияTCP/UDP 5060SIP сообщенияTLS(TCP) 5061Real-Time Protocol (RTP)UDP 16384 – 32767Secure Real-Time Protocol (SRTP)UDP 16384 – 32767Skinny Client Protocol (SCCP)TCP 2000Secure Skinny Client Protocol (SCCPS)TCP 2443Media Gateway Control Protocol (MGCP) управление шлюзомUDP 2427Media Gateway Control Protocol (MGCP) соединение со шлюзамTCP 2428MGCP GatewayUDP 2427, 2428 H.225 Signalling Services ICT и H323 GatekeeperTCP 1720Gatekeeper (H.225) DiscoveryTCP 1718Gatekeeper (H.225) RASUDP 1719H.245TCP 5555-5574Gatekeeper Discovery (RAS)UDP 1719Q.931 signaling от Voice GatewayTCP 2727Q.931 call SetupTCP 1720SyslogTCP 514
Сегодня хотим поговорить про модуль «Web Callback» для FreePBX 13. Модуль является платным и стоит $50. Платеж единоразовый. В сравнении с популярными сервисами обратного звонка, покупка модуля окупается в среднем за полгода. Интересно? Тогда читайте ниже: настройка и адаптация стиля под свой сайт.
Процесс настройки
Данный модуль находится в меню Applications. Он позволяет легко и просто добавить HTML “Позвоните Мне” код на ваш веб-сайт. Посетители просто вводят свой телефонный номер для соединения с нужной вам очередью или ринг-группой. Далее, этот модуль позволяет выставить префикс для поступающего номера, что позволит определить, что вызов идет именно с модуля обратного звонка. Так же можно указать правила набора номера, для определения номеров, на которые можно совершить вызов. Как только вы установите направление для вызова и подтвердите настройки модуля, вы получите HTML-код для добавления на вашу страницу.
Итак, пошаговый процесс создания кода для помещения на веб-страницу:
Нажмите на + Add Web Callback
Заполните поля:
Описание полей:
Name – Название коллбэка
CID Prepend – Префикс при определении номера, в данном случае – «CALLBACK»
Number Prepend – Префикс при наборе номера
Dial Matches – Маска, для определения номеров, которые можно набирать
Icon – Выбор иконки из предложенных
Valid Message – Сообщение, которое высвечивается при правильном наборе
Invalid Message – Сообщение, которое высвечивается при неправильном наборе
Error Message – Сообщение, которое высвечивается, если произошла какая-либо ошибка
Destination – Направление вызова, в данном случае – ринг-группа с названием “web callback”
HTML Code – Код, который появится после сохранения настроек
Нажмите Submit
Далее нужно только добавить получившийся код на сайт и пользоваться. Только надо учитывать два момента: первый – данный модуль надо купить у Shmooze и иметь публичный адрес вашей АТС/или пробрасывать порты.
Изменения стиля формы обратного звонка
После того как мы создали форму обратного звонка на сайт, нам необходимо доработать ее внешне, так как встроенные формы имеют не привлекательный дизайн. Открываем файл /etc/schmooze/wcb.html и добавляем в него следующий код:
<style type="text/css">
#frame {
background-image: url('/admin/images/webcallback.png');
background-repeat: no-repeat;
background-size: 200px;
height: 65px;
cursor: pointer;
cursor: hand;
}
#webcallbackinput {
position: relative;
left: 66px;
top: 30px;
width: 125px;
}
</style>
<div id="frame">
<input type="text" name="num" placeholder="Укажите ваш номер" id="webcallbackinput" value="">
<input type="hidden" id="dest" value="http://1.2.3.4:12345/wcb.php">
<input type="hidden" id="i" value="1">
</div>
<div id="link"></div>
<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js"></script>
<script type="text/javascript">
$(document).ready(function(){
$('#frame').click(function(){
if ($('#webcallbackinput').val()) {
var valid_msg = 'Спасибо. Мы уже звоним Вам!';
var invalid_msg = 'Ошибка. Пожалуйста, укажите все параметры согласно требованию полей';
var but = $(this);
$.ajax({
url: $('#dest').val(),
type: 'post',
data: {p: $('#webcallbackinput').val(), i: $('#i').val()},
cache: false,
success: function(data, b, c) {
data = $.parseJSON(data);
switch (data.Response) {
case 'Error':
switch (data.Message) {
case 'Originate failed':
alert(invalid_msg);
break;
default:
alert(data.Message);
break;
}
break;
case 'Success':
alert(valid_msg);
break;
default:
break;
}
},
error: function(a, b, c) {
alert(invalid_msg);
}
})
}
})
});
</script>
Обратите внимание, чтобы форма работала корректно, вам необходимо указать корректное значение параметра value в поле input ниже (это значение было сгенерировано на этапе настройки в поле) и значение параметр id в поле, следующем следом за ним. В нашем примере, id=2:
<input type="hidden" id="dest" value="http://1.2.3.4:12345/wcb.php">
<input type="hidden" id="i" value="1">
В данном примере указано значение http://1.2.3.4:12345/wcb.php , где значение 1.2.3.4 – внешний IP – адрес нашего маршрутизатора, а 12345 – это проброс нестандартного порта в наш Asterisk. Рекомендуем в настройках проброшенного порта указать разрешенные сети (source address), с которых можно подключиться через этот порт. Это необходимо в целях безопасности, если ваш Web – сервер находится не в локальной сети, а например, на хостинге
Так же здесь вы можете настроить сообщения, которые будут показаны пользователю при успешном и неуспешном исходе вызова обратного звонка
var valid_msg = 'Спасибо. Мы уже звоним Вам!';
var invalid_msg = 'Ошибка. Пожалуйста, укажите все параметры согласно требованию полей ';
На самом деле поиск DNS это не то, что требует частого внимания. Но иногда приходится заботиться об этом. Например, если у вашего провайдера слабые сервера или же в вашей сети часто происходят DNS обращения, то нужно настроить локальный кэширующий DNS сервер.
Как кэширующий DNS-сервер может пригодиться?
Кэширующий DNS-сервер занимается обработкой DNS запросов, которые выполняет ваша система, затем сохраняет результаты в памяти или кэширует их. В следующий раз, когда система посылает DNS запрос для того же адреса, то локальный сервер почти мгновенно выдает результат.
Эта идея может показаться бесполезной. Подумаешь, какие-то там секунды. Но если DNS сервера провайдера тратят много времени на разрешение имени, то в результате падает скорость Интернет серфинга. Например, домашняя страница новостного канала MSNBC для корректной работы обращается более чем к 100 уникальным доменам. Даже если на запрос тратится одна десятая секунды, в итоге получается 10 секунд ожидания, что по нынешним меркам слишком много.
Локальный кэширующий DNS увеличивает скорость не только дома или в офисе, он также помогает работе серверов. Например, у вас есть почтовый сервер с анти-спам фильтром, который выполняет очень много DNS запросов. Локальный кэш намного увеличить скорость его работы.
И наконец, system-resolved поддерживает новейшие стандарты вроде DNSSEC и DNSoverTLS или DoT. Эти технологии увеличивают безопасность при работе в Интренет.
Какой локальный кэширующий сервер выбрать?
В этом руководстве будет использован сервер systemd-resolved. Эта утилита является частью набора управления системой systemd. Если в вашей системе используется systemd, а большинство дистрибутивов Linux используют это, то в системе уже установлен systemd-resolved, но не запущен. Большинство систем не используют эту утилиту.
systemd-resolved запускает небольшой локальный кэширующий DNS-сервер, который мы настроим на запуск при загрузке системы. Затем мы изменим конфигурацию всей системы так, чтобы DNS запросы шли на локальный сервер.
Как проверить используется ли systemd-resolved?
В некоторых дистрибутивах, например Ubuntu 19.04, по умолчанию используется systemd-resolved.
Если у вас уже запущен systemd-resolved, тогда не нужно что-то настраивать в системе. Но нужно проверить на корректность утилит управления сетевыми настройками, такие как NetworkManager, так как они могут игнорировать системные настройки сети.
Перед тем как перейти к следующему разделу проверьте запущен ли в вашей системе systemd-resolved:
$ resolvectl status
Если в ответ получите сообщение ниже, значит в системе не настроен systemd-resolved:
$ resolvectl status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
И наоборот, если на выходе видите что-то подобное, то systemd-resolved уже работает:
Global
LLMNR setting: yes
MulticastDNS setting: yes
DNSOverTLS setting: opportunistic
DNSSEC setting: allow-downgrade
DNSSEC supported: no
Current DNS Server: 1.1.1.1
DNS Servers: 1.1.1.1
1.0.0.1
Включение и настройка systemd-resolved
Отдельно устанавливать systemd-resolved не нужно, так как этот сервис является частью systemd. Всё что нужно сделать это запустить его и добавить в автозагрузку. Для включения данной службы введите команду ниже:
$ sudo systemctl start systemd-resolved.service
Далее нужно ввести следующую команду, чтобы добавить службу в автозапуск.
$ sudo systemctl enable systemd-resolved.service
И наконец нужно прописать DNS сервера, куда будет обращаться локальный сервер для разрешения имен. Есть много разных сервисов, но приведённые ниже самые быстрые, бесплатные и оба поддерживают DNSSEC и DoT:
Google Public DNS
8.8.8.8
8.8.4.4
Cloudflare Public DNS
1.1.1.1
1.0.0.1
Для этого откройте конфигурационный файл systemd-resolved любым текстовым редактором:
$ sudo nano /etc/systemd/resolved.conf
Отредактируйте строку, которая начинается на:
#DNS=
И пропишите одну из вышеуказанных пар. Мы используем Cloudflare Public DNS:
DNS=1.1.1.1 1.0.0.1
Сохраните изменения и перезапустите службу systemd-resolved:
$ sudo systemctl restart systemd-resolved.service
Итак, systemd-resolved уже запущен и готов для выполнения быстрых и безопасных DNS запросов, как только мы настроим систему соответствующим образом.
Настройка системы для использования systemd-resolved
Есть несколько путей настройки системы на использование локального DNS сервера. Мы рассмотрим два наиболее используемых метода. Первый – рекомендуемый метод, второй конфигурация в режиме совместимости. Разница в том, как будет обрабатываться файл /etc/resolv.conf.
В файле /etc/resolv.conf содержатся IP адреса серверов разрешения имен, которые используются программами. Программы при необходимости разрешения доменного имени обращаются к этому файлу в поисках адресов серверов разрешения имен.
Итак, первый метод конфигурации заключается в создании символьной ссылки на /run/systemd/resolve/stub-resolv.conf. В этом случае файл /etc/resolv.conf управляется службой systemd-resolved.
Это может вызвать проблемы в том случае, если другие программы пытаются управлять файлом /etc/resolv.conf. Режим совместимости оставляет /etc/resolv.conf не тронутым, позволяя программам управлять им. В этом режиме, в настройках программ, управляющих файлом /etc/resolv.conf в качестве системного сервера разрешения имен должен быть указан IP 127.0.0.53.
Конфигурация в рекомендуемом режиме
При этом режиме конфигурация проводится вручную. Сначала нужно удалить или переименоваться оригинальный файл /etc/resolv.conf. Лучше переименовать, чтобы при необходимости можно было использовать информацию в нем.
$ sudo mv /etc/resolv.conf /etc/resolv.conf.original
Затем создаем символьную ссылку:
$ sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
И наконец перезапускаем службу systemd-resolved:
$ sudo systemctl restart systemd-resolved.service
Настройка в режиме совместимости
В режиме совместимости, нужно убедиться, что локальный сервер разрешения имен system-resolved запущен и используется системными службами. Откройте файл /etc/resolv.conf любым редактором:
$ sudo nano /etc/resolv.conf
Удалите все строки, которые содержать ключевое слово nameserver и добавьте одну единственную строку:
nameserver 127.0.0.53
Этот файл мажет быть изменён любой программой. Чтобы предотвратить это нужно настроить программы так, чтобы в качестве DNS они использовали адрес 127.0.0.53.
Отладка systemd-resolved
Посмотреть, как система выполняет DNS запросы после внесённых изменений сложно. Самый эффективный метод – это включить режим отладки для службы systemd-resolved, а затем просмотреть файл логов.
systemd-resolved можно перевести в режим отладки созданием специального служебного файла, в котором содержатся настройки отладки. Делается это следующей командой:
$ sudo systemctl edit systemd-resolved.service
Вставьте в файл следующие строки:
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
После этого служба systemd-resolved автоматический перезапуститься. Откройте второй терминал и просмотрите логи в journald:
$ sudo journalctl -f -u systemd-resolved
Строка, которая содержит слова “Using DNS server” показывает, какой DNS сервер используется для разрешения имён. В нашем случае это DNS сервера Cloudflare
Using DNS server 1.1.1.1 for transaction 19995.
Слова “Cache miss” в начале строки означает, что для данного домена нет закэшированной информации:
Cache miss for example.com IN SOA
И наконец слова “Positive cache” в начале строки означает, что systemd-resolved уже запрашивал информацию об этом домене и теперь ответы возвращает из кэша:
Positive cache hit for example.com IN A
Не забудьте отключить режим отладки, так как в это время создается большой файл логов. Сделать это можно командой:
$ sudo systemctl edit systemd-resolved.service
а затем удалить добавленные выше две строки.
Использование защищенных DNS запросов
systemd-resolved один из немногих DNS серверов, которые поддерживает DNSSEC и DNSoverTLS. Эта два механизма позволяют убедиться, что полученная DNS информация подлинная (DNSSEC) и он не был изменён по пути (DoT).
Эти функции легко включаются редактированием основного конфигурационного файла system-resolved:
$ sudo nano /etc/systemd/resolved.conf
Измените файл следующим образом:
DNSSEC=allow-downgrade
DNSOverTLS=opportunistic
Сохраните изменения и перезапустите службу systemd-resolved.
$ sudo systemctl restart systemd-resolved.service
Пока прописанные DNS сервера поддерживают эти две функции все DNS запросы будут защищены. DNS сервера Google и CloudFlare поддерживают эти механизмы защиты.
Заключение
Теперь ваша система будет выполнять DNS запросы быстро и эффективно даже если провайдер не работает достаточно быстро. Кроме этого, ваша цифровая жизнь лучше защищена новейшими механизмами защиты DNS запросов.