По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Интеграция Asterisk и CUCM позволяет по протоколу SIP позволяет объединить несколько телефонных пулов, или, например, использовать Asterisk в роли IVR (голосового меню). Как правильно объединить Asterisk и Cisco Unified Communications Manager через SIP – транк расскажем в статье Настройка CUCM Перейдем к настройке Cisco UCM. Для создания нового SIP – транка в раздел Device -> Trunk и нажмите на кнопку Add New. Мы создаем SIP – транк, поэтому, укажите поле Trunk Type и Device Protocol на SIP, как указано на скриншоте ниже: После указания настроек нажмите Next. В появившемся окне указываем следующие опции: Device Name - имя для создаваемого SIP – транка. Обязательное поле Description - описание создаваемого подключения. Device Pool - выберите девайс пул для SIP – транка. Необходимо, чтобы он совпадал с устройствами, которые будут маршрутизироваться через этот транк. Обязательное поле Листаем вниз, и находим раздел под названием Inbound Calls и выставляем следующую опцию: Calling Search Space - имя CSS для SIP - транка. Должно совпадать с маршрутизируемыми устройствами. Последний шаг настроек находится в разделе SIP Information в пункте Destination, тут настраиваем следующие опции: Destination Address - Введите IP – адрес вашего Asterisk. Обратите внимание, что по умолчанию порт назначения 5060. Если ваш сервер Asterisk слушает SIP на другом порту, то укажите его в поле Destination Port. Обязательное поле SIP Trunk Security Profile - профиль безопасности для SIP - транка. Укажите в данном поле Non Secure SIP Trunk Profile. Обязательное поле Rerouting Calling Search Space - укажите CSS, который указали ранее в разделе настроек Inbound Calls. Out-Of-Dialog Refer Calling Search Space - аналогично указанному ранее пункту. SUBSCRIBE Calling Search Space - так же укажите CSS. SIP Profile - SIP профиль. В данном поле указывается Standard SIP Profile По окончанию настроек нажмите Save. Маршрутизацию в SIP – транк можно осуществлять с помощью шаблонов, которые настраиваются в настройках Route Pattern. Настройка со стороны Asterisk Все настройки SIP – транка на стороне Asterisk будем выполнять с помощью графической оболочки FreePBX 13. Для настройки транка перейдем в раздел Connectivity -> Trunks. Нажмите на + Add Trunk, чтобы создать новый SIP – транк. Во вкладке General, укажите имя для создаваемого транка. Далее, переходим во вкладку pjsip Settings. Так как в рамках настройки SIP – транка между Asterisk и CUCM мы не используем регистрацию по логину/паролю, то отмечаем следующие опции: Authentication - выставьте None. Как сказано раньше, мы не используем аутентификацию по логину и паролю. Registration - выставьте None. SIP Server - укажите IP – адрес Cisco UCM. Context - укажите контекст from-internal Перейдите во вкладку Advanced: Qualify Frequency - выставьте 60. Интервал в секундах, через который будут отправляться Keep – Alive сообщения для проверки состояния транка. From Domain - укажите IP – адрес вашего CUCM Нажмите Submit и затем Apply Config. После этого необходимо настроить маршрутизацию для этого транка. Как это сделать, вы можете прочитать в статье по ссылке ниже: Маршрутизация вызовов FreePBX
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
Первая часть тут. В конце 1980—х в мире сетевой инженерии появилась новая тема для обсуждения-асинхронный режим передачи данных (ATM). Потребность в более скоростных схемах в сочетании с медленным развитием в коммутации пакетов персонально на основе их адресов назначения привела к толчку к новому виду передачи, который, в конечном счете, реконфигурировал бы весь набор (или стек, потому что каждый протокол образует слой поверх протокола ниже, как «слоёный пирог») протоколов, используемых в современных сетях. ATM объединил размер ячейки (или пакета) с фиксированной длиной коммутации каналов с заголовком из коммутации пакетов (хотя и значительно упрощенным), чтобы произвести «промежуточное» технологическое решение. Было два ключевых момента для ATM: label switching и fixed call sizes; рисунок 1 иллюстрирует первый вариант. На рис. 1 G отправляет пакет, предназначенный для H. При получении этого пакета A проверяет локальную таблицу и обнаруживает, что следующий переход к H — это C. Локальная таблица A также указывает метку, показанную как L, а не «просто» информацию о том, куда переслать пакет. A вставляет эту метку в специальное поле в начале пакета и пересылает ее в C. Когда C получает пакет, ему не нужно читать адрес назначения в заголовке, скорее, он просто читает метку, которая является коротким полем фиксированной длины. Метка просматривается в локальной таблице, которая сообщает C переадресовать трафик в D для назначения H. Метка очень мала и поэтому легко обрабатывается для устройств пересылки, что делает переключение намного быстрее. В некотором смысле метка также может «содержать» информацию для обработки пакета. Например, если на самом деле существует два потока трафика между G и H, каждому из них может быть назначена своя метка (или набор меток) через сеть. Пакеты, несущие одну метку, могут иметь приоритет над пакетами, несущими другую метку, поэтому сетевым устройствам не нужно просматривать какие-либо поля в заголовке, чтобы определить, как обрабатывать конкретный пакет. Это можно рассматривать как компромисс между коммутацией пакетов и коммутацией каналов. В то время как каждый пакет все еще пересылается hop by hop, виртуальный канал также может быть определен путем метки через сеть. Второй момент заключался в том, что ATM также был основан на ячейке фиксированного размера: каждый пакет был ограничен 53 октетами информации. Ячейки фиксированного размера могут показаться незначительной проблемой, но пакеты фиксированного размера могут иметь огромное значение для производительности. Рисунок 2 иллюстрирует некоторые факторы, связанные с фиксированными размерами ячеек. На рисунке 2 пакет 1 (A1) копируется из сети в память на сетевой карте или интерфейсе LC1; затем он проходит через внутреннюю структуру внутри B (между ячейками памяти) к LC2, и, наконец, возвращается в сеть на исходящем интерфейсе B. На такой диаграмме это может показаться тривиальным, но, пожалуй, наиболее важным фактором скорости, с которой устройство может переключать / обрабатывать пакеты, является время, необходимое для копирования пакета по любым внутренним путям между ячейками памяти. Процесс копирования информации из одного места в памяти в другое является одной из самых медленных операций, которые может выполнять устройство, особенно на старых процессорах. Создание одинакового пакета (фиксированный размер ячейки) позволило оптимизировать код во время процесса копирования, что значительно увеличило скорость переключения. Путь пакета 2 через B еще хуже с точки зрения производительности; сначала он копируется из сети в локальную память. Когда порт назначения определяется путем поиска в локальной таблице пересылки, код, обрабатывающий пакет, понимает, что пакет должен быть фрагментирован, чтобы соответствовать наибольшему размеру пакета, разрешенному на исходящем канале [B,C]. Карта входящей линии, LC1, фрагментирует пакет на A1 и A2, создавая второй заголовок и корректируя любые значения в заголовке по мере необходимости. Пакет делится на два пакета, А1 и А2. Эти два пакета копируются в двух операциях через матрицу на исходящую сетевую карту LC2. Используя ячейки фиксированного размера, ATM избегает затрат на производительность фрагментации пакетов (в то время, когда предлагалась ATM), понесенных почти любой другой системой коммутации пакетов. ATM, на самом деле, не начинался в ядре сети и не прокладывал свой путь к краю сети. А почему бы и нет? Первый ответ заключается в довольно странном выборе размера ячейки. Почему 53 октета? Ответ прост-и, возможно, немного поразителен. АТМ должна была заменить не только сети с коммутацией пакетов, но и тогдашнее поколение голосовых сетей, основанных на технологиях коммутации каналов. Объединяя эти две технологии, провайдеры могли бы предлагать оба вида услуг на одном наборе схем и устройств. Какой объем информации или размер пакета идеально подходит для передачи голосового трафика? Около 48 октетов. Какой объем информации или размер пакета является минимумом, который имеет какой-либо смысл для передачи данных? Около 64 октетов. Пятьдесят три октета были выбраны в качестве компромисса между этими двумя размерами; это не было бы идеально для передачи голоса, так как 5 октетов каждой ячейки, несущей голос, были бы потрачены впустую. Это не было бы идеально для трафика данных, потому что самый распространенный размер пакета, 64 октета, должен был бы быть разделен на две ячейки для переноса через сеть ATM. Общим мнением во время проведения этих обсуждений было то, что протоколы передачи данных могли бы адаптироваться к немного меньшему размеру ячейки, что делает 53 октета оптимальным размером для поддержки широкого спектра трафика. Протоколы передачи данных, однако, не изменились. Для переноса 64-октетного блока данных одна ячейка будет содержать 53 октета, а вторая - 9 октетов с 42 октетами свободного пространства. Провайдеры обнаружили 50% или более доступной пропускной способности на каналах ATM использовались пустые ячейки, что фактически приводило к потере пропускной способности. Следовательно, поставщики данных прекратили развертывание ATM, поставщики голосовой связи так и не начали его развертывание, и ATM умер. Что интересно, так это то, как наследие таких проектов, как ATM, живет в других протоколах и идеях. Концепция переключения меток была подхвачена Yakov Rekhter и другими инженерами и превращена в переключение меток. Это сохраняет многие фундаментальные преимущества быстрого поиска ATM на пути пересылки и объединения метаданных об обработке пакетов в саму метку. Коммутация по меткам в конечном итоге стала Multiprotocol Label Switching (MPLS), которая не только обеспечивает более быстрый поиск, но также стеки меток и виртуализацию. Таким образом, была взята и расширена основная идея, которая существенно повлияла на современные сетевые протоколы и конструкции. Вторым наследием ATM является фиксированный размер ячейки. В течение многих лет доминирующий сетевой транспортный пакет, основанный на TCP и IP, позволял сетевым устройствам фрагментировать пакеты при их пересылке. Однако это хорошо известный способ снижения производительности сети. Бит «не фрагментировать» был добавлен в заголовок IP, сообщая сетевым устройствам о необходимости отбрасывать пакеты, а не фрагментировать их, и были предприняты серьезные усилия для обнаружения самого большого пакета, который может передаваться по сети между любой парой устройств. Новое поколение IP, названное IPv6, удалило фрагментацию сетевыми устройствами из спецификации протокола. Третья часть тут.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59