По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Желание использовать данные с внешних сервисов это вполне обычная практика. Так как многие из этих сервисов доступны по HTTP(S) (REST API, например), то в этой статье мы хотим показать простой способ обращения к этим сервисам по cURL и обработку данных в случае, если сервер вернет JSON. Все взаимодействия будут выполняться из диалплана.
Простой cURL запрос
В диалплане Asterisk существует функция CURL, которая позволяет получить содержимое WEB или FTP страницы. Синтаксис запроса следующий:
CURL(url,post-data)
url - URL, к которому мы будем выполнять обращение;
post-data - по умолчанию будет выполнен GET – запрос. Если в данном параметре будут указаны различные значения, то будет выполнен POST запрос с указанными в переменной данными;
Например:
exten => _X.,1,Set(C_RESULT=${CURL(//merionet.ru/rest?num=84991234567)})
Здесь мы выполним GET запрос по указанному URL, а результат сохраним в переменной C_RESULT.
Использование HTTPS в запросах
Иногда, HTTPS запросы могут не срабатывать, так как удаленная сторона будет проверять наш SSL – сертификат. Если поставить параметр ssl_verifypeer=0, то такой проверки не будет:
same => n,Set(CURLOPT(ssl_verifypeer)=0)
Как воспользоваться этим в диалплане?
Легко. С помощью функции GotoIf мы можем определить действие, которое отработает на базе результата cURL:
exten => _X.,1,Set(C_RESULT=${CURL(//merionet.ru/rest?num=84991234567)})
same => n,GotoIf($["${C_RESULT}" = "1"]?res1:res2)
same => n(res1),Verbose(CURL Result = 1)
same => n,Hangup
same => n(res2),Verbose(CURL Result != 1)
same => n,Hangup
Указанный код отправит GET - запрос на rest, в котором в параметре num передаст номер звонящего (можно указать соответствующую переменную диалплана Asterisk). В случае, если результатом выполнения запроса будет 1, то мы перейдем к выполнению шага res1, а противоположном случае, res2.
res_json для обработки JSON ответов
На самом деле, для API, является обычной практикой возврат ответа в виде JSON. Поэтому, нам следует преобразовать эти данные перед обработкой их. Для этого мы воспользуемся модулем res_json из JSON библиотеки, который создан для расширения базовых возможностей диалплана с точки зрения обработки JSON.
Почитайте материал об установке данного модуля по этой ссылке.
exten => _X.,1,Set(C_RESULT=${CURL(//merionet.ru/rest.json)})
same => n,Set(result=${JSONELEMENT(C_RESULT, result/somefield)})
same => n,GotoIf($["${result}" = "1"]?res1:res2)
same => n(res1),Verbose(CURL Result = 1)
same => n,Hangup
same => n(res2),Verbose(CURL Result != 1)
same => n,Hangup
Для теста, создайте у себя на web – сервере файл rest.json со следующим содержанием:
{
"result": {
"somefield": 1
}
}
В предыдущем материале мы рассмотрели, как работает Интернет на базовом уровне, включая взаимодействие между клиентом (вашим компьютером) и сервером (другим компьютером, который отвечает на запросы клиента о веб-сайтах).
В этой же части рассмотрим, как устроены клиент, сервер и веб-приложение, что мы можем удобно серфить в Интернете.
Модель клиент-сервер
Эта идея взаимодействия клиента и сервера по сети называется моделью «клиент-сервер». Это делает возможным просмотр веб-сайтов (например, сайт wiki.merionet.ru) и взаимодействие с веб-приложением (как Gmail).
На самом деле, модель клиент-сервер - это ни что иное, как способ описать отношения между клиентом и сервером в веб-приложении. Это детали того, как информация переходит от одного конца к другому, где картина усложняется.
Базовая конфигурация веб-приложения
Существует сотни способов настройки веб-приложения. При этом большинство из них следуют одной и той же базовой структуре: клиент, сервер, база данных.
Клиент
Клиент - это то, с чем взаимодействует пользователь. Так что «клиентский» код отвечает за большую часть того, что на самом деле видит пользователь. Это включает в себя:
Определение структуры веб-страницы
Настройка внешнего вида веб-страницы
Реализация механизма пользовательского взаимодействия (нажатие кнопок, ввод текста и т.д.)
Структура: Макет и содержимое веб-страницы определяются с помощью HTML (обычно HTML 5, если речь идет о современных веб-приложениях, но это другая история.)
HTML означает язык гипертекстовой разметки (Hypertext Markup Language). Он позволяет описать основную физическую структуру документа с помощью HTML-тэгов. Каждый HTML-тэг описывает определенный элемент документа.
Например:
Содержимое тега «<h1>» описывает заголовок.
Содержимое тега «<p>» описывает абзац.
Содержимое тега «<button>» описывает кнопку.
И так далее...
Веб-браузер использует эти HTML-тэги для определения способа отображения документа.
Look and Feel: Чтобы определить внешний вид веб-страницы, веб-разработчики используют CSS, который расшифровывается как каскадные таблицы стилей (Cascading Style Sheets). CSS - это язык, который позволяет описать стиль элементов, определенных в HTML, позволяя изменять шрифт, цвет, макет, простые анимации и другие поверхностные элементы.
Стили для указанной выше HTML-страницы можно задать следующим образом:
Взаимодействие с пользователем: Наконец, для реализации механизма взаимодействия с пользователем, на сцену выходит JavaScript.
Например, если вы хотите что-то сделать, когда пользователь нажимает кнопку, вы можете сделать что-то подобное:
Иногда взаимодействие с пользователем, может быть реализовано без необходимости обращения к вашему серверу - отсюда и термин "JavaScript на стороне клиента". Другие типы взаимодействия требуют отправки запросов на сервер для обработки.
Например, если пользователь публикует комментарий в потоке, может потребоваться сохранить этот комментарий в базе данных, чтобы весь материал был структурирован и собран в одном месте. Таким образом, вы отправляете запрос на сервер с новым комментарием и идентификатором пользователя, а сервер прослушивает эти запросы и обрабатывает их соответствующим образом.
Сервер
Сервер в веб-приложении прослушивает запросы, поступающие от клиента. При настройке HTTP-сервера он должен прослушивать конкретный номер порта. Номер порта всегда связан с IP-адресом компьютера.
Вы можете рассматривать порты как отдельные каналы на каждом компьютере, которые можно использовать для выполнения различных задач: один порт может быть использован для серфинга на wiki.merionet.ru, в то время как через другой получаете электронную почту. Это возможно, поскольку каждое из приложений (веб-браузер и клиент электронной почты) использует разные номера портов.
После настройки HTTP-сервера для прослушивания определенного порта сервер ожидает клиентские запросов, поступающие на этот порт, выполняет все действия, указанные в запросе, и отправляет все запрошенные данные через HTTP-ответ.
База данных
Базы данных – это подвалы веб-архитектуры - большинство из нас боятся туда спускаться, но они критически важны для прочного фундамента. База данных - это место для хранения информации, чтобы к ней можно было легко обращаться, управлять и обновлять.
Например, при создании сайта в социальных сетях можно использовать базу данных для хранения сведений о пользователях, публикациях и комментариях. Когда посетитель запрашивает страницу, данные, вставленные на страницу, поступают из базы данных сайта, что позволяет нам воспринимать взаимодействие пользователей в реальном времени как должное на таких сайтах, как Facebook или в таких приложениях, как Gmail.
Как масштабировать простое веб-приложение
Вышеописанная конфигурация отлично подходит для простых приложений. Но по мере роста приложения один сервер не сможет обрабатывать тысячи - если не миллионы - одновременных запросов от посетителей.
Чтобы выполнить масштабирование в соответствии с этими большими объемами, можно распределить входящий трафик между группой внутренних серверов.
Здесь все становится интересно. Имеется несколько серверов, каждый из которых имеет собственный IP-адрес. Итак, как сервер доменных имен (DNS) определяет, на какой экземпляр вашего приложения отправить трафик?
Ответ очевиден - никак. Управление всеми этими отдельными экземплярами приложения происходит через средство балансировки нагрузки.
Подсистема балансировки нагрузки действует как гаишник, который маршрутизирует клиентские запросы по серверам как можно быстрее и эффективнее, насколько это возможно.
Поскольку вы не можете транслировать IP-адреса всех экземпляров сервера, вы создаете виртуальный IP-адрес, который транслируется клиентам. Этот виртуальный IP-адрес указывает на подсистему балансировки нагрузки. Таким образом, когда DNS ищет ваш сайт, он указывает на балансировщик нагрузки. Затем подсистема балансировки нагрузки перескакивает для распределения трафика на различные внутренние серверы в реальном времени.
Возможно, вам интересно, как подсистема балансировки нагрузки узнаёт, на какой сервер следует отправлять трафик. Ответ: алгоритмы.
Один популярный алгоритм, Round Robin, включает равномерное распределение входящих запросов по ферме серверов (все доступные серверы). Вы обычно выбираете такой подход, если все ваши серверы имеют одинаковую скорость обработки и память.
С помощью другого алгоритма, Least Connections, следующий запрос отправляется на сервер с наименьшим количеством активных соединений.
Существует гораздо больше алгоритмов, которые вы можете реализовать, в зависимости от ваших потребностей.
Теперь поток трафика выглядит следующим образом:
Службы
Итак, мы решили проблему трафика, создав пулы серверов и балансировщик нагрузки для управления ими.
Но одной репликация серверов может быть недостаточно для обслуживания приложения по мере его роста. По мере добавления дополнительных функциональных возможностей в приложение необходимо поддерживать тот же монолитный сервер, пока он продолжает расти. Для решения этой проблемы нам нужен способ разобщить функциональные возможности сервера.
Здесь и появляется идея служб. Служба является просто другим сервером, за исключением того, что она взаимодействует только с другими серверами, в отличие от традиционного веб-сервера, который взаимодействует с клиентами.
Каждая служба имеет автономную единицу функциональности, такую как авторизация пользователей или предоставление функции поиска. Службы позволяют разбить один веб-сервер на несколько служб, каждая из которых выполняет отдельные функции.
Основное преимущество разделения одного сервера на множество сервисов заключается в том, что он позволяет масштабировать сервисы полностью независимо.
Другое преимущество здесь заключается в том, что он позволяет командам внутри компании работать независимо над конкретной услугой, а не иметь 10, 100 или даже 1000 инженеров, работающих на одном монолитном сервере, который быстро становится кошмаром для менеджера проекта.
Краткое примечание: эта концепция балансировщиков нагрузки и пулов внутренних серверов и служб становится очень сложной, поскольку вы масштабируете все больше и больше серверов в вашем приложении. Это особенно сложно с такими вещами, как, например, сохранение сеанса, обработка отправки нескольких запросов от клиента на один и тот же сервер в течение сеанса, развертывания решения для балансировки нагрузки. Такие продвинутые темы не будет затрагивать в данном материале.
Сети доставки контента (Conten Delivery Network – CDN)
Все вышеперечисленное отлично подходит для масштабирования трафика, но приложение все еще централизовано в одном месте. Когда ваши пользователи начинают посещать ваш сайт из других концов страны или с другого конца мира, они могут столкнуться с длительной задержкой из-за увеличенного расстояния между клиентом и сервером. Ведь речь идет о "всемирной паутине" - не о "местной соседней паутине".
Популярная тактика решения этой проблемы - использование сети доставки контента (CDN). CDN - это большая распределенная система «прокси» серверов, развернутая во многих центрах обработки данных. Прокси-сервер - это просто сервер, который действует как посредник между клиентом и сервером.
Компании с большим объемом распределенного трафика могут платить CDN-компаниям за доставку контента конечным пользователям с помощью серверов CDN. CDN имеет тысячи серверов, расположенных в стратегических географических точках по всему миру.
Давайте сравним, как веб-сайт работает с CDN и без него.
Как мы уже говорили в разделе 1, для типичного веб-сайта доменное имя URL преобразуется в IP-адрес сервера хоста.
Однако если клиент использует CDN, доменное имя URL преобразуется в IP-адрес пограничного сервера, принадлежащего CDN. Затем CDN доставляет веб-контент пользователям клиента, не затрагивая серверы клиента.
CDN может сделать это, сохраняя копии часто используемых элементов, таких как HTML, CSS, загрузки программного обеспечения и медиаобъектов с серверов клиентов.
Главная цель - расположить контент сайта как можно ближе к конечному пользователю. В итоге пользователь получает более быструю загрузку сайта.
Прогресс не стоит на месте и постепенно, телефонные станции на базе IP вытесняют устаревшие аналоговые АТС. При миграции с аналоговой на IP – АТС, основной головной болью для бизнеса является сохранение телефонной емкости, которая была подключена к аналоговой АТС и к которой так привыкли постоянные клиенты. В данном случае на помощь приходит FXO шлюз.
Забегая вперед хочется отметить, что процесс подключения аналоговых линий всегда сложен: возникает множество проблем с корректной передачей CallerID, определением Busy Tones (сигналов занято), шумами или помехами на линии и прочими неприятностями.
Итак, если вас не отпугивает вышеперечисленные трудности, то мы с радостью спешим рассказать как настроить бюджетный VoIP шлюз D-Link DVG-7111S и подключить его к IP-АТС Asterisk. Данная статья будет полезна тем, кто имеет аналоговые телефонные линии и хочет скрестить их сетью VoIP.
Что такое FXO и FXS?
Зачастую, некоторые компании, по тем или иным причинам, не могут отказаться от использования старых аналоговых линий. Причин может быть множество, например, провайдер может отказаться переводить на протокол SIP номер, который многие годы знают все заказчики или невозможность миграции со старой мини-АТС. Именно для таких случаев необходим VoIP-шлюз, который позволит состыковать устройства разных поколений.
Разберемся с терминологией. Для соединения IP-АТС с аналоговыми линиями служат интерфейсы FXO (Foreign eXchange Office) и FXS (Foreign Exchange Station). Интерфейс FXS – это порт, с помощью которого аналоговый абонент подключается к аналоговой телефонной станции. Простейшим примером может служить телефонная розетка в стене у Вас дома. FXO – это интерфейс, в который включаются аналоговые линии. Следовательно, любая аналоговая линия имеет два конца, на одном из который интерфейс FXS (АТС), а на другом FXO (Телефон).
Другими словами, чтобы было совсем понятно:
FXS - если вам требуется подключить аналоговый телефон к IP – АТС, то воспользуйтесь FXS портом (шлюзом)
FXO - если вам требуется подключить аналоговую линию от провайдера к IP – АТС, то воспользуйтесь FXO портом (шлюзом)
Таким образом, для того чтобы скрестить сеть VoIP с аналоговой нам нужно иметь такое адаптирующее устройство, которое бы преобразовывало сигналы аналоговой телефонной линии в сигналы VoIP.
Настройка
В нашем примере мы имеем в распоряжении: аналоговую линию от провайдера услуг, IP-АТС Asterisk и шлюз D-Link DVG-7111S.
Первое, что необходимо сделать – включить шлюз в одну сеть с IP-АТС Asterisk с помощью интерфейса WAN, порт LAN подключить в локальный свич, а также подключить имеющуюся аналоговую линию в порт FXO на шлюзе. Теперь шлюз можно найти по адресу 192.168.8.254, только предварительно нужно на управляющей АРМ настроить адрес 192.168.8.1. Перед нами открывается вэб-интерфейс, через который можно управлять шлюзом. Стандартный логин admin без пароля.
Теперь необходимо сконфигурировать дополнительные сетевые настройки. Для этого переходим в раздел Setup -> Internet Setup и настраиваем новый адрес шлюза из той же сети, в которой находится Asterisk, а также адреса серверов DNS. Жмём Apply
Далее переходим на вкладку VoIP Setup и настраиваем следующие параметры:
PHONE 1 - FXS Настраивается если у вас есть отдельный аналоговый телефон. Сюда заносим его Extension, который зарегистрирован на Asterisk.
В разделе PHONE 2 - FXO настраиваются параметры имеющейся аналоговой линии в соответствии с настройками транка на Asterisk. Номер и пароль на шлюзе и на Asterisk должна совпадать.
В разделе SIP PROXY SERVER настраиваются параметры подключения к IP-Атс Asterisk. Указываем IP-адрес нашего сервера, порт (по умолчанию 5060) и время регистрации TTL. Нажимаем Apply.
Во вкладке LAN Setup выбираем режим Bridge, всё остальное оставляем без изменений.
Переходим в раздел ADVANCED -> VOIP CODECS и настраиваем нужный приоритет голосовых кодеков.
В разделе CPT/ Cadence рекомендуем выключить опцию BTC, поскольку разные провайдеры могут по-разному отдавать сигнал “Занято” это может являться причиной внезапных обрывов.
В разделе HOT LINE включаем данную функцию и вписываем номер телефонной линии. Теперь, при звонке из ТФоП, шлюз сам наберет данный номер с минимальной задержкой и вызов пойдёт через Asterisk.
На этом настройка шлюза завершена, рекомендуем провести следующий набор действий
MAINTENANCE -> Backup and Restore -> System--Save and Reboot -> Save all settings -> Reboot
Настройка FreePBX
Теперь необходимо на IP-АТС Asterisk создать соответствующий транк. В нашем случае, транк для подключения аналоговой линии от D-Link будет выглядеть так:
В разделе sip Settings -> Outgoing указываем адрес, который настраивали на шлюзе
host=192.168.1.2 //ip - адрес шлюза
port=5060
context=from-trunk
qualify=yes
type=peer
insecure=no
В разделе sip Settings -> Incoming настраиваем такие же параметры аналоговой линии, которые настраивали на шлюзе. Номер и пароль должны совпадать.
host=dynamic
username=495123456
secret=тут_ваш_пароль
context=from-trunk
qualify=yes
type=friend
insecure=no
Готово! Осталось только настроить входящую и исходящую маршрутизацию. О ее настройке можете почитать по ссылке ниже:
Настройка маршрутизации вызовов