По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Спешим поделиться тем, как с помощью IP-АТС Asterisk можно провести двусторонний видео - звонок. В качестве терминалов, которые будут участвовать в данном соединении, мы выбрали программный open - sourсe клиент IP-телефонии на базе протокола SIP - Linphone (Linux Phone) версии 3.10.2 для Windows и приложение Linphone для Android версии 3.1.1. Настройки произведем с помощью графического интерфейса FreePBX 13.
Конфигурация FreePBX
Приступим к настройке. Для начала необходимо создать на сервере два внутренних номера (Extension).
Важно: обязательно создавайте номера с типом CHAN_SIP.
Теперь новым внутренним номерам нужно включить поддержку видео. Для этого переходим во вкладку Advanced:
И напротив строки Video Support выбираем Yes. Такую процедуру проделываем для всех номеров, которым хотим разрешить пользоваться видео - вызовами.
Теперь необходимо включить глобальную поддержку видео. Для этого переходим по следующему пути: Settings -> Asterisk SIP Settings и открываем вкладку Chan SIP Settings:
По умолчанию, в разделе Video Codecs поддержка видео отключена. Для того, чтобы её выключить, нажимаем Enabled:
Откроется список поддерживаемых видео кодеков. По умолчанию, Asterisk поддерживает следующие кодеки: H.261, mpeg4, H.263, H.263+, H.264 и последний кодек, который мы будем использовать далее - VP8.
Чтобы исключить возможные проблемы с подключением SIP-терминалов в дальнейшем, можно изменить ещё один параметр. Дело в том, что практически все SIP-терминалы используют 5060 порт для отправки запросов регистрации, а в FreePBX 13 для технологии CHAN_SIP используется порт 5160, соответственно, на этапе регистрации Endpoint’а могут возникнуть проблемы. Что бы этого избежать, в строке Bind Port поставим 5060. Не забудьте предварительно поменять порт для CHAN_PJSIP, может возникнуть внутренний конфликт.
На этом настройка FreePBX завершена, теперь необходимо настраивать терминалы.
Настройка видео - терминалов
Как было сказано в начале, для теста будем использовать Linphone (Linux Phone) версии 3.10.2.
После установки дистрибутива, нас встречает помощник настройки учётной записи SIP:
Вводим данные для ранее созданного внутреннего номера, например - 1022, и жмём Применить.
Если всё было сделано верно, то мы увидим наш полный идентификатор и зелёный круг, свидетельствующий о том, что регистрация была успешной.
Далее переходим в настройки, выбираем требуемые параметры видео (разрешение и частоту кадров)
В разделе кодеки, следует обязательно убедиться в том, что кодек VP8 – разрешен к использованию.
На этом настройка десктопного клиента для Windows закончена.
Теперь сконфигурируем Linphone Android клиент. После установки приложения, нужно выбрать USE SIP ACCOUNT
Ввести данные учетной записи в соответствии с данными, которые мы вводили на сервере. В качестве транспорт укажите UDP.
В разделе Settings устанавливаем требуемые параметры по видео (разрешение, частоту кадров, максимальную пропускную способность) и обязательно разрешаем использование кодека VP8.
Если всё было сделано правильно, то мы увидим статус Registered. Софтфон готов к использованию.
Теперь можно проводить вызовы с трансляцией видео. Набираем номер нужного абонента и жмём на значок трубки.
Нажав на значок Видео начнётся двусторонняя видеотрансляция.
Ниже пример как это выглядит на десктопной версии:
И пример того, как это выглядит в мобильном приложении:
Использование REST API является полезной функцией для реализации ваших сценариев. Вы можете получить доступ к новым функциям, а также расширить возможности создания новых, более продвинутых сценариев.
Опыт многих пользователей показывает, что, когда начинаешь использовать REST API в скриптах, то чувствуешь себя довольно неуклюже и непривычно. В этой заметке мы обсудим:
Что такое REST API
Как читать документацию
Как использовать API REST с PowerShell
Некоторые советы и подсказки, как облегчить и улучшить практику
Что такое "REST"?
REST, или RESTful API, это API, который использует HTTP запросы для получения, добавления, удаления или манипулирования данными в различных сервисах.
Как правило, то, что нужно сделать с данными, решается тем, какой HTTP-метод вы используете. Вот краткий список методов HTTP и их применение в REST API:
GET-Read
POST-Create
PATCH-Partial update/modify
PUT-Update/replace
DELETE-Remove
Данные, которые возвращает API REST, обычно представляются в формате JSON.
Теперь давайте начнём с нашего первого API запроса!
Что такое API
Работа с документацией
Для использования различных API REST необходимо научиться читать и интерпретировать документацию. К счастью, если вы знаете, как читать один тип документации, вы сможете быстро научиться читать другие.
В этой статье мы используем petstore.swagger.io, так как он использует популярный фреймворк Swagger, который довольно часто используется в разработке.
На предыдущем рисунке показана наиболее важная информация о конечных точках REST API:
HTTP-метод-GET/POST/DELETE и т.д.
URL-адрес, связанный с конечной точкой REST API (Базовый URL, как правило, представлен в верхней части страницы документации)
Краткое описание
Подробности
Первая страница документации просто замечательная, и, как правило, с помощью этой информации можно выполнить большинство запросов, требующих использования метода HTTP GET. Но такие методы, как POST и SET, обычно требуют, чтобы вы щелкнули и развернули строку, чтобы получить больше информации.
Если вы нажмете на одну из строк, то получите информацию, которая выглядит так:
Здесь мы представили конечную точку REST, которая может создать новый объект pet. Здесь указывается, как должен выглядеть JSON, предоставленный в теле POST, и какой тип контента он принимает. Другие конечные точки REST указывают, что это за параметры, каким типом данных они должны быть и т.д.
Это основы для чтения документации. Теперь, когда общие принцип более-менее ясны, пора начать использовать REST API с PowerShell.
Получение первых данных (GET)
Используя REST API с PowerShell обычно довольно просто, используется встроенные командлеты, таким образом, нет необходимости в дополнительных модулях. Мы собираемся извлечь данные с помощью метода GET в конечной точке /pet/{ petId}.
Если развернуть конечную точку /pet/{ petId} в документации, можно увидеть, что {petId} на самом деле является параметром, который принимает целое число.
Это делает URL-адрес для выборки объекта pet с идентификатором 1: https://petstore.swagger.io/v2/pet/1
В документации SWAGGER REST API обычно отображается базовый URL-адрес в верхней части страницы.
Теперь начнем с PowerShell. Откройте окно терминала и введите:
PS51 > Invoke-RestMethod -Method GET -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/1"
id : 1
category : @{id=0; name=string}
name : doggie
photoUrls : {string}
tags : {@{id=0; name=string}}
status : available
Поскольку в ответе от сервера возвращается тип содержимого "application/json" используется метод Invoke-RestMethod, который автоматически преобразует возвращаемый JSON в объект.
Ошибка 404 Not found, как правило, означает, что объект не найден или URL-адрес введен неправильно.
Итак, мы выполнили первый вызов REST API. Но возможности метода GET для получения данных довольно ограничены, так что давайте создадим что-нибудь с помощью метода POST.
Создание объекта методом POST
Метод POST чаще всего используется для создания, например, пользователей или записей и т.д. Запрос POST отправляет BODY, содержащий информацию, конечной точке REST, обычно в формате JSON, но он также может быть в виде формы с кодировкой URL.
Вы узнаете, как создать объект JSON, который можно отправить в конечную точку/pet.
Можно увидеть, как должен выглядеть JSON, если развернуть строку POST/pet в документации.
Начнем с создания хэштаблицы, который можно преобразовать в объект JSON. Raw JSON следует избегать в скриптах PowerShell, поскольку он ограничивает его возможности.
$Body = @{
id = 19
category = @{
id = 45
name = "Whatever"
}
name = "Dawg"
photoUrls = @(
"string"
)
tags = @(
@{
id = 0
name = "string"
}
)
status = "available"
}
Если вам трудно создать хештаблицу, который преобразуется в нужный JSON, установите модуль PsdKit и используйте команду $ JsonString | ThreadTo-Psd
Теперь имеется хэш-таблица, которую можно преобразовать в строку JSON и POST в конечную точку/pet:
$JsonBody = $Body | ConvertTo-Json
$Uri = "https://petstore.swagger.io/v2/pet"
Invoke-RestMethod -ContentType "application/json" -Uri $Uri -Method Post -Body $JsonBody
id : 19
category : @{id=45; name=Whatever}
name : Dawg
photoUrls : {string}
tags : {@{id=0; name=string}}
status : available
При создании объекта он обычно получает созданный для подтверждения объект. Использование DELETE. Метод DELETE используется для удаления данных, а применение очень схоже с методом GET.
PS51 > Invoke-RestMethod -Method DELETE -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/1"
Только убедитесь, что не удалите ничего важного
Использование PUT
Метод PUT используется для обновления данных. Это делается аналогично методу POST путем представления полного или частичного объекта JSON:
PS51> $Body = [PSCustomObject]@{
id = 19
name = "Dawg with a new name"
}
PS51> $JsonBody = $Body | ConvertTo-Json
PS51> $Uri = "https://petstore.swagger.io/v2/pet"
PS51> Invoke-RestMethod -ContentType "application/json" -Uri $Uri -Method PUT -Body $JsonBody
id name photoUrls tags
-- ---- --------- ----
19 Dawg with a new name {} {}
Обычно API REST возвращает объект JSON с использованными и/или обновленными данными. Можно увидеть, что объект был обновлен с помощью метода GET:
PS 51> Invoke-RestMethod -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/19"
id : 19
category : @{id=45; name=Whatever}
name : Dawg with a new name
photoUrls : {string}
tags : {@{id=0; name=string}}
status : available
Создание функций
Писать эти команды каждый раз вручную может стать довольно утомительным и на самом деле не масштабируемым. Если мы вызываем конечную точку несколько раз, то лучше создать для нее функцию. Это довольно просто и нужно написать всего несколько строк:
Function Get-PetstorePet {
[cmdletbinding()]
param(
# Id of the pet
[Parameter(Mandatory,ValueFromPipeline)]
[int]$Id
)
Begin{}
Process{
$RestMethodParams = @{
Uri = "https://petstore.swagger.io/v2/pet/$Id"
ContentType = "application/json"
Method = "GET"
}
Invoke-RestMethod @RestMethodParams
}
End{}
}
После создания функции ее можно вызвать в сценарии:
PS51> Get-PetstorePet -Id 1
id name photoUrls tags
-- ---- --------- ----
1 Doggie {http://picture.url} {}
Это можно сделать и для метода POST для создания нового объекта pet в Petstore:
Function Add-PetstorePet {
[cmdletbinding()]
param(
# Id of the pet
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[int]$Id,
# Name of the pet
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string]$Name,
# Status of the pet (available, sold etc)
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string]$Status,
# Id of the pet category
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[int]$CategoryId,
# Name of the pet category
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string]$CategoryName,
# URLs to photos of the pet
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string[]]$PhotoUrls,
# Tags of the pets as hashtable array: @{Id=1;Name="Dog"}
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[Hashtable[]]$Tags
)
Begin{}
Process{
$Body = @{
id = $Id
category = @{
id = $CategoryId
name = $CategoryName
}
name = $Name
photoUrls = $PhotoUrls
tags = $Tags
status = $Status
}
$BodyJson = $Body | ConvertTo-Json
$RestMethodParams = @{
Uri = "https://petstore.swagger.io/v2/pet/"
ContentType = "application/json"
Method = "Post"
Body = $BodyJson
}
Invoke-RestMethod @RestMethodParams
}
End{}
}
И вызов этой функции PowerShell намного упрощает задачу:
PS51> $AddPetStorePetsParams = @{
Id = 44
Name = "Birdie"
Status = "available"
CategoryId = 50
CategoryName = "Hawks"
PhotoUrls = "https://images.contoso.com/hawk.jpg"
Tags = @(
@{
Id=10
Name="Not eagles"
}
)
}
PS51> Add-PetStorePet @AddPetStorePetsParams
id : 44
category : @{id=50; name=Hawks}
name : Birdie
photoUrls : {https://images.domain.com/hawk.jpg}
tags : {@{id=0}}
status : available
Возможно, что многие модули, которые вы ежедневно используете, состоят из функций, который за кулисами используют REST API.
Заключение
Обучение работы с REST API, главным образом основано на чтении документации. Мы использовали документацию на основе SWAGGER в этом посте, так как она представляет, как могут выглядеть другие стили документации.
Кроме того, преобразование вызовов API в функцию может сэкономить много времени, упростить работу и очистить сценарии.
Привет! В статье расскажем как сделать аутентификацию пользователей FreePBX 13 в модуле User Management через Microsoft Active Directory. Настройка выполняется достаточно тривиально. Указанные параметры протестированы с MSE 2012.
Pre - work
Перед началом настройки, необходимо протестировать доступность 389 порта в AD по транспорту TCP. Для этого, сделаем telnet в cmd консоли рабочей машины:
telnet 192.168.1.67 389
В нашем случае, 192.168.1.67 - это адрес AD – сервера. Если все ОК, то переходим к проверке Base DN (базы поиска). Открываем консоль CMD на своей рабочей машине и выполняем dsquery запрос:
dsquery user -name MerionNetworks
dsquery user - команда для поиска пользователей;
-name - поиск пользователей, по критерию имени (в нашем случае MerionNetworks) – можно использовать маски, например, «*Networks»;
MerionNetworks - имя, по которому осуществляем поиск;
Команда вернет нам примерно вот такой вывод:
"CN= MerionNetworks,CN=Users,DC=merionet,DC=local"*
Запоминаем вот эту часть CN=Users,DC=merionet,DC=local и переходим к настройке FreePBX.
Настройка в FreePBX
Переходим в раздел Admin → User Management нажимаем на вкладку Settings и далее Authentication Settings. В поле Authentication Engine выбираем Microsoft Active Directory и приступаем к настройке:
Authentication Engine - тип подключения. Мы рассматриваем подключения к Microsoft AD, его и указываем;
Remote Authentication IP Addresses - список IP – адресов, с которых разрешена удаленная аутентификация методом отправки POST на URL 192.168.1.7/admin/ajax.php?module=userman&command=auth, где 192.168.1.7 – IP – адрес нашего сервера Asterisk (FreePBX);
Synchronize - как часто синхронизировать данные с AD. Мы указали раз в час;
Host - имя или IP – адрес сервера AD;
Port - порт, на котором слушает AD. У нас стандартный 389 порт;
Username - существующее имя пользователя в AD. Мы производили проверку в первой части статьи пользователем MerionNetworks, его и укажем;
Password - указываем пароль этого пользователя;
Domain - указываем доменную часть;
Base DN - копируем сюда Base DN, который получили ранее с помощью dsquery;
Status - статус подключения к AD. У нас Connected :)