По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Спешим поделиться тем, как с помощью 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. Софтфон готов к использованию. Теперь можно проводить вызовы с трансляцией видео. Набираем номер нужного абонента и жмём на значок трубки. Нажав на значок Видео начнётся двусторонняя видеотрансляция. Ниже пример как это выглядит на десктопной версии: И пример того, как это выглядит в мобильном приложении:
img
Использование 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 в функцию может сэкономить много времени, упростить работу и очистить сценарии.
img
Привет! В статье расскажем как сделать аутентификацию пользователей 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 :)
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59