По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В сегодняшней статье мы поговорим об одном из первых протоколов, получивших широкое применения в сетях VoIP – H.323.
Первая реализация H.323 была представлена ITU-T (International Telecommunication Union - Telecommunications) еще в 1996 и предназначалась для использования в видеоконференциях, ограниченных LAN (Local Area Network). Однако, протокол был быстро адаптирован для передачи голосовых данных в других типах IP сетей, таких как WAN (Wide Are Network) и Интернет.
H.323 чаще всего называют “протоколом”, хотя на самом деле, это целый стек протоколов, которые объединены одной задачей – поддержание передачи аудио- и видео-данных через сеть с коммутацией пакетов.
Протокол H.323
Как видно из данного рисунка передача аудио и видео осуществляется по стекам G.xxx/RTP/UDP/IP и H.xx/RTP/UDP/IP, за статистическую информацию о сессии отвечает RTCP.
Протокол H.255 RAS (Registration, Admission, Status) отвечает за взаимодействие оконечных устройств с привратником или контроллером зоны.
Протокол H.245 управляет информационными медиа каналами, проводит согласование функциональных возможностей терминалов и осуществляет управление логическими каналами.
Процесс установления и завершения звонков через IP сеть осуществляется по средствам протокола H.255.0, сигнальные сообщения которого, позаимствованы у Q.931, использующегося в ISDN.
Архитектура H.323 имеет клиент-серверную модель и включает в себя следующие элементы:
- Терминал
Это основное устройство в системе H.323, обеспечивающее передачу видео- и аудио данных. Терминал обязательно должен поддерживать все протоколы, входящие в стек H.323, для обеспечения сервисов IP телефонии. Выполняется как в виде простого IP телефона, так и в виде сложного устройства с дополнительными функциями.
- Шлюз (Gateway)
Данный элемент присутствует только тогда, когда необходимо обеспечить сопряжение сети H.323 с сетью другого типа, например ISDN (Integrated Services Digital Network) или PSTN (Public Switched Telephone Network). Стоит отметить, что с помощью шлюзов можно обеспечить взаимодействие H.323 и с сетями мобильной связи третьего поколения (3G), которые используют протокол H.324.
- Привратник (Gatekeeper)
Также как и шлюз, привратник является опциональным элементом сети H.323. В число функций привратника входят: регистрация терминалов, управление полосой пропускания, трансляция адреса, аутентификация пользователей.
Привратник работает в двух режимах: direct routed и gatekeeper routed
Наиболее эффективным и широко распространенным является режим direct routed, поскольку в этом режиме оконечные устройства (терминалы), по средствам протокола RAS узнают IP адрес удаленного устройства и соединение происходит напрямую.
В режиме же gatekeeper routed соединение всегда происходит через привратник, что конечно же требует от него дополнительных вычислительных мощностей.
Совокупность устройств, подключенных к одному привратнику называется зоной (zone), поэтому привратник часто называют контроллером зоны.
- Устройство управления конференциями (Multipoint Control Unit)
Данное устройство является сервером, в функции которого входит поддержание аудио- и видео- конференций между тремя или более H.323 терминалами. Сервер управляет ресурсами конференции, определяет аудио- и видео-потоки, проводит согласование терминалов по возможности обработки аудио- и видео-данных.
Как видно, наличие всех рассмотренных устройств, кроме терминалов, является опциональным. Таким образом, простейшей архитектурой сети H.323 могут являться два, напрямую подключенных терминала, поддерживающих соответствующий стек протоколов.
В следующей статье мы более подробно рассмотрим работу некоторых протоколов из стека H.323, а также изучим возможные варианты сценариев установления соединения. Кроме того, мы научимся разбираться в сигнальных сообщениях протокола Q.931, что поможет нам в понимании не только H.323, но и ISDN.
В обычной корпоративной сети доступ к серверам из филиалов организации может осуществляться, чаще всего, подключением к серверам, расположенным в центральном офисе. Но при расположении серверной инфраструктуры в облаке параметры связи рабочих станций с серверами будут зависеть уже не от канала связи от каждого конкретного филиала до центрального офиса, а от канала связи всех отделений организации с ЦОД облачного провайдера, чьими услугами пользуется организация для формирования облачной инфраструктуры.
Переход в облака поставил перед разработчиками ПО и сетевыми инженерами ряд новых условий, вызывающих задержку сигнала, которые им приходится учитывать для формирования качественного доступа к данным в облаке. Например, задержка длительностью 500мс приводит к снижению трафика Google на 20%, а задержка в 100мс сокращает продажи Amazon на 1%.
Время задержки может быть очень важным аспектом во время работы с виртуальными рабочими столами (VDI), потоковым вещанием, трейдингом, передовыми web-сервисами, базами данных, терминальными приложениями. Но задержка не столь критична для таких сервисов как электронная почта или работа с документами.
QoS и SLA
Существует проблема обеспечения необходимого качества обслуживания (QoS). Разные виды трафика имеют различные требования к рабочим характеристикам сети. Чувствительность видов трафика была взята из и показана в таблице 1
Таблица 1. Чувствительность различных приложений сетевым характеристикам
Тип трафика
Уровень чувствительности к сетевым характеристикам
Полоса
пропускания
Потери
Задержка
Джиттер
Голос
Очень низкий
Средний
Высокий
Высокий
Электронная коммерция
Низкий
Высокий
Высокий
Низкий
Транзакции
Низкий
Высокий
Высокий
Низкий
Электронная почта
Низкий
Высокий
Низкий
Низкий
Telnet
Низкий
Высокий
Средний
Низкий
Поиск в сети "от случая
к случаю"
Низкий
Средний
Средний
Низкий
Постоянный поиск в
сети
Средний
Высокий
Высокий
Низкий
Пересылка файлов
Высокий
Средний
Низкий
Низкий
Видеоконференция
Высокий
Средний
Высокий
Высокий
Мультикастинг
Высокий
Высокий
Высокий
Высокий
Рекомендации МСЭ-Т по обеспечению QoS для сетей описываются в рекомендациях Y.1540 - стандартные сетевые характеристики для передачи пакетов в сетях IP, и Y.1541 нормы для параметров, определенных в Y.1540.
Данные рекомендации важны для всех участников сети: провайдеров и операторов, пользователей и производителей оборудования. При создании оборудования, планировании развертывания и оценке сетей IP, оценка качества функционирования сети все будут опираться на соответствие характеристик требованиям потребителей.
Основные характеристики, рассматриваемые в рекомендации Y.1540:
производительность сети;
надежность сети/сетевых элементов;
задержка;
вариация задержки (jitter);
потери пакетов.
Подробнее о данных характеристиках следует прочитать в вышеназванных рекомендациях. В таблице 2 указаны нормы на определенными в Y.1540 характеристики и распределены по классам качества обслуживания (QoS).
Таблица 2 - Нормы для характеристик сетей IP с распределением по классам QoS
Сетевые
характеристики
Классы QoS
0
1
2
3
4
5
Задержка доставки пакета
IP, IPTD
100 мс
400 мс
100 мс
400 мс
1 с
Н
Вариация задержки
пакета IP, IPDV
50 мс
50 мс
Н
Н
Н
Н
Коэффициент потери
пакетов IP, IPLR
1х10 3
1х10 3
1х10 3
1х10 3
1х10 3
Н
Коэффициент ошибок
пакетов IP, IPER
1х10 4
1х10 4
1х10 4
1х10 4
1х10 4
Н
Примечание: Н не нормировано. Рекомендация Y.1541 устанавливает соответствие между классами QoS и приложениями:
Класс 0 приложения реального времени, чувствительные к джиттеру, характеризуемые высоким уровнем интерактивности (VoIP, видеоконференции);
Класс 1 приложения реального времени, чувствительные к джиттеру, интерактивные (VoIP, видеоконференции);
Класс 2 транзакции данных, характеризуемые высоким уровнем интерактивности (например, сигнализация);
Класс 3 транзакции данных, интерактивные;
Класс 4 приложения, допускающие низкий уровень потерь (короткие транзакции, массивы данных, потоковое видео)
Класс 5 традиционные применения сетей IP.
Таким образом некоторые из облачных сервисов вполне могут попадать в классы 0 и 1, а значит следует учитывать время задержки и стараться сделать так, чтобы она не превышала 100 мс.
Задержки в сетях
Подключение к облаку через VPN аналогично подключению к центральному офису организации по VPN, за исключением лишь того, что если в обычной корпоративной сети все филиалы организации подключались к центральному офису, то теперь подключение филиалов и центрального офиса в том числе будет осуществляться к ЦОД облачного провайдера.
Для проверки задержки в большинстве ОС используется команда ping, а для проверки пути прохождения пакета команда tracert, которые подробнее рассмотрим ниже.
Предположим, что домашняя сеть является подобием корпоративной сети малого предприятия. В таблице в приложении А собраны данные из статьи с указанием расположения ЦОД.
Воспользуемся этими данными чтобы проверить задержку сигнала от текущей домашней сети, расположенной в городе Москва, без учета VPN, до web-сервера некоторых компаний, владеющих, ЦОД, расположенных в разных городах, тем самым проверяя разницу в задержке в зависимости от расположения ЦОД облачного провайдера.
Для проверки задержки воспользуемся "Командной строкой" Windows и командами ping и tracert. Команда ping используется для проверки целостности и качества соединения в сети на основе протоколов TCP/IP. Команда tracert строит маршрут через коммутационные узлы между компьютером и конечным сервером и выводит их IP-адреса и время
задержки. На рисунках 1 и 2 представлена системная справка по командам, соответственно, tracert и ping.
Проведем тест проверки задержки до домена DataLine dtln.ru, расположенного ближе всего к домашней сети (рисунки 3 и 4).
Как видно из результатов на рисунке 5.3, было передано и получено 4 пакета объемом 32 байта. Время обмена одним пакетом составило 1 миллисекунду.
Команда tracert вывела следующие данные:
1, 2, 3 - номер перехода;
<1 мс <1 мс <1 мс время ответа для 3-х попыток (в данном случае все попытки менее 1 мс);
185.3.141.232 IP-адреса (в данном случае IP-адрес домена
dtln.ru)
Согласно проверке данного IP на сайте 2ip.ru, данный домен базируется по тому же адресу на карте, что и указано в таблице в приложении Б. Таким образом можно сделать вывод, что web-сервер большинства компаний из списка вероятнее всего находится на территории одного из их ЦОД, но даже если и нет, то позволяет сделать выводы о доступности ресурса.
Аналогично проверим ping для остальных компаний, результаты представим на рисунке 5.5. В качестве опорного времени задержки будет использовано среднее и максимальное время приема-передачи.
Из данных рисунка 5 можно сделать вывод, что среднее значение времени задержки в пределах Москвы из сети, также находящейся в пределах Москвы, чаще всего не превышает 10мс.
Можно сравнить данные значения с ping до серверов Amazon Web Services в разных регионах с сайта cloudping.info (рисунок 6).
VPN без шифрования теоретически позволил бы сократить эту задержку в связи с использованием "прямого туннеля" между "офисом" и ЦОД. Шифрование будет вносить уже свою задержку, проверить которую в данных условиях нет возможности.
В локальных сетях корпоративной сети и сети ЦОД задержка исчисляется в микросекундах. В сети ЦОД предъявляются высокие требования к быстродействию сети, современные решения Ethernet для ЦОД должны быть широкополосными и поддерживать скорости 10, 25, 40, 50, 100 Гбит/с, обеспечивать низкие задержки до 1-2 мкс для связи серверов (через три коммутатора), и многие другие.
Скорость интернет-канала
Передача видео через сети связи, будь то видео с камер наблюдения или же видеоконференции, являются одними из самых требовательных с скорости передачи данных. Если для работы с документами может быт достаточно скорости в 100 Кбит/с, то для передачи видео понадобится уже примерно 2 Мбит/с.
Для некоторых приложений, таких как IP-телефония, желательно, чтобы уровень задержек был низким, а мгновенная пропускная способность канала была больше определенного порогового значения: не ниже 24 Кбит/с для ряда приложений IP-телефонии, не ниже 256 Кбит/с для приложений, обрабатывающих видеопоток в реальном времени. Для некоторых приложений задержки не так критичны, но, с другой стороны, желательна высокая пропускная способность, например, для передачи файлов.
Например, компания Ivideon предлагает услуги облачного видеонаблюдения, и у них на сайте даются следующие требования к интернет-каналу для разного качества видеопотока. Данные представлены в таблице 3.
Таблица 3 Требования к интернет-каналу для одной камеры видеонаблюдения при разных разрешения при частоте 25 кадров/сек
Разрешение Качество изображения
Рекомендуемая скорость
1280х720 (1Mpx) /25к/с
1 Мбит/с
1920x1080 (2Mpx) /25к/с
2 Мбит/с
2048x1536 (3Mpx) /25к/с
2 Мбит/с
2592x1728 (4Mpx) /25к/с
2 Мбит/с
Но для работы с терминальными сессиями достаточно канала в 128-256 Кбит/с на пользователя. Для 50 пользователей понадобится 6.25 Мбит/с.
Компания 1cloud.ru при выборе ширины канала связи предлагает скорость соединения в диапазоне от 10 до 100 Мбит/с для доступа к виртуальному серверу.
Внутри облака сетевые соединения между виртуальными машинами имеют пропускную способность в 1 Гбит/с.
RDP-сессия
Для теста потребления трафика при использовании удаленного подключения RDP был проведен эксперимент.
Два персональных компьютера находятся в одной локальной сети и подключены к интернету. Один выступает сервером удаленного доступа, второй подключается к нему посредством встроенной в Windows программы
"Подключение к удаленному рабочему столу" по протоколу RDP. На сервере запускается видео в интернете. Для захвата трафика и анализа используется ПО Wireshark
Параметры подключения:
размер удаленного рабочего стола 1920х1080
глубина цвета 15 бит
выбранная скорость соединения 56 Кбит/с
дополнительные возможности отключены (рисунок 7)
Wireshark программа для захвата и анализа сетевого трафика. Данная программа работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс, и мощнейшую систему фильтров.
Во время подключения к удаленному рабочему столу программа замеряла отправленные и поступившие пакеты данных. Эти пакеты были отфильтрованы по IP-адресу сервера, а также по протоколу RDP. Интерфейс программы представлен на рисунке 8.
График ввода/вывода данных по IP-адресу сервера по протоколу RDP представлен на рисунке 9.
На графике на рисунке 9 видно два "всплеска" данных, т.е. две сессии подключения к серверу. Во время первой сессии проводилась работа с тяжеловесным графическим приложением. Во время второй сессии было включено видео, затем производился web-серфинг в браузере машины с некоторыми графическими материалами на странице.
Как видно по графику, в пиковый момент была передача данных 5.5 Мбит/с. В последние моменты web-серфинга 0,65 Мбит/с.
Таким образом можем сделать вывод, что протокол RDP не укладывается в ранее заявленный диапазон до 128 Кбит/с. Однако стоит учитывать, что RDP-сессия изначально очень требовательна к сети и является, по сути, передачей видеотрафика.
Общедоступной информации в сети для анализа влияния облачной инфраструктуры на сеть, по крайней мере в русскоязычном сегменте интернета, чрезвычайно мало. Исследований по теме облачных вычислений недостаточно для заключения результата, и, в основном, это анализы финансовых затрат или производительности серверов.
Наиболее подходящей темой для дискуссий на тему влияния облачной инфраструктуры на сеть могут служить только качество обслуживания (QoS) и договор о предоставлении услуг SLA, но данные темы слишком обширны и требует более углубленного внимания, а вопросы, связанные с ними, требуют внимания соответствующих специалистов.
Хотим чуть-чуть рассказать про достаточно новую и не описанную нами ранее платформу Chat2Desk, которая умеет объединять сообщения из мессенджеров, социальных сетей, почты и смс. Зачем такое надо? А вот зачем – это удобный инструмент для контакт-центров (у вас же есть контакт-центр, верно?), который содержит в себе также конструктор чат-ботов, автоматическую воронку продаж и инструменты для разнообразной аналитики. В статье мы кратко пройдемся по следующему функционалу:
Подключение социальных сетей;
Подключение мессенджеров;
Подключение почты;
Чат на сайт;
Роли в системе;
Конструктор чат-ботов;
Автоответы;
Мобильное приложение.
Подключение социальных сетей
Не секрет, что многие компании сейчас ведут общение с клиентами через социальные сети – как в целях поддержки, так и в целях лидогенерации. Казалось бы, зачем нужно их «скрещивать» в одном инструменте? В основном, чтобы оператору поддержки или SMM-менеджеру не нужно было держать открытыми несколько вкладок и переключаться между ними, случайно закрывать нужную, открывать обратно, забывать – ну вы поняли. Итак, В Chat2Desk можно подключить:
Facebook
VK
Odnoklassniki
Для подключения необходимо создать группу или паблик и узнать ключ API, который нужно будет сообщить менеджеру Chat2Desk, который как раз таки и отрабатывает такие заявки на подключения :) А вы что, ожидали подробной инструкции?
Подключение мессенджеров
Мессенджеры подключаются чуть иначе, так как публичным API обладает только не очень заблокированной известный мессенджер Telegram. Соответственно, более подробно мы про него и расскажем :)
Для подключения того самого Telegram необходимо будет зарегистрировать бота и получить API ключ.
И далее все каналы подключаются через «Настройки» - «Аккаунты и каналы»- «Создать новый».
В свою очередь, для других мессенджеров нужно будет следовать инструкциям менеджера платформы. Подключить Viber и WhatsApp лучше всего на отдельный номер, который будет использоваться только для коммуникации с клиентами через эти мессенджеры – подробно касаться этого в статье мы не будем.
Подключение почты
Какой может быть агрегатор различных каналов для контакт-центров без электронной почты? Вот и мы так подумали. Однако, Chat2Desk не обладает преднастроенной интеграцией с почтовыми сервисами, поэтому придется покопаться в настройках почтового ящика, чтобы найти необходимые данные для подключения. Оператор поддержки (он же менеджер, хи-хи) Chat2Desk сможет проконсультировать какие именно параметры ему нужны для интеграции. Практически все подключения каналов происходят через чат с менеджерами Chat2Desk, что не всегда удобно – особенно для таких как мы, которые любят все делать руками :)
Чат на сайт
Но кто не любит всплывающие чаты на ваших сайтах? Если что - у нас такой тоже есть, кстати говоря. Chat2Desk также предлагает установить фирменный чат-бокс на сайт. Его можно кастомизировать в разделе «Настройки» - «Оформление». Стоимость лицензии Chat2Desk формируется из количества каналов, которые подключены к платформе. Скрипт чата на сайте – единственный бесплатный канал.
Роли в системе
В системе используется простая иерархия, состоящая из 3-х довольно стандартных возможных ролей с различным уровнем доступа:
Администратор
Супервайзер
Оператор
Назначать роли обычно может Администратор, так как он является главным элементом. Можно ограничивать доступ к настройкам, к просмотру аналитики и даже к каким-то клиентам, если это необходимо. Например, если с крупными VIP-клиентами общается только специальный отдел.
Конструктор чат-ботов
С помощью платформы можно легко создать скрипт, который будет реагировать на ключевые слова и выдавать готовые ответы. Настроить чат-бот можно в «Настройки»-«Чат-бот».
Далее нужно составить группы ключевых слов и ответы на сообщения, их содержащие.
Параметр Стоп-слова (flugegeheimen, не забывайте!) отключает чат-бот от диалога, даже если в сообщении есть ключевые слова.
Автоответы
Функция автоответов несколько схожа с чат-ботом, но нужна скорее для быстрого принятия чата и приветствия клиента. Автоответы помогают разгрузить операторов, так как им не нужно постоянно вводить «Доброе утро! Чем я могу вам помочь?». Сообщение такого характера автоматически отправится клиенту, как только он написал. Благодаря переменным, можно указать имя пользователя и подходящее приветствие «Добрый день» или «Добрый вечер».
Мобильное приложение и оно же - заключение
У платформы chat2desk нет десктопного или мобильного приложения. При использовании сервиса с компьютера или ноутбука – достаточно залогиниться и отметить свой статус как он-лайн, чтобы начать обрабатывать обращения. Просматривать переписку и чаты со смартфона можно в специальном Telegram боте. Это экономит память и ресурсы гаджета. Так что не жалуйтесь.