По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет! Сегодня расскажем про то, как настроить Call Hunting в Cisco Unified Communications Manager (CUCM). Call Hunting позволяет распределять звонки на телефоны, в необходимой последовательности.
Теория
Call Hunting содержит следующие компоненты:
Directory Numbers (DNs) и Voicemail порты: конечные назначения, присваиваются Line Groups;
Line Groups: присваиваются Hunt List’у, к одному Hunt листу можно присвоить больше одной Line группы. В Line группе могут быть настроены различные алгоритмы поиска (Top-Down, Circular, Longest Idle, Broadcast) и другие настройки;
Hunt Lists: Представляет собой упорядоченный список Line групп. Звонок, проходящий через систему Call Hunting’а направляется в первую Line группу в Hunt листе. Если никто не может ответить в этой Line группе, то звонок может быть возвращен в Hunt List, где будет направлен в другую Line группу. Процесс может повторяться до тех пор, пока на звонок не ответят, закончатся Line группы или звонящий повесит трубку;
Hunt Pilots: Hunt Pilot присваивается Hunt List’у, и может быть уникальным DN или ТфОП номером. После набора этого номера начинается процесс Call Hunting’а;
Визуально это можно представить так:
Настройка Call Hunting
Первым делом создаем Line Group:
Для начала необходимо убедиться, что созданы Directory Numbers, присвоенные телефонным аппаратам;
После этого в CM Administration переходим во вкладку Call Routing → Route/Hunt → Line Group, и в открывшемся окне нажимаем Add New;
Здесь в поле Line Group Name указываем называние для Line группы, ниже в поле RNA Reversion Timeout указываем сколько секунд будет звонить каждый телефон в группе, перед тем как будет достигнуто значение No Answer;
В выпадающем списке Distribution Algorithm выбираем алгоритм распределения звонков:
Top Down – каждый новый вызов начинается с номера который стоит первым в списке;
Circular – каждый новый вызов начинается с номера, который в списке был после номера, который принял предыдущий вызов;
Broadcast – все телефоны звонят одновременно; Longest Idle Time – звонок направляется на телефон, который дольше всех был неактивен);
В меню Hunt Options выбираем, что будет происходить со звонком при достижении определенного состояния (No Answer, Busy и Not Available);
В поле Available DN/Route Partition выбираем номера, которые будут добавлены в группу, и в каком порядке будет происходить обзвон. Они будут отображаться в поле Secelted DN/Route Partition. Затем нажимаем Save;
Затем создаем Hunt List:
Переходим во вкладку Call Routing → Route/Hunt → Hunt List и нажимаем Add New;
В поле Name указываем название листа;
Выбираем CUCM группу в поле Cisco Unified Communications Manager Group. Значение по умолчанию – Default;
Нажимаем Save, после чего на странице появится поле Hunt List Member Information;
Нажимаем Add Line Group и добавляем в необходимом порядке Line группы, созданные ранее;
Теперь, как вы могли догадаться, создаем Hunt Pilot :)
Переходим во вкладку Call Routing → Route/Hunt → Hunt Pilot и нажимаем Add New.
В поле Hunt Pilot указываем номер, на который будут поступать звонки;
Если необходимо, то указываем Partition;
В выпадающем меню Hunt List выбираем тот Hunt List, на который будут уходить звонки;
В меню Call Forward Settings можно указать, куда отправлять вызов, если Call Hunting система не может его обработать (состояния No Answer и Busy);
Web real-time communication (WebRTC) стандарт, который появился совсем недавно и нацелен на осуществление общения в реальном времени с помощью веб-браузера с использованием одно ранговой сети.
Проект WebRTC является открытым и его целью является позволить браузерам нативно поддерживать пиринговую передачу данных в реальном времени.
В настоящее время много веб-сервисов используют RTC (связь в режиме реального времени), но при этом требуется установка приложений или специальных плагинов. К примеру – Skype, Facebook (так же работает через Skype) и Google Hangouts (использует плагин Google Talk). Установка и обновление плагинов может быть достаточно трудоёмким и нудным процессом, после которого могут появляться новые ошибки. С этой точки зрения технология WebRTC действительно привносит множество новшеств, таких как:
Нет необходимости в лицензировании
Интеграция являет собой процесс с использованием стандартных Web API
Отсутствие проприетарных плагинов
Нет необходимости в скачивании и установке чего-либо, достаточно просто зайти на веб-страницу.
Целями данной технологии являются, главным образом – минимум трудозатрат при связи, поддержка большинства браузеров, поддержка популярных в данный момент сервисов для голосовой или видеосвязи – Skype, WhatsApp и т.д. Главное – уменьшение капитальных затрат и повышение эффективности связи при использовании данной разработки.
Основные моменты
До первой коммуникации браузеры «не знают» о существовании друг друга
JavaScript управляет процессом установки соединения через сервер
Потоки медиа-данных используют кратчайшие пути с целью уменьшения задержки. На схеме ниже изображен процесс соединения абонентов:
Для веб-приложения WebRTC необходима следующая информация:
Получение доступа к потоковой передачи голоса иили видео данных
Получение сетевой информации – сетевой адрес, порт и обмен данной информацией с другими пирами
Синхронизация сигнальной информации для открытия и закрытия сессий, выявления ошибок
Обмен информацией о совместимости таких параметров как: тип браузера, разрешение и тип кодека
Соединение входящего и исходящего потока медиа-данных
Что касается сигнализации при использовании данной технологии, первоначальной идеей было использовать SDP (Session Description Protocol), однако данный подход выявил несколько неразрешимых проблем. IETF принял решение стандартизировать протокол JSEP (Javascript Session Establishment Protocol), что дословно переводится как протокол открытия сессии с помощью Javascript. JSEP предоставляет интерфейс для приложения, позволяющий оперировать локальными и удаленными описаниями сессий. Подход с использованием данного протокола делегирует ответственность по управлению состоянием сигнализации исключительно приложению.
Что же с точки зрения безопасности?
Есть несколько путей, которыми может быть скомпрометировано приложение или плагин RTC:
Незашифрованные медиа-данные могут быть перехвачены между абонентами или между абонентом и сервером
Приложение может записывать звонки и распространять их без ведома пользователя
Вирусы могут установлены вместе с приложением или плагином при установке из неблагонадежного источника
В технологии WebRTC было добавлено несколько функций, которые позволяют избежать вышеописанного:
Реализации WebRTC используют безопасные протоколы, такие как DTLS и SRTP
Шифрование обязательно для всех компонентов WebRTC, включая сигнальные механизмы.
WebRTC не является плагином или отдельной программой – всего компоненты запускаются в браузере, причем не являясь отдельным процессом. Компоненты WebRTC обновляются при обновлении браузера.
Конечно, вышеописанное справедливо только при использовании поддерживаемых браузеров и соблюдении обычных правил безопасности в интернете.
Преграды для быстрого развития
Необходимость наличия сервера для осуществления четырех задач:
Поиск пользователей
Сигнализация
Механизмы прохождения сигнальной и медиа информации через NAT
Механизмы обеспечения прохождения информации через межсетевой экран
Отсутствие нативных приложений и SDK – WebRTC технология для связи абонентов через браузер, однако нет SDK, позволяющего разработать нативное приложение для IOS и Android
Невозможность конференций – благодаря своей пиринговой натуре (peer-to-peer), WebRTC является чрезвычайно легко масштабируемой технологией, но при этом отсутствует необходимый инструментарий для организации аудио и видеоконференций.
Выводы
Стандартизация различных API для WebRTC может снизить цены на связь и позволит использовать WebRTC во многих индустриях – телекоммуникационной, игровой, новостной и так далее. Кроме того, можно с уверенностью сказать, что WebRTC окажет сильное влияние на Интернет в общем – разработки веб-приложений с открытым кодом, на рост совместимости между браузерами и т.д
Протокол маршрутизации OSPF (Open Shortest Path First) (про него можно прочитать тут, а про его настройку здесь) для обмена информации о топологии сети использует сообщения LSA (Link State Advertisement). Когда роутер получает LSA сообщение, он помещает его в базу Link-State DataBase (LSDB). Когда все базы между маршрутизаторами синхронизированы, OSPF использует алгоритм Shortest Path First, чтобы высчитать лучший маршрут между сетями.
LSA содержат в себе информацию о маршруте передается внутри Link State Update (LSU) пакета. Каждый LSU пакет содержит в себе один или несколько LSA, и когда LSU отправляется между маршрутизаторами OSPF, он распространяет информацию LSA через сеть. Каждый LSA используется в определенных границах сети OSPF.
Выглядит это вот так:
Типы LSA
OSPF в настоящее время определяет 11 различных типов LSA, однако, несмотря на большое разнообразие LSA, только около половины из них обычно встречаются в сетях OSPF, но мы рассмотрим их все.
LSA Тип 1 – OSPF Router LSA
Пакеты LSA Type 1 (Router LSA) отправляются между маршрутизаторами в пределах одной и той же зоны (area) где они были созданы и не покидают эту зону. Маршрутизатор OSPF использует пакеты LSA Type 1 для описания своих собственных интерфейсов, а также передает информацию о своих соседях соседним маршрутизаторам в той же зоне.
LSA Тип 2 – OSPF Network LSA
Пакеты LSA Type 2 (Network LSA) генерируются Designated Router’ом (DR) для описания всех маршрутизаторов, подключенных к его сегменту напрямую. Пакеты LSA Type 2 рассылаются между соседями в одной и той же зоны где они были созданы и остаются в пределах этой зоны.
LSA Тип 3 – OSPF Summary LSA
Пакеты LSA Type 3 (Summary LSA) генерируются с помощью пограничных маршрутизаторов Area Border Routers (ABR) и содержат суммарное сообщение о непосредственно подключенной к ним зоне и сообщают информацию в другие зоны, к которым подключен ABR. Пакеты LSA Type 3 отправляются в несколько зон по всей сети.
На рисунке показано как маршрутизатор R2 ABR создает Type 3 Summary LSA и отправляет их в зону Area 0. Таким же образом R3 ABR роутер создает пакеты Type 3 и отправляет их в Area 2. В таблице маршрутизации маршруты, полученные таким образом, отображаются как “O IA”
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
LSA Тип 4 – OSPF ASBR Summary LSA
Пакеты LSA Type 4 (ASBR Summary LSA) - это LSA, которые объявляют присутствие автономного пограничного маршрутизатора Autonomous System Border Router (ASBR) в других областях.
На схеме, когда R2 (ABR) принимает пакет LSA Type 1 от R1, он создаст пакет LSA Type 4 (Summary ASBR LSA), который передает маршрут ASBR, полученный из Area 1, и вводит его в Area 0. Хотя пакеты LSA Type 4 используются ABR для объявления маршрута ASBR через их зоны, он не будет использоваться самим ASBR в пределах его локальной зоны (Area 1); ASBR использует LSA Type 1 для информирования своих соседей (в данном случае R2) в своих сетях.
LSA Тип 5 – OSPF ASBR External LSA
Пакеты LSA Type 5 (ASBR External LSA) генерируются ASBR для передачи внешних перераспределенных маршрутов в автономную систему (AS) OSPF. Типичным примером LSA Type 5 будет внешний префикс или маршрут по умолчанию (default router), как показано на схеме.
Этот внешний маршрут/префикс перераспределяется в OSPF-сеть ASBR (R1) и в таблице маршрутизации будет отображаться как "O E1" или "O E2".
LSA Тип 6 – OSPF Group Membership LSA
Пакеты LSA Type 6 (Group Membership LSA) были разработаны для протокола Multicast OSPF (MOSPF) , который поддерживает многоадресную маршрутизацию через OSPF. MOSPF не поддерживается Cisco и не пользуется широкой популярностью.
LSA Тип 7 – OSPF Not So Stubby Area (NSSA) External LSA
Пакеты LSA Type 7 (NSSA External LSA) используются для некоторых специальных типов зон, которые не позволяют внешним распределенным маршрутам проходить через них и таким образом блокируют распространение в них LSA Type 5. LSA Type 7 действуют как маска для LSA Type 5 пакетов, позволяя им перемещаться по этим специальным зоам и достигать ABR, который может переводить пакеты LSA Type 7 обратно в пакеты LSA Type 5.
На схеме ABR R2 переводит LSA Type 7 в LSA Type 5 и рассылает его в сеть OSPF.
LSA Тип 8 – OSPF External Attributes LSA (OSPFv2) / Link Local LSA (OSPFv3)
Пакеты LSA Type 8 в OSPFv2 (IPv4) называются внешними атрибутами LSA и используются для передачи атрибутов BGP через сеть OSPF, в то время как адреса BGP передаются через LSA Type 5 пакеты, однако, эта функция не поддерживается большинством маршрутизаторов. С OSPFv3 (IPv6) , LSA Type 8 переопределяется для передачи информации IPv6 через сеть OSPF.
LSA Тип 9, 10 и 11
Обычно LSA этих типов используются для расширения возможностей OSPF. Практическое применение этих LSA заключается в Traffic Engineering’е MPLS, где они используются для передачи параметров интерфейса, таких как максимальная пропускная способность, незанятая полоса пропускания и т.д.
LSA Тип 9 – OSPF Link Scope Opaque (OSPFv2) / Intra Area Prefix LSA (OSPFv3)
LSA Type 9 в OSPFv2 (IPv4) определяется как Link Scope Opaque LSA для передачи OSPF информации. Для OSPFv3 он переопределяется для обработки префикса связи для специального типа зоны, называемого Stub Area.
LSA Тип 10 – OSPF Area Scope Opaque LSA
Пакеты LSA Type 10 используются для потоковой передачи информации OSPF через маршрутизаторы других областей. Даже если эти маршрутизаторы не обрабатывают эту информацию, чтобы расширить функциональность OSPF, этот LSA используется для Traffic Engineering’а для объявлений MPLS и других протоколов.
LSA Тип 11– OSPF AS Scope Opaque LSA
Пакеты LSA Type 11 выполняют ту же задачу, что и пакеты LSA Type 10, но не пересылаются в специальные зоны (Stub зоны)