По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Дорогой читатель! В поисках полезной автоматизации и кастомизации своего Asterisk продвинутые администраторы прибегают к использованию различных скриптов. Это может быть PHP, Perl C, Pascal или Shell. Для использования скриптов, написанных на одном из перечисленных языков программирования в диалплане Asterisk используется AGI (Asterisk Gateway Interface) – о нем и поговорим.
Как это работает?
AGI - это прослойка между скриптом и диалпланом (планом набора) в Asterisk. В скрипт мы можем передавать различные переменные, а можем получать какие - то значения из скрипта. Когда Asterisk инициирует запуск скрипта через AGI, он передает в него набор переменных. Все переменные обладают префиксом agi_:
Переменная
Описание
Пример
agi_request
Имя файла исполняемого скрипта
trunk.php
agi_channel
Канал, инициирующий звонок
Local/89123456789@from-internal-00000002;2
agi_language
Языковой код
en
agi_type
Тип канала, инициирующий вызов
Local
agi_uniqueid
Уникальный идентификатор звонка
1497364935.15
agi_version
Версия Asterisk
13.10.0
agi_callerid
Номер звонящего (CID Number)
89123456789
agi_calleridname
Имя звонящего (CID Name)
89123456789
agi_dnid
Набранный номер
unknown
agi_context
Контекст обработки вызова
macro-dialout-trunk
Как вызвать AGI в диалплане?
Вызвать AGI скрипт очень просто: предварительно, загрузите скрипт в директорию /var/lib/asterisk/agi-bin/. После этого, скрипту необходимо дать права и собственника. Предположим, наш скрипт называется trunk.php:
chmod 755 /var/lib/asterisk/agi-bin/trunk.php
chown asterisk:asterisk /var/lib/asterisk/agi-bin/trunk.php
Теперь, чтобы скрипт был вызван в диалплане, просто добавьте следующую конструкцию:
exten => 1333,n,AGI(trunk.php)
Просто, не правда ли? А если мы хотим передать переменную в скрипт? Просто добавьте ее после запятой:
exten => 1333,n,AGI(trunk.php, ${CALLERID(number)})
А как же написать скрипт?
Теперь к самому скрипту – напишем его на PHP. Пусть нам нужно отправлять письмо с номером звонящего. Выглядеть скрипт будет так:
#!/usr/bin/php -q
<?php
require('phpagi.php');
$agi = new AGI(); //подключаем файл phpagi.php – 1 и 2 строки обязательны в любом скрипте
$cid = $agi->request['agi_callerid']; // берем из AGI номер звонящего
mail("info@merionet.ru", 'Привет!', 'Вот и номер звонящего:', $cid); //отправляем в письме
Вот и все. Нам будет приходить на почту письмо с номером звонящего – прокачав данный функционал можно отслеживать пропущенные вызовы, например.
The HyperText Transfer Protocol, или HTTP, это самый распространенный в мире протокол уровня приложений модели OSI на сегодняшний день. Протокол HTTP образует пространство, которое большинство людей называют сетью Интернет. Основной задачей протокола HTTP является извлечение HTML (HyperText Markup Language) или любых других документов с WEB – сайтов через сеть Интернет. Каждый раз, когда вы открываете интернет - браузер, в дело вступает протокол HTTP, оперируя поверх стека протоколов TCP/IP.
Протокол HTTP был впервые выпущен на свет вначале 1990 года и имел три версии:
HTTP/0.9: Простейшая реализация протокола, позволяющая только получать WEB – страницы
HTTP/1.0: Даная версия обнародована Инженерным советом Интернета (Internet Engineering Task Force, IETF) в рамках RFC 1945 в 1996 году. В данной версии было добавлено большое количество дополнительных полей, именуемых заголовками в этой спецификации. Эта версия протокола расширяла взаимодействие между клиентом и сервером.
HTTP/1.1: Версия 1.1 определена в RFC 2068 советом IETF как доработанная и улучшенная версия протокола HTTP поверх спецификации 1.0. Одним из самых заметных улучшений версии 1.1 по сравнению с 1.0 стало внедрений методов постоянных TCP сессий, возможность отправки нескольких HTTP запросов одновременно, не дожидаясь ответа сервера (повышение скорости работы) и реализация алгоритма кэширования.
На сегодняшний день, большинство современных интернет – браузеров поддерживают обе версии 1.0 и 1.1 протокола HTTP. Важно отметить, что современные браузеры обеспечивают полную совместимость данных версий, то есть при условии отправки запрос версии 1.0 и получения ответа 1.1, данные будут успешно обработаны.
Получение веб страницы по HTTP
Рассмотрим процесс получения WEB – страницы обычным интернет браузером с сервера. Любая HTML страница содержит в себе множество объектов, тэгов и изображений. В целом, HTML можно рассматривать как структуру страницы, в которой все объекты расставлены на свои места. В свою очередь, интернет – браузер получает инструкции в рамках этого HTML документа, откуда брать шрифты, цвета, фон и прочие элементы оформления страницы. Порядок таков:
Клиент (браузер) отправляет запрос на WEB – сервер для запрашиваемой страницы.
Сервер анализирует запрос и отправляет HTML код необходимый для формирования страницы.
Клиент начинает анализировать полученный документ и формировать WEB – страницу.
Клиент в последующих запросах будет формировать изображения, видео или любую другую форму внутренних объектов из источников WEB – сервера.
Когда все элементы страницы получены, клиент (интернет браузер) отобразит запрошенную WEB – страницу. Порядок и время работы зависят от версии протокола (1.0 или 1.1).
HTTP запросы
Протокол HTTP (HyperText Transfer Protocol) позволяет не только получать HTML документы с Web – серверов, но и передавать информацию от клиента к серверу. Заголовки запросов в протокол HTTP версий 1.0 и 1.1 указаны в таблице ниже:
Запрос
Описание
HTTP/1.0
HTTP/1.1
GET
Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок.
Да
Да
HEAD
Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок.
Да
Да
HEAD
Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок.
Да
Да
POST
Позволяет клиенту отправлять информацию в сторону сервера, например через различные встроенные в сайт формы
Да
Да
PUT
Позволяет клиенту добавить файл в определенную директорию сервера.
Нет
Да
DELETE
Позволяет клиенту удалить файл указанный в рамках запроса.
Нет
Да
TRACE
Позволяет клиенту отслеживать свой запрос к серверу.
Нет
Да
OPTIONS
Позволяет клиенту определять параметры взаимодействия с сервером.
Нет
Да
В стандартном понимании Web – сайта, запросы GET и POST являются наиболее часто используемыми. Метода GET используется клиентом для получения каждого отдельного объекта страницы, в то время как POST зачастую используется в интернет магазинах, где необходимо отправить информацию в строну сервера.
Что такое URL?
Uniform Resource Locator (URL) одна из самых важных составляющих любого GET запроса, который состоит из хоста, на котором находится сайт, схемы обращения (сетевой протокол) и полного пути к HTML файлу. Опционально, URL может содержать в себе информацию о номере TCP порта и определенной точки на странице. Ниже приведен типичный пример URL:
Почитать лекцию №18 про модель Recursive Internet Architecture (RINA) можно тут.
Итерационная модель также выводит концепции сетевых протоколов, ориентированных на соединение и без установления соединения, снова на свет.
Протоколы, ориентированные на соединение, перед отправкой первого бита данных устанавливают сквозное соединение, включая все состояния для передачи значимых данных. Состояние может включать в себя такие вещи, как требования к качеству обслуживания, путь, по которому будет проходить трафик через сеть, конкретные приложения, которые будут отправлять и получать данные, скорость, с которой данные могут отправляться, и другая информация. Как только соединение установлено, данные могут быть переданы с минимальными издержками.
Сервисы без установления соединения, с другой стороны, объединяют данные, необходимые для передачи данных, с самими данными, передавая оба в одном пакете (или блоке данных протокола). Протоколы без установления соединения просто распространяют состояние, необходимое для передачи данных по сети, на каждое возможное устройство, которому могут потребоваться данные, в то время как модели, ориентированные на установление соединения, ограничивают состояние только теми устройствами, которые должны знать об определенном потоке пакетов. В результате сбои в работе одного устройства или канала в сети без установления соединения можно устранить, переместив трафик на другой возможный путь, а не переделав всю работу, необходимую для построения состояния, для продолжения передачи трафика из источника в пункт назначения.
Большинство современных сетей построены с использованием бесконтактных транспортных моделей в сочетании с ориентированными на подключение моделями качества обслуживания, контроля ошибок и управления потоками. Эта комбинация не всегда идеальна; например, качество обслуживания обычно настраивается по определенным путям, чтобы соответствовать определенным потокам, которые должны следовать этим путям. Такая трактовка качества обслуживания как более ориентированного на соединение, чем фактические управляемые потоки трафика, приводит к сильным разрывам между идеальным состоянием сети и различными возможными режимами сбоев.