МЕТОДИЧЕСКОЕ ПОСОБИЕ ЛЕКЦИОННОГО МАТЕРИАЛА ПО ДИСЦИПЛИНЕ: «ЭКСПЛУАТАЦИЯ ОБЪЕКТОВ СЕТЕВОЙ ИНФРАСТРУКТУРЫ»

АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ

ОРГАНИЗАЦИЯ

«БАЛТИЙСКИЙ ИНФОРМАЦИОННЫЙ ТЕХНИКУМ»

МЕТОДИЧЕСКОЕ ПОСОБИЕ ЛЕКЦИОННОГО МАТЕРИАЛА ПО ДИСЦИПЛИНЕ:

«ЭКСПЛУАТАЦИЯ ОБЪЕКТОВ СЕТЕВОЙ

ИНФРАСТРУКТУРЫ»

для специальности: 09.02.06 «Сетевое и системное администрирование».

Подготовила: Cлавинская Т.В 

Калининград 2021 г.

Введение

Профессиональный модуль «Эксплуатация объектов сетевой инфраструктуры»  логически взаимосвязан с профессиональными модулями и учебными дисциплинами специальности СПО 09.02.06 Сетевое и системное администрирование: основы электротехники, основы теории информации, технологии физического уровня передачи данных, архитектура аппаратных средств, операционные системы, основы программирования и баз данных, организация сетевого администрирования, проектирование сетевой инфраструктуры.

Лекционный материал по профессиональному модулю «Эксплуатация объектов сетевой инфраструктуры» составлен в соответствии с рабочей программой дисциплины МДК 03.01 Эксплуатация объектов сетевой инфраструктуры на тему 1.2. «Эксплуатация систем IP-телефонии».

  Работа устройств в сети Интернет осуществляется с использованием специального Интернет-протокола (Internet Protocol - IP). В настоящее время протокол IP используется не только в сети Интернет, но и в других сетях передачи данных с пакетной коммутацией (локальных, корпоративных, региональных и др.). И во всех этих сетях, в принципе, имеется возможность передавать речевые сообщения с использованием пакетов данных. Такой способ передачи речи и получил название IP-телефония. За рубежом обычно употребляется аббревиатура VoIP - Voice over IP, хотя часто используют более узкий термин «Интернет-телефония». 

Аналоговая передача звука требовала наличия на АТС по одному порту для каждого абонента. Содержание такого оборудования стоит дорого, поэтому со всех абонентов взималась фиксированная ежемесячная плата за использование услуг связи и дополнительные платежи за межрегиональные вызовы с поминутной тарификацией. Появление IP телефонии позволило передавать двухсторонний поток аудиоданных по сети интернет, уравняв местные и международные звонки. VoIP телефония предполагала размещение оборудования в офисе абонента. Телефоны сотрудников в радиусе действия док станции могли соединяться между собой бесплатно. Удалённые сотрудники подключались к корпоративной сети через интернет и оплачивали только стоимость мобильного трафика. При этом вызовы на городские и мобильные номера за пределами корпоративной сети обслуживал VoIP провайдер по принципу поминутной или посекундной тарификации.

Современное оборудование для передачи голоса посредством протокола IP (VoIP) позволяет обеспечивать приоритет передачи голосового трафика над передачей обычных данных, получать приемлемое качество звукового сигнала при сильном сжатии, эффективно подавлять различные шумы.

Сегодня телекоммуникационные операторы, специализирующиеся на предоставлении услуг IP-телефонии, применяют выделенные каналы с приоритетом голосового трафика над трафиком данных, что гарантирует высокое качество передачи речи. При этом используется сразу несколько вариантов маршрутизации голосового трафика для каждого из тысяч направлений, а в случае возникновения каких-либо проблем трафик автоматически перенаправляется на другие каналы.

По мере своего развития IP-телефония претерпевает важные качественные изменения: из дополнительной услуги она постепенно превращается в некий базовый сервис, который с течением времени становится одним из компонентов мультисервисной технологии. Важную роль играют сигнальные протоколы VoIP для передачи голосового трафика. Активно развиваются, во-первых, Н.323, берущий свое начало от традиционных телефонных протоколов, и, во-вторых, протоколы, созданные на базе IP-технологий, - такие как SIP, MGCP, MEGACO.

Появление SIP и софтфонов сделали IP телефонию на ПК доступной для широкого круга пользователей. Клиент-серверное приложение использовало классические http и FTP серверы для обмена файлами и голосовых вызовов. При этом наличие безлимитного интернет трафика в домашней сети клиента означало бесплатные звонки по всему миру, но общаться могут только пользователи одного и того же приложения. Чтобы организовать подключение домашней или офисной сети к глобальной сотовой и городской линии необходим SIP сервер.

Российские операторы IP-телефонии наиболее часто использовали протоколы группы Н.323. Это вызвано тем, что данный протокол был первым общепринятым стандартом промышленной реализации IP-телефонии. В настоящее время все большее внимание уделяется SIP. Протокол SIP в этой группе является самым простым видом протокола, более доступным для восприятия и понимания рядовым IT-

специалистом. SIP особенно хорош в использовании во внутрикорпоративных сетях. При этом внешним протоколом в сети телекоммуникационного оператора для предприятия может применяться протокол  MGCP/MEGACO.

Как было отмечено, IP-телефония становится одним из компонентов решения передачи разнородного мультимедийного трафика с использованием протокола TCP/IP. И вполне естественно, что развитие отдельных инструментов управления мультимедийным трафиком влияет на всю систему технологий пакетной передачи данных.

Следует также иметь в виду, что IP-телефония - это не просто альтернатива обычной телефонии. Актуальность развития решений IP-телефонии обусловлена не только возможностью снижения затрат на телефонные переговоры и техническое обслуживание инфраструктуры (хотя и это, безусловно, имеет значение). В стратегическом плане IPтелефония может стать единой технической платформой, которая позволит объединить решения для передачи данных и голоса, а также для обработки и последующего использования этой информации во всех бизнес-процессах. Таким образом, развитие IPтелефонии в определенном смысле является средством повышения производительности труда и развития бизнеса. На сегодняшний день IP-телефония все больше вытесняет традиционные телефонные сети за счет легкости развертывания, низкой стоимости звонка, простоты конфигурирования, высокого качества связи и сравнительной безопасности соединения.

В России деятельность по предоставлению услуг Интернет-телефонии подлежит лицензированию. Интернет - телефония в силу ряда технологических и потребительских особенностей отличается от традиционной телефонной связи. Эти отличия учитываются при решении вопроса лицензирования деятельности операторов по предоставлению услуг Интернет-телефонии. Именно поэтому Интернет-телефония классифицируется как разновидность услуг телематических служб.

Компаниям, которые планируют заниматься Интернет-телефонией и уже владеют какойлибо лицензией на любую другую телематическую службу, необходимо подать заявку на расширение имеющейся лицензии. При отсутствии  лицензии подается заявка на новую лицензию. 

Нормативные документы, регулирующие деятельность операторов Интернет-телефонии в России, разрабатываются  рабочей  группой «Интернет-телефония» при Ассоциации документальной электросвязи (АДЭ). 

1. Виды соединений, взаимодействие с компьютерной сетью

Работа IP-телефонии, передача голоса, аудио-, видео-, конференц-связь имеет свою существенную специфику, особенно в условиях уже созданных компьютерных сетей. 

Можно выделить три наиболее часто используемых сценария IP-телефонии:

          компьютер-компьютер;              телефон-компьютер;              телефон-телефон.

Первый сценарий "компьютер-компьютер" реализуется на базе стандартных компьютеров, оснащенных средствами мультимедиа и подключенных к сети Интернет.

Компоненты сценария "компьютер-компьютер" показаны на рис. 1. В этом сценарии аналоговые речевые сигналы от микрофона абонента А преобразуются в цифровую форму с помощью аналого-цифрового преобразователя (АЦП). Отсчеты речевых данных в цифровой форме затем сжимаются кодирующим устройством для сокращения нужной для их передачи полосы в отношении 4:1, 8:1 или 10:1. 

Выходные данные после сжатия формируются в пакеты, к которым добавляются заголовки протоколов, и затем пакеты передаются через IP-сеть в систему IP-телефонии, обслуживающую абонента Б. Когда пакеты принимаются системой абонента Б, заголовки протокола удаляются, а сжатые речевые данные поступают в устройство, развертывающее их в первоначальную форму, после чего речевые данные снова преобразуются в аналоговую форму с помощью цифро-аналогового преобразователя (ЦАП) и попадают в динамик телефона абонента Б. Для обычного соединения между двумя абонентами системы IP-телефонии на каждом конце одновременно реализуют как функции передачи, так и функции приема. Под IP-сетью, подразумевается либо глобальная сеть Интернет, либо корпоративная сеть предприятия Intranet. Для проведения телефонных разговоров друг с другом абоненты А и Б должны иметь доступ к Интернету или к другой сети с протоколом IP.

 

Рис. 1. Сценарий IP-телефонии "компьютер-компьютер"

Для поддержки сценария "компьютер-компьютер" поставщику услуг Интернет необходимо иметь отдельный сервер (GateKeeper), преобразующий имена пользователей в динамические адреса IP. Сам сценарий ориентирован на пользователя, которому сеть нужна в основном для передачи данных, а программное обеспечение IP-телефонии требуется лишь иногда для разговоров с коллегами. Эффективное использование телефонной связи по сценарию "компьютер-компьютер" обычно связано с повышением продуктивности работы крупных компаний, например, при организации виртуальной презентации в корпоративной сети с возможностью не только видеть документы на веб-сервере, но и обсуждать их содержание с помощью IP-телефона.

Следующий сценарий "телефон-компьютер" находит применение в разного рода справочно-информационных службах Интернета, в службах сбыта товаров или в службах технической поддержки. Пользователь, подключившийся к cepвepy WWW какой-либо компании, имеет возможность обратиться к оператору справочной службы. Это вполне соответствует стилю жизни современных потребителей, связанному с потребностью в дополнительных удобствах и экономии времени.

Во втором сценарии "телефон-компьютер" соединение устанавливается между пользователем ТфОП и пользователем IP-сети (рис. 2). Предполагается, что установление соединения инициирует пользователь сети коммутации каналов.

 

Рис. 2. Пользователя IP-сети вызывает абонент ТфОП по сценарию "телефон-компьютер"

Шлюз для взаимодействия сетей ТфОП и IP может быть реализован как отдельным устройством, так и интегрированным в существующее оборудование ТфОП или IP-сети. Показанная на рисунке сеть коммутации каналов может быть корпоративной сетью или сетью общего пользования.

Возможна и иная разновидность второго сценария, когда соединение устанавливается между пользователем IP-сети и абонентом ТфОП, но инициирует его создание абонент ТфОП. При попытке вызвать справочно-информационную службу, используя услуги пакетной телефонии и обычный телефон, на начальной фазе абонент А вызывает близлежащий шлюз IP-телефонии для минимизации затрат на услуги связи. От шлюза к абоненту А поступает запрос ввести номер, к которому должен быть направлен вызов (например, номер службы), и личный идентификационный номер (PIN) для аутентификации и последующего начисления платы, если эта служба платная. Основываясь на вызываемом номере, шлюз определяет наиболее доступный путь к данной службе. Кроме того, шлюз активизирует свои функции. Разъединение с любой стороны передается противоположной стороне по протоколу сигнализации и вызывает завершение установленных соединений и освобождение ресурсов шлюза для обслуживания следующего вызова.

Эффективность объединения услуг передачи речи и данных является основным стимулом использования IP-телефонии по сценариям "компьютер-компьютер" и "телефонкомпьютер", не нанося при этом ущерба интересам операторов традиционных телефонных сетей.

Третий сценарий "телефон-телефон" в значительной степени отличается от первых двух сценариев IP-телефонии своей социальной значимостью, поскольку целью его применения является предоставление обычным абонентам ТфОП альтернативной возможности междугородной и международной телефонной связи.

Обслуживание вызовов по такому сценарию IP-телефонии выглядит следующим образом. Поставщик услуг IP-телефонии подключает свой шлюз к коммутационному узлу или станции ТфОП по сети Интернет или по выделенному каналу к аналогичному шлюзу, находящемуся в другом городе или другой стране.

Типичная услуга IP-телефонии по сценарию "телефон-телефон" использует стандартный IP-телефон, а вместо междугороднего компонента ТфОП задействует либо частную IP-сеть, либо сеть Интернет. Благодаря маршрутизации телефонного трафика по IP-сети стало возможным обходить сети общего пользования и, соответственно, не платить за междугороднюю/международную связь операторам этих сетей.

Как показано на рис.3, поставщики услуг IP-телефонии предоставляют услуги "телефонтелефон" путем установки шлюзов IP-телефонии на входе и выходе IP-сетей. Абоненты подключаются к шлюзу поставщика услуг IP-телефонии через ТфОП, набирая специальный номер доступа. Абонент получает доступ к шлюзу, используя персональный идентификационный номер (PIN) или услугу идентификации номера вызывающего абонента (Calling Line Identification). После этого шлюз просит ввести телефонный номер вызываемого абонента, анализирует этот номер и определяет, какой шлюз имеет лучший доступ к нужному телефону. Как только между входным и выходным шлюзами устанавливается контакт, дальнейшее установление соединения к вызываемому абоненту выполняется выходным шлюзом через его местную телефонную сеть.

Полная стоимость такой связи будет складываться для пользователя из расценок ТфОП на связь с входным шлюзом, расценок интернет-провайдера на транспортировку данных и расценок удаленной ТфОП на связь выходного шлюза с вызванным абонентом.

 

Рис. 3. Соединение абонентов ТфОП через транзитную IP-сеть по сценарию "телефонтелефон"

Одним из алгоритмов организации связи по сценарию "телефон-телефон" является выпуск поставщиком услуги своих телефонных карт. Имея такую карту, пользователь, желающий позвонить в другой город, набирает номер поставщика данной услуги, затем в режиме до набора вводит свой идентификационный номер и PIN-код, указанный на карте. После процедуры аутентификации он набирает телефонный номер адресата.

2. Архитектура системы для построения сетей IP-телефонии на базе стандарта Н.323

Первой  рекомендацией для построения сетей IP-телефонии стала рекомендация H.323 СЭ (ITU-T). Н.323 является первой зонтичной спецификацией систем мультимедийной связи для работы в сетях с коммутацией пакетов, не обеспечивающих гарантированное качество обслуживания.

Стандарт Н.323  входит в  семейство рекомендаций Н.32х, описывающих порядок организации мультимедиа-связи в сетях различных типов:

-  Н.320 - узкополосные цифровые коммутируемые сети;

-  Н.321 - широкополосные сети ISDN и ATM;

-  Н.322 - пакетные сети с гарантированной полосой пропускания; - Н.324 - телефонные сети общего пользования (ТфОП).

Рекомендация Н.323, разработанная МСЭ-Т, содержит описания терминальных устройств, оборудования и сетевых служб, предназначенных для осуществления мультимедийной связи в сетях с коммутацией пакетов (например, в Интернет или корпоративной Интранет). Корпоративная Интранет обычно строится на базе семейства протоколов TCP/IP и предоставляет возможность абонентам обмениваться данными с одним или несколькими WEB-серверами, на которых сосредоточены основные информационные ресурсы. Корпоративная Интранет характеризуется повышенной надежностью и имеет ограниченный доступ. 

В рекомендации Н.323 описываются четыре основных компонента (Рис.4): 

•       терминал; 

•       контроллер зоны (Gatekeeper); 

•       шлюз (Gateway); 

•       устройство управления многоточечной конференцией (MCU). 

 

Рис.4 Компоненты сети, поддерживающей обмен по протоколу H.323

Основными устройствами сети являются: терминал, шлюз, привратник и устройство управления конференциями. Устройства Н.323 не имеют жестко закрепленного места в сети. Устройства подключаются к любой точке IP-сети, но при этом сеть Н.323 разбивается на зоны, а каждой зоной управляет привратник (Gatekeeper).

Терминал H.323 – это оконечное устройство сети IP-телефонии, обеспечивающее двухстороннюю речевую или мультимедийную связь с другим терминалом, шлюзом или устройством управления конференциями (рис. 5). При этом терминалом для сети Н.323 может оказаться обычный телефонный аппарат, с которого абонент позвонил на шлюз с помощью предоплаченных карт или персональный компьютер с установленным мультимедийным приложением (например, NetMeeting). Сейчас появилось понятие упрощенных H.323 терминалов, которые поддерживают аудио или текстовую связь согласно H.323, но не реализуют весь функционал классического H.323 терминала.

 

Рис.5 Терминал стандарта Н.323

Терминал должен содержать: 

•       элементы аудио (микрофон, акустические системы, телефонный микшер, систему акустического эхоподавления); 

•       элементы видео (монитор, видеокамера);   элементы сетевого интерфейса;   интерфейс пользователя. 

Терминал Н.323 должен поддерживать протоколы Н.245, Q.931, RAS, RTP/RTCP и семейство протоколов Н.450.x и обеспечивать кодирование/декодирование аудио информации в соответствии с Рекомендацией G.711.

Модуль управления поддерживает три вида сигнализации: H.225, Н.245, RAS и обеспечивает регистрацию терминала у привратника, установление и завершение соединения, обмен информацией, необходимой для открытия разговорных каналов, предоставление дополнительных услуг и техобслуживание.

Телематические приложения обеспечивают передачу пользовательских данных, неподвижных изображений и файлов, доступ к базам данных и т. п. Стандартным протоколом для поддержки таких приложений является протокол Т.120.

Модуль H.225.0 отвечает за преобразование видеоинформации, речи, данных и сигнальной информации в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP, и наоборот. Кроме того, функциями модуля являются разбиение информации на логические кадры, нумерация последовательно передаваемых кадров, выявление и коррекция ошибок.

Сетевой интерфейс обеспечивает гарантированную передачу управляющих сообщений Н.245, сигнальных сообщений Н.225.0 (Q.931) и пользовательских данных при помощи протокола TCP и негарантированную передачу речевой и видеоинформации, а также сообщений RAS при помощи протокола UDP.

Блок синхронизации вносит задержку на приемной стороне с целью обеспечить синхронизацию источника информации с ее приемником, согласование речевых и видеоканалов или сглаживание вариации задержки информации.

Видеокодеки кодируют видеоинформацию, поступающую от внешнего источника видеосигналов (видеокамеры или видеомагнитофона), для ее передачи по сети с маршрутизацией пакетов IP и декодируют сигналы, поступающие от сети, для последующего отображения видеоинформации на мониторе или телевизоре.

Аудиокодеки кодируют аудиоинформацию, поступающую от микрофона (или от других источников), для ее передачи по сети с маршрутизацией пакетов IP и декодируют сигналы, поступающие от сети, для последующего воспроизведения.

Шлюзы Н.323 

Шлюз обеспечивает компрессию данных (голоса), конвертирование их в IP-пакеты и направление в IP-сеть. При приеме пакетов с голосовыми данными шлюз осуществляет обратные действия: расформирование IP-пакетов и декомпрессию. В результате обычные телефонные аппараты без проблем принимают речевую информацию. 

Основные функции, выполняемые шлюзом, таковы: 

•       реализация физического интерфейса с телефонной и IP-сетью; 

•       генерация и детектирование сообщений абонентской сигнализации; 

•       преобразование сообщений абонентской сигнализации в пакеты данных и обратно; 

•       преобразование речевого сигнала в пакеты данных и обратно; 

•       установление соединения между абонентами; 

•       передача по сети IP-пакетов с сигнальной и речевой информацией ;   разъединение соединений. 

Большая часть функций шлюза в рамках архитектуры TCP/IP реализуются процессами прикладного уровня. 

Gatekeeper H.323 

Функцию управления вызовами выполняет Gatekeeper (контроллер зоны). Контроллер зоны выполняет следующие функции:  

•       преобразование адреса-псевдонима в транспортные адреса; 

•       контроль доступа в сеть на основании авторизации вызовов, наличия необходимой для связи полосы частот и других критериев, определяемых производителем;   контроль полосы пропускания;   управление зонами. 

Контроллер зоны осуществляет вышеперечисленные функции в отношении терминалов, шлюзов и устройств управления, зарегистрированных в нем. Идентификация узла может осуществляться по его текущему IP-адресу, телефонному номеру Е.164 или подстановочному имени - строке символов, подобно адресу электронной почты. Контроллер зоны упрощает процесс обслуживания вызова, предоставляя пользователю использовать легко запоминающееся подстановочное имя. Привратник выполняет функции управления зоной сети IP-телефонии, в которую входят терминалы, шлюзы и блоки конференций, зарегистрированные у этого привратника.

Разные участки зоны сети H.323 могут быть территориально разнесены и соединяться друг с другом через маршрутизаторы.

Функции контроллера зоны могут быть встроены в шлюзы, элементы распределенных УПАТС, блоки управления многоточечными конференциями, а также в конечные устройства Н.323 (терминалы). С помощью механизмов регистрации, авторизации и статуса (Registration/Admissions/Status, RAS) терминалы могут находить контроллеры зоны и регистрироваться в них. В число наиболее важных функций, выполняемых привратником, входят:

•  преобразование так называемого alias-адреса (имени абонента, телефонного номера, адреса электронной почты и др.) в транспортный адрес сетей с маршрутизацией пакетов IP (IP-адрес и номер порта TCP);

•  контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS (используются сообщения ARQ/ACF/ARJ);

•  контроль, управление и резервирование пропускной способности сети;

•  маршрутизация сигнальных сообщений между терминалами, расположенными в одной зоне; 

•  привратник может организовывать сигнальный канал непосредственно между терминалами или ретранслировать сигнальные сообщения от одного терминала к другому.

Сервер управления конференциями (Multipoint Control Unit, MCU)

Сервер управления конференциями обеспечивает связь трех и более Н.323терминалов. Все терминалы, участвующие в конференции, устанавливают соединение с MCU. Сервер управляет ресурсами конференции, согласовывает возможности терминалов по обработке звука и видео, определяет аудио- и видео потоки, которые необходимо направлять по многим адресам. 

Одна из  дополнительных услуг IP-телефонии, возможность организации конференций, а рекомендация Н.323 предусматривает три вида конференции.

Первый вид – централизованная  конференция, в которой оконечные устройства соединяются в режиме «точка-точка» с устройством управления конференциями (MCU), контролирующим процесс  создания и завершения конференции, а также обрабатывающим потоки пользовательской информации.

Второй вид – децентрализованная  конференция, в которой каждый ее участник соединяется с остальными участниками в режиме «точка-группа точек», и оконечные устройства сами обрабатывают (переключают или смешивают) потоки информации, поступающие от других участников конференции.

Третий вид – смешанная  конференция, т. е. комбинация двух  предыдущих видов.

2.1 Сигнализация по стандарту H.323  

Для обеспечения широкомасштабного внедрения IP-телефонии одним из самых важных факторов является обеспечение совместимости систем разных фирм. Достижение совместимости возможно только на базе стандартных протоколов сигнализации. Протоколы сигнализации обеспечивают установление, администрирование и завершение сеанса связи между конечными точками (терминалами пользователей), однозначно     идентифицируемыми           заданной         схемой            адресации.

Понятие «сигнализация» относится ко всей информации, связанной с вызовами и необходимой для их установления, маршрутизации, мониторинга и завершения как на физическом, так и на логическом уровнях. 

Архитектура протоколов технологии IP-телефонии, подобно модели протоколов ISDN, предусматривает отделение функций управления (сигнализации) от функций доставки пользовательской информации, что является наиболее благоприятным условием для внедрения новых услуг. 

В системах IP-телефонии процедуры управления вызовами выполняются протоколами сигнализации, а непосредственная маршрутизация пакетов через IP-сеть обеспечивается протоколами OSPF или BGP (резервирование сетевых ресурсов возможно, например, при помощи протокола RSVP). 

В Н.323 входит три основных протокола: протокол взаимодействия оконечного оборудования с привратником (RAS, Registration, Admissionand Status), протокол управления соединениями  H.225 и протокол управления логическими каналами Н.245, которые совместно с интернет протоколами TCP/IP, UDP, RTP и RTCP, а также протоколом Q.931, представлены на рис. 6.

Протокол TCP используется для переноса сигнальных сообщений H.225 и управляющих сообщений H.245, сигнальные сообщения RAS переносятся с помощью протокола  UDP, а перенос речевой и видео-информации производится посредством использования RTP/RCP.

 

Рис. 6. Стек  протокола H.323

Для выполнения действий сигнализации между шлюзами и gatekeeper в соответствии с Рекомендацией Н.323 должны использоваться следующие протоколы: 

•       сигнализация RAS (Registration, Admission, Status); 

•       сигнализация Q.931 (согласно Н.225.0);   протокол управления Н.245. 

Протокол RAS

В рекомендации Н.225.0 определен протокол взаимодействия компонентов сети Н.323 оконечного оборудования (терминалов, шлюзов, устройств управления конференциями) с привратником, который получил название Registration, Admission and Status (RAS). RASсообщения служат для регистрации терминалов, допуска их к сеансу связи, изменения используемой полосы пропускания, информирования о состоянии сеанса и его прекращении. В отсутствии контроллера зоны (gatekeeper) протокол RAS не задействуется.

Основные процедуры, выполняемые оконечным оборудованием и привратником с помощью протокола RAS:

•       обнаружение привратника,

•       регистрация оконечного оборудования у привратника,

•       контроль доступа оконечного оборудования к сетевым  ресурсам,

•       определение местоположения оконечного оборудования в сети,

•       изменение полосы пропускания в процессе обслуживания  вызова,

•       опрос и индикация текущего состояния оконечного  оборудования,

•       оповещение привратника об освобождении полосы  пропускания, ранее занимавшейся оборудованием.

Выполнение первых трех процедур, предусмотренных протоколом RAS, является начальной фазой установления  соединения с использованием сигнализации H.323. Далее следуют  фаза сигнализации H.225.0 (Q.931) и обмен управляющими  сообщениями Н.245. Разъединение  происходит в обратной последовательности: в первую очередь закрываются управляющий Н.245 и сигнальный H.225.0 каналы,  после чего по каналу RAS привратник  оповещается об освобождении ранее занятой оконечным оборудованием полосы пропускания.

Передача сообщений RAS осуществляется в дейтаграммах UDP. Для адресации RAS должна использоваться адресная информации, в которую входят: 

•       сетевой адрес оборудования; 

•       идентификатор TSAP (Transport Layer Service Access Point);            мнемонический адрес (Alias Address). 

Сетевой адрес является адресом в формате, используемом в сети с коммутацией пакетов, например, адрес в форматах IPv4, IPv6, IPX, NetBIOS. Идентификатор TSAP используется для идентификации информационных потоков, отправленных с одного сетевого адреса. Для контроллера зоны выделены постоянные значения идентификатора TSAP: 1718 (для поиска gatekeeper) и 1719 (для передачи сообщений сигнализации RAS). Мнемонический адрес служит для адресации оконечного оборудования в удобной пользователю форме. Адресом может быть телефонный номер в формате Е.164, телефонный номер в корпоративной сети, адрес электронной почты и т.д. 

Контроллер зоны не имеет мнемонического адреса. Нахождение контроллера зоны должно осуществляться с помощью широковещательного запроса GRQ (Gatekeeper Request), передаваемого оконечным оборудованием с идентификатором TSAP, равным 1718. Если контроллер зоны найден и он готов обслужить запрос от оконечного оборудования, в ответ он должен получить сообщение GCF (Gatekeeper Confirm). Если оконечное оборудование получило ответ от нескольких контроллеров зоны, выбор одного из них должен осуществляться оконечным оборудованием произвольным образом. Если контроллер зоны не может обслужить запрос от оконечного оборудования, то в ответ он должен передать сообщение GRJ (Gatekeeper Reject), в котором должна сообщаться причина отказа, и может содержаться адрес альтернативного контроллера зоны. При нахождении контроллера зоны между ним и оконечным оборудованием осуществляется установление логического канала сигнализации, по которому будут передаваться остальные сообщения RAS (Рис.7). 

 

Рис. 7 - Этапы прохождения вызова в среде H.323

После нахождения контроллера зоны оконечное оборудование в сообщении RRQ (Registration Request) сообщает свой сетевой и мнемонический адрес. В ответ контроллер зоны должен передать сообщение RCF (Registration Confirm) для подтверждения регистрации оконечного оборудования, либо RRJ (Registration Reject) в случае отказа от регистрации. Сообщение RRQ может передаваться при включении оконечного оборудования. Если при повторной регистрации мнемонический и сетевой адреса, переданные контроллеру зоны оконечным оборудованием, совпадают с ранее переданными, то контроллер зоны должен передать сообщение RCF. Если при повторной регистрации мнемонический адрес равен ранее указанному, а сетевые отличаются, должно быть передано сообщение RRJ с причиной отказа «Duplicate registration». Для отмены регистрации используются сообщения URQ (Unregistered Request), передаваемое оконечным оборудованием, и UCF (Unregistered confirm), URJ (Unregistered reject), передаваемые контроллером зоны оконечному оборудованию. 

Регистрация оконечного оборудования в контроллере зоны может осуществляться один раз и не повторяться при включении оконечного оборудования. В этом случае контроллер зоны должен определять состояние оконечного оборудования. Для этого контроллер зоны должен периодически передавать сообщение IRQ (Information Request). Интервал определяется производителем оборудования и должен быть не менее 10 секунд. 

После регистрации оконечного оборудования в контроллере зоны он может установить соединение с вызываемым оконечным оборудованием. Для этого оконечное оборудование-инициатор должно передать сообщение ARQ (Admissions Request) и установить логический канал для передачи сообщений протокола Q.931. В сообщении ARQ указываются скорость передачи, кратная 100 бит/с, и количество каналов, необходимых для передачи речевой информации. Например, при использовании интерфейсов ISDN для выделения полосы 192 Кбит/с необходимо указать значения соответственно 640 и 3. Скорость указывается без учета размеров заголовков пакетов и блоков данных транспортных протоколов. Если сеть может обеспечить требуемые параметры, то контроллер зоны должен передать подтверждение ACF (Admissions Confirm), в противном случае передается сообщение ARJ (Admissions Reject) с указанием причины отказа. 

После получения подтверждения оконечное оборудование устанавливает соединение с вызываемым оконечным оборудованием с использованием сигнализации Q.931 (в соответствии с Н.225.0). Сообщения сигнализации протокола Q.931 могут передаваться по логическому каналу через контроллер зоны или непосредственно между двумя оконечными устройствами. Выбор способа осуществляет контроллер зоны и сообщает об этом оконечному оборудованию в сообщении ACF. 

Для установления соединения используются сообщения Setup и Connect, после передачи которых устанавливается канал управления Н.245. Канал для передачи информации управления Н.245 может быть установлен двумя способами: через контроллер зоны или непосредственно между оконечными устройствами. В случае если логический канал сигнализации Q.931 устанавливается через контроллер зоны, то канал для передачи информации управления Н.245 также должен устанавливаться через контроллер зоны. Способ установления канала для передачи информации управления Н.245 между оконечным оборудованием в настоящее время не специфицирован. 

Если канал сигнализации RAS установлен, то он может использоваться для установления нескольких соединений. Идентификация сообщений сигнализации, принадлежащих одному и тому же соединению, осуществляется с помощью идентификатора Call ID. 

Сигнализация по протоколу H.225.0 (Q.931) и протокол управления H.245 Стандарт Н.225 описывает протоколы сигнализации и формирования пакетов в системах пакетной передачи мультимедийного трафика. Канал управления вызовами Н.225.0 используется для установления и разрыва соединений между двумя терминалами Н.323, а также между терминалом и шлюзом. Служебные сообщения этого протокола передаются поверх TCP или UDP. Соответствующий механизм Н.225.0 основан на протоколе Q.931, который был разработан для ISDN. Он обеспечивает предоставление целого ряда дополнительных видов обслуживания и возможность взаимодействия с сетями, базирующимися на способе коммутации каналов. Канал управления вызовом не зависит от канала RAS и канала управления Н.245. 

Протокол управления мультимедийной передачей Н.245 обеспечивает: 

•       согласование возможностей компонентов; 

•       установление и разрыв логических каналов; 

•       передачу запросов на установление приоритета;        управление потоком (загрузкой канала);   передачу общих команд и индикаторов. 

Сообщения протокола Н.245 передаются по специальному каналу управления. Это логический канал «0», который, в отличие от каналов обмена мультимедиа-потоками, постоянно открыт. Обмен параметрами между терминалами позволяет согласовывать режимы работы и форматы кодирования информации, что обеспечивает взаимодействие терминалов, изготовляемых разными производителями. В процессе обмена сообщениями о параметрах уточняются возможности терминалов принимать и передавать различные виды трафика. 

Протокол Q.931 реализует следующие функции: 

•       передача запроса на установление соединения; 

•       инициализация соединения и обмен информацией о возможностях терминалов;   установление соединения для передачи речевой информации;   разъединение соединения. 

Для установления соединения инициатор вызова (оконечное оборудование 1) должно передать сообщение Setup оконечному оборудованию 2 по логическому каналу сигнализации с идентификатором TSAP, равным 1719.

В ответ получатель (оконечное оборудование 2) должен передать сообщение Connect, сообщающее инициатору о готовности установить соединение. Инициатор сообщения должен получить сообщения Call proceeding, Connect, Alerting в течение 4 секунд. После получения сообщения Connect должен быть установлен логический канал управления Н.245, по которому передается информация о возможностях оконечного оборудования в сообщении Terminal Capability Set. Для определения инициатора установления канала RTP используется идентификатор Status Determination Number в сообщении Master Slave Determination. После инициализации соединения создается логический канал для передачи речевой информации. Установление канала для передачи речевой информации осуществляется оконечным оборудованием после получения сообщения Open Logical Channel по каналу управления Н.245. Передача речевой информации по логическому каналу должна осуществляться в пакетах RTP. Передача управляющей информации должна осуществляться в пакетах RTCP.

При необходимости изменения требуемой полосы пропускания используется сообщение BRQ (Bandwidth Change Request) сигнализации RAS, которое может передаваться как контроллером зоны, так и оконечным оборудованием. Если изменение полосы пропускания невозможно, то посылается сообщение BRJ (Bandwidth Reject). Если изменение возможно, то передается сообщение BCF (Bandwidth Confirm). Уменьшение полосы пропускания возможно всегда, а для увеличения полосы пропускания свыше значения, указанного в последнем сообщении ARQ, оконечное оборудование должно закрыть все логические каналы и открыть их заново. Логический канал должен быть закрыт сообщением Close Logical Channel протокола управления Н.245, а открыт с новыми параметрами сообщением Open Logical Channel. 

Соединение разрушается следующим образом: 

•       инициатор разъединения должен закрыть канал сообщением Close Logical Channel, передаваемым по каналу управления Н.245; 

•       инициатор разъединения должен передать сообщение End Session Command по каналу управления Н.245; 

•       удаленное оборудование дожидается сообщения End Session Command, передаваемого по каналу управления Н.245; 

•       если логический канал сигнализации для обмена сообщениями протокола Q.931 открыт, он закрывается сообщением Release Complete. 

Если в системе присутствует контроллер зоны, то он должен освободить ранее выделенную полосу пропускания. Освобождение полосы пропускания осуществляется сообщением DRQ (Disengage Request) сигнализации RAS, передаваемым оконечным оборудованием. В ответ должно быть получено сообщение подтверждения DCF (Disengage Confirm) или сообщение отказа DRJ (Disengage Reject). 

Сигнализация по протоколу H.450

Дополнительные услуги в сетях IP-телефонии определяет семейство рекомендаций Н.450. Рекомендация 450.1 описывает протокол сигнализации, используемый при обмене между двумя компонентами сети, позволяющий предоставлять дополнительные услуги.

Вопросы для cамопроверки

1.      Перечислите основные функции привратника?

2.      Каким требованиям должен удовлетворять терминал IP-телефонии?

3.      Зачем нужен шлюз?

4.      Какие виды конференций H.323 вы знаете?

5.      Перечислить основные функции протокола RAS?

6.      Для чего нужно сообщение ARQ в протоколе RAS?

7.      В каком случае пользователь получит сообщение ARJ протокола RAS?

8.      Перечислите основные сообщения Н.225?

9.      Когда посылается сообщение H.225 Setup?

10.  Что означает H.225 Alerting с точки зрения абонента?

11.  Как определяется ведущее и ведомое оборудование в H.245?

12.  В чем разница между однонаправленными и двунаправленными логическими каналами H.245?

3. Сеть на базе протокола SIP

Вторым вариантом построения сетей стал протокол SIP, разработанный группой MMUSIC (Multiparty Multime-dia Session Control) комитета IETF (Internet Engineering Task Force), а спецификации протокола представлены в документе RFC 2543. Протокол инициирования сеансов - Session Initiation Protocol (SIP)- является протоколом прикладного уровня и предназначается для организации, модификации и завершения сеансов связи: мультимедийных конференций, телефонных соединений и распределения мультимедийной информации, в основу которого заложены следующие принципы. При организации мультимедийного сеанса используется два основных метода для нахождения и информирования заинтересованных участников: 

•       уведомление о сеансе с использованием разных средств - электронной почты, групп новостей, Web-страниц или специального протокола SAP (Session Announcement Protocol); 

•       приглашение к участию в сеансе с помощью протокола SIP. 

3.1 Архитектура системы для построения сетей IP-телефонии  по протоколу SIP 

Сеть SIP содержит следующие основные элементы (рис.8). 

 агенты пользователя,   прокси-серверы,    серверы переадресации,  сервер местоположения (location server)

Терминалы могут быть двух типов:

1.  Персональный компьютер со звуковой платой и программным обеспечением SIPклиента.

2.  SIP-телефон, подключающийся непосредственно к ЛВС Ethernet.

Путем программирования сервер  можно настроить на разные алгоритмы работы: он может обслуживать часть пользователей по одним правилам, а другую часть - по иным. Агенты пользователя (User Agent или SIP client) являются приложениями терминального оборудования и включают в себя две составляющие: агент пользователя - клиент (User Agent Client - UAC) и агент пользователя - сервер (User Agent Server - UAS), иначе известные как клиент и сервер соответственно.  Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны.    Сервер UAS принимает запросы и возвращает ответы, т.е. выступает в качестве вызываемой стороны. Кроме того, существует два типа сетевых серверов SIP:   прокси- серверы (серверы-посредники) и 

 серверы переадресации. 

Серверы SIP могут работать как в режиме с сохранением состояний текущих соединений (statefull), так и в режиме без сохранения состояний текущих соединений (stateless). Сервер SIP, функционирующий в режиме stateless, может обслужить сколь угодно большое количество пользователей, в отличие от привратника Н.323, который может одновременно работать с ограниченным количеством пользователей. 

 Прокси-сервер (Proxy-server) действует «от имени других клиентов» и содержит функции клиента (UAC) и сервера (UAS). Этот сервер интерпретирует и может перезаписывать заголовки запросов перед отправкой их к другим серверам. Ответные сообщения следуют по тому же пути обратно к прокси-серверу, а не к клиенту.

Рис.8 Архитектура SIP – сети

Прокси-сервер может модифицировать запросы, которые он переправляет дальше. Проще говоря, пользователь отсылает требование установить соединение на прокси-сервер, а тот сам “заботится” о том, чтобы оно было установлено. Прокси-сервер может размножать запрос и передавать его по разным направлениям, чтобы запрос достиг нескольких мест, в надежде на то, что нужный пользователь окажется в одном из них.

Сервер переадресации (redirect server) передает клиенту в ответе на запрос адрес следующего сервера или клиента, с которым первый клиент связывается затем непосредственно. Он не может инициировать собственные запросы. Адрес сообщается первому клиенту в поле Contact сообщений SIP. Таким образом, этот сервер просто выполняет функции поиска текущего адреса пользователя.

Пользователь может перемещаться от одной оконечной системы к другой, так что нужен какой-то метод определения его местоположения (рис. 8). Для этого в SIP используется сервер местоположения (location server) - это база адресов, доступ к которой имеют SIPсерверы, пользующиеся ее услугами для получения информации о возможном местоположении вызываемого пользователя. Принципы работы сервера местоположения не регламентированы документом RFC 2543, но там имеются примеры протоколов, которые могут использоваться для этого LDAP (RFC 1777), rwnois (RFC 2167) и др. Упрощенно базу данных можно представить как совокупность адресных записей, в которых напротив “публикуемого” адреса пользователя его стоит текущий адрес. Приняв запрос, сервер SIP обращается к серверу местоположения, чтобы узнать адрес, по которому можно найти пользователя. В ответ тот сообщает либо список возможных адресов, либо информирует о невозможности найти их. С другой стороны, пользователь информирует SIP-сервер о своем местоположении сообщением REGISTER. Сервер местоположения может располагаться как совместно с SIP-сервером, где могут присутствовать некоторые элементы базы адресов, так и отдельно от него. 

3.2 Адресация Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей протокол SIP использует адрес, подобный адресу электронной почты. В качестве адресов рабочих станций используются специальные универсальные указатели ресурсов - так называемые SIP URL (Universal Resource Locators).

SIP-адреса бывают четырех типов:

          имя@домен;           имя@хост;              имя@IР-адрес;

    №телефона@шлюз.

Таким образом, адрес состоит из двух частей. Первая часть - это имя пользователя, зарегистрированного в домене или на рабочей станции. Если вторая часть адреса идентифицирует какой-либо шлюз, то в первой указывается телефонный номер абонента.

Во второй части адреса указывается имя домена, рабочей станции или шлюза. Для определения IP-адреса устройства необходимо обратиться к службе доменных имен  Domain Name Service (DNS). Если же во второй части SIP-адреса размещается IP-адрес, то с рабочей станцией можно связаться напрямую.

В начале SIP-адреса ставится слово "sip:", указывающее, что это именно SIP-адрес.

Примеры SIP-адресов:

sip: [e-mail] sip: user1@192.168.100.152

sip: [e-mail]

3.3 Сигнализация на основе протокола SIP

В протоколе SIP определены два вида сигнальных сообщений - запрос и ответ. Они имеют текстовый формат (кодировка символов согласно RFC 2279) и базируются на протоколе HTTP (синтаксис и семантика определены в RFC 2068). 

Структура сообщений протокола SIP

Сообщения протокола SIP (запросы и ответы), представляют собой последовательности текстовых строк, закодированных в соответствии с документом RFC 2279. Структура и синтаксис сообщений SIP идентичны используемым в протоколе HTTP. Структура сообщений протокола SIP:

Стартовая строка

Заголовки

Пустая строка

Тело сообщения

•               Стартовая строка — начальная строка любого SIP-сообщения. Если сообщение является запросом, в ней указывается тип запроса, адресат и номер версии протокола. Если сообщение является ответом на запрос, в ней указывается номер версии протокола, тип ответа и его короткая расшифровка.

•               Заголовки сообщений содержат информацию, необходимую для обработки

сообщения (информация об отправителе, адресате, пути следования и пр.)

•               Тело сообщения содержит описание сеансов связи. Не все запросы содержат тело сообщения (например запрос BYE). Все ответы могут содержать тело сообщения, но содержимое тела в них бывает разным.

Заголовок  содержит  имя,  за  которым  после  двоеточия (:)  следует    поле, содержащее данные заголовка. Примеры и смысл наиболее часто встречаемых заголовков:

•               Call-ID – уникальный идентификатор отдельного сеанса связи или регистрации отдельного клиента; он подобен метке соединения (call reference) в DSS-1. Назначается стороной, которая инициирует вызов. Содержит буквенно-числовое значение и имя хоста, разделенные символом @: [e-mail] –  определяет  получателя  запроса;

• From – определяет отправителя запроса; по организации аналогичен полю То.

• CSeq – уникальный идентификатор запроса внутри одного Call-ID, он необходим для того, чтобы отличить, на какой запрос прошел ответ, так как в некоторых случаях он может оказаться ответом на другой запрос; состоит из двух частей: натурального числа в диапазоне от 1 до 2³² и названия типа запроса.

• Via –запрос может проходить через несколько прокси-серверов, каждый из которых принимает, обрабатывает и направляет его на следующий прокси-сервер, пока сообщение не достигнет конечного UAS. Поле Via показывает путь, пройденный запросом; каждый прокси-сервер добавляет это поле со своим адресом. Это необходимо для обнаружения колец, т.е. когда сообщение ходит в сети по кругу и не передается дальше, а также в случаях, когда необходимо, чтобы запросы и ответы обязательно проходили по одному и тому же пути (например, в случае использования firewall).

• Content-Type – определяет формат описания сеанса связи. Само описание сеанса, например, в формате протокола SDP включается в тело сообщения.

• Content-Length – показывает размер тела сообщения.

Запросы

 С помощью запросов клиент сообщает о текущем местоположении, приглашает пользователей принять участие в сеансах связи, модифицирует уже установленные сеансы, завершает их и т. д. Тип запроса указывается в стартовой строке.

1.                  INVITE (Приглашение) приглашает пользователя принять участие в сеансе связи, с этого запроса всегда начинается очередной сеанс. 

2.                  ACK (Подтверждение) — Подтверждает приём ответа на запрос INVITE.

3.                  BYE (Завершение) — Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе.

4.                  CANCEL (Сброс) — Отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.

5.                  REGISTER (Регистрация) — Переносит адресную информацию для регистрации пользователя на сервере определения местоположения.

6.                  OPTIONS (Возможности) — Запрашивает информацию о функциональных возможностях сервера.

Но в процессе развития, в протокол было добавлено ещё несколько типов запросов, которые дополнили его функциональность:

1.                  PRACK — временное подтверждение (RFC 3262)

2.                  SUBSCRIBE — подписка на получение уведомлений о событии (RFC 3265)

3.                  NOTIFY — уведомление подписчика о событии (RFC 3265)

4.                  PUBLISH — публикация события на сервере (RFC 3903)

5.                  INFO — передача информации, которая не изменяет состояние сессии (RFC 2976)

6.                  REFER — запрос получателя о передаче запроса SIP (RFC 3515)

7.                  MESSAGE — передача мгновенных сообщений средствами SIP (RFC 3428)

8.                  UPDATE — модификация состояния сессии без изменения состояния диалога (RFC 3311)

Оба протокола (SAP и SIP) используют механизм SDP (Session Description Protocol) для описания характеристик сеанса: время проведения, требуемые ресурсы и т.д. (Рекомендация RFC 2327). Протокол SDP используется исключительно для текстового описания сеанса и не имеет ни транспортных механизмов, ни средств согласования требуемых для сеанса параметров. Эти функции должны выполнять протоколы, применяемые для передачи информации SDP. 

Ответы на запросы

Ответы на запросы сообщают о результате обработки запроса либо передают запрошенную информацию. Структуру ответов и их виды протокол SIP унаследовал от протокола HTTP. Определено шесть типов ответов, несущих разную функциональную нагрузку. Тип ответа кодируется трёхзначным числом, самой важной является первая цифра, которая определяет класс ответа:

1.           1ХХ — Информационные ответы; показывают, что запрос находится в стадии обработки. Наиболее распространённые ответы данного типа — 100 Trying, 180 Ringing, 183 Session Progress – сессия обслуживается.

2.           2ХХ — (успех) - Финальные ответы, означающие, что запрос был успешно обработан. В настоящее время в данном типе определены только два ответа — 200 OK и 202 Accepted (прим. 202 кода нет в RFC 3261).

3.           3ХХ — (переадресация) - Финальные ответы, информирующие оборудование вызывающего пользователя о новом местоположении вызываемого пользователя, например, ответ 302 Moved Temporary – Временно перемещен.

4.           4ХХ — ( ошибка клиента) - Финальные ответы, информирующие об отклонении или ошибке при обработке или выполнении запроса, например, 403 Forbidden или классический для протокола HTTP ответ 404 Not Found. Другие примеры: 406 Not Acceptable — неприемлемый (по содержанию) запрос, 486 Busy Here — абонент занят или 487 Request Terminated — вызывающий пользователь разорвал соединение не дожидаясь ответа (отмена запроса).

5.           5ХХ — (ошибка сервера) – Финальные ответы, информирующие о том, что запрос не может быть обработан из-за отказа сервера, 500 Server Internal Error.

6.           6ХХ — (глобальный сбой) - Финальные ответы, информирующие о том, что соединение с вызываемым пользователем установить невозможно, например, ответ 603 Decline означает, что вызываемый пользователь отклонил входящий вызов.

Процесс регистрации пользователя в сети IP- телефонии по протоколу SIP представлен на рис.9.

 

Рис.9 Процесс регистрации пользователя в сети IP- телефонии по протоколу SIP

На рис.10 приведены примеры запроса и ответа и схема построения соединения агентов через сервера в сети SIP.

Пример запроса INVITE:

INVITE sip: [e-mail] SIP/2.0

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell <sip: [e-mail]>

To: T. Watson <sip: [e-mail]>

Call-ID: [e-mail]

Cseq: 1 INVITE

Content-Type: application/sdp Content-Length: ...

v=0

o=bell 53655765 2353687637 IN IP4 128.3.4.5 SIP=IN IP4 kton.bell-tel.com

m=audio 3456 RTP/AVP 0 3 4 5

Этот запрос приглашает [e-mail] для участия в сеансе связи с [e-mail]. В теле  сообщения отправитель указывает, что он может принимать на порт 3456 аудиоинформацию, кодированную 0 (PCMU), 3 (GSM), 4 (G.723) и 5 (DV14). Запрос направляется  на прокси - сервер boston.bell-tel.com. В полях То и From перед скобками с адресом (<>) помещена  надпись, которую пользователь желает вывести  на дисплей вызываемого  пользователя.

Пример SIP-ответов 

SIP/2.0 200 OK

Via: SIP/2.0/UDP kton.bell-tel.com

From: A. Bell <sip:[e-mail]>

To: <sip:[e-mail]>;

Call-ID: [e-mail]

Cseq: 1 INVITE

Content-Type: application/sdp Content-Length: ...

v=0

o=watson 4858949 4858949 IN IP4 192.1.2.3

t=3149329600 0

SIP=IN IP4 boston.bell-tel.com m=audio 5004 RTP/AVP 0 3 a=rtpmap:0 PCMU/8000

a=rtpmap:3 GSM/8000

В ответе пользователя Watson на запрос Bell сообщается, что он может принимать аудиоинформацию на порт 5004, понимает кодеки PCMU, GSM. Поля From, To, Via, Call-ID взяты из запроса. Поле Cseq показывает, что это – ответ на INVITE с Cseq: 1.

Алгоритм установления соединения непосредственно между клиентами SIP представлен на рис.10

 

Рис.10 Алгоритм установления соединения непосредственно между клиентами SIP

Алгоритм установления соединения  с использованием серверов определения местоположения и переадресации представлен на рис.11.

 

Рис.11 Алгоритм установления соединения через сервер переадресации

Вопросы для самопроверки

1.  Зачем нужен протокол SIP?

2.  Основные принципы, положенные в основу протокола SIP, кто его стандартизировал?

3.  Какое место занимает протокол SIP в стеке протоколов TCP/IP.

4.  С помощью какого протокола терминалы обмениваются информацией о своих функциональных возможностях?

5.  Перечислить основные элементы SIP-сети.

6.  Элементы SIP-сети. Их функции.

7.  Агент пользователя. Из каких элементов он состоит. 8. Прокси-сервер. Типы прокси-серверов, их функции 9. Сервер переадресации. Функции.

10.  Сервер определения местоположения. Функции.

11.  Показать пример SIP-сети. Описать на нем в общем виде процесс установления соединения между терминалами

12.  Какой тип адресации используется в протоколе SIP.

13.  Перечислить типы SIP-адресов, что значат их элементы?

14.  Описать принцип «клиент-сервер».

15.  Сообщения протокола SIP. Какой формат сообщений и их структура?

16.  Какие существуют виды сообщений?

17.  Назначение запросов протокола SIP.

18.  Назначение ответов протокола SIP.

19.  Пояснить назначение основных заголовков сообщений.

20.  Описать процесс установления соединения с участием сервера

переадресации

21.  Описать процесс установления соединения с участием прокси-сервера

22.  В чем разница двух сценариев?

23.  В какие моменты времени терминалы пользователей посылают информацию о своих функциональных возможностях? В каких сообщениях эта информация располагается?

24.  Какое минимальное число сообщений необходимо для установления соединения?

4. Протокол управления шлюзами MGCP

Протокол управления транспортными шлюзами MGCP (Media Gateway Controller Protocol)  представляет собой достаточно простой протокол клиент-сервер. Логика управления вызовами выполняется агентом (Call Agent, CA)), и полностью отделена от медиа-потоков. Эти потоки обрабатываются шлюзами или абонентскими терминалами, которые способны исполнять лишь ограниченный набор команд, исходящих от управляющего устройства. В архитектуре протокола MGCP-сети можно выделить два основных функциональных компонента. Первый может быть представлен транспортным шлюзом (Media Gateway, MG) или IP-телефоном, а второй - устройством управления вызовами, которое может называться контроллером сигнализаций (CA), контроллером шлюза (Media Gateway Controller, MGC) или программным контроллером (Softswitch, SS).

Иногда контроллер сигнализаций представляют в виде двух компонентов - собственно контроллера (Call Agent), выполняющего функции управления шлюзами, и шлюза сигнализации (Signaling Gateway), обеспечивающего обмен сигнальной информацией и согласование между традиционной телефонной сетью и сетью IP.

При разработке протокола управления шлюзами рабочая группа MEGACO опиралась на принцип декомпозиции, согласно которому шлюз разбивается на отдельные функциональные блоки (рис. 12):

•       транспортный шлюз - Media Gateway, который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP: кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование;

•       устройство управления вызовами - Call Agent, выполняющее функции управления шлюзом;

•       шлюз сигнализации - Signaling Gateway, который обеспечивает доставку сигнальной информации, поступающей со стороны ТфОП, к устройству управления шлюзом и перенос сигнальной информации в обратном направлении.

Дальнейшим развитием протокола MGCP является протокол управления вызовами Megaco (Media Gateway Control), известный также как стандарт ITU H.248. Протокол Megaco обеспечивает взаимодействие шлюза (Media Gateway, MG) и контроллера шлюза (Media Gateway Controller, MGC). Шлюзы обеспечивают согласование разных сред передачи данных, а контроллеры шлюзов - управление этими шлюзами (рис.13).

  

Рис. 12. Архитектура сети, базирующейся на протоколе MGCP

Иными словами, Megaco разработан для внутри-доменного удаленного управления устройствами, отвечающими за установление соединения или проведение сеанса связи: 

•       шлюзы VoIP; 

•       серверы удаленного доступа; 

•       мультиплексоры цифровых абонентских линий (Digital Subscriber Line Access Multiplexer, DSLAM); 

•       маршрутизаторы, поддерживающие технологию многопротокольной коммутации меток (Multiprotocol Label Switching, MPLS); 

•       оптические кросс-коннекторы; 

•       модули агрегирования сеансов РРР (Point-to-Point Protocol) и другие. 

 

Рис. 13 - Использование протокола Megaco в сети IP-телефонии

MGCP и Megaco являются низкоуровневыми протоколами управления устройствами, которые сообщают шлюзу, каким образом связать потоки, поступающие в сеть с коммутацией пакетов или ячеек, с потоками пакетов или ячеек, переносимыми, например, транспортным протоколом реального времени (Real-Time Transport Protocol, RTP). По существу, Megaco повторяет MGCP в отношении архитектуры и взаимодействия контроллера со шлюзом, но при этом Megaco поддерживает более широкий диапазон сетевых технологий, в том числе ATM. 

Контроллеры обмениваются со шлюзами (или IP-телефонами) аудиоданными в простом текстовом формате, а функциональное назначение каждого шлюза определяется набором команд, которые он "понимает". Манипулируя наборами команд, можно получать специализированные шлюзы: транковые (Trunking gateways, TGW), абонентские (Residential gateways, RGW), шлюзы доступа (Access gateways, AGW) и др.

Контроллер сигнализаций CA воспринимает сеть как набор двух логических элементов - устройств (endpoints ) и соединений (connections ) между ними. Устройства могут быть физическими (например, IP-телефоны или линии на шлюзах) или виртуальными (например, линии к серверам голосовых сообщений). Соединения могут быть ориентированы на передачу голоса, факс-сообщений или данных. Управление этими элементами, т. е. организация соединений между устройствами, происходит путем посылки команд в виде текстовых ( ASCII ) сообщений по протоколу UDP - при этом может использоваться протокол SDP.

Простейший сценарий соединения будет выглядеть следующим образом:  пользователь  телефона, подключенного к MGCP-шлюзу, снимает трубку, после чего шлюз сообщает контроллеру об этом событии, а СА дает команду шлюзу включить в телефонную линию сигнал готовности (dial-ton ). Теперь пользователь слышит в трубке непрерывный гудок. Далее следует набор телефонного номера - тоже последовательность событий для контроллера. Анализируя эти события, СА может установить соединение с другим абонентом в IP-сети или в телефонной сети.

Для многих приложений не имеет значения, какой из протоколов, MGCP или Megaco, будет использоваться. Однако Megaco лучше интегрирован с приложениями, требующими поддержки нескольких сред передачи, чем MGCP, потому что в базовый протокол включены семантические элементы для конференций. Благодаря этому MGCP может быть лучшей основой для приложений, не привязанных к какой-либо среде, например для управления сеансами на базе MPLS. С развитием мультимедийных услуг в протоколе MGCP выявился ряд функциональных недостатков этого протокола и несовершенство модели установления соединения, поэтому будущее развитие технологии управления распределенным шлюзом связывается с более совершенным протоколом MEGACO/H.248.

4.1. Классификация шлюзов по области применения

Применяется следующая классификация транспортных шлюзов (Media Gateways):  Trunking Gateway - шлюз между ТфОП и сетью с маршрутизацией пакетов IP, ориентированный на подключение к телефонной сети;

•       Voice over ATM Gateway - шлюз между ТфОП и АТМ-сетью, который также подключается к телефонной сети посредством большого количества цифровых трактов;

•       Residential Gateway - шлюз, подключающий к IP-сети аналоговые, кабельные модемы, линии xDSL и широкополосные устройства беспроводного доступа;

•       Access Gateway - шлюз для подключения к сети IP-телефонии небольшой учрежденческой АТС через аналоговый или цифровой интерфейс;

•       Business Gateway - шлюз с цифровым интерфейсом для подключения к сети с маршрутизацией IP-пакетов учрежденческой АТС;

•       Network Access Server - сервер доступа к IP-сети для передачи данных;

•       Circuit switch или packet switch - коммутационные устройства с интерфейсом для управления от внешнего устройства.

4.2 Модель процесса обслуживания вызова MEGACO/H.248

При описании алгоритма установления соединения с использованием протокола MEGACO комитет IETF опирается на специальную модель процесса обслуживания вызова (рис. 14), отличную от модели MGCP. Протокол MEGACO оперирует с двумя логическими сущностями внутри транспортного шлюза: окончание (termination) и контекст (context), которыми может управлять контроллер шлюза.

 

Рис. 14. Примеры модели процесса обслуживания вызова

Окончания (порты) являются источниками и приемниками медиаинформации. Они являются логическими объектами медиашлюза. Можно выделить два вида окончаний в зависимости от того, какой интерфейс они представляют – физический или виртуальный. Физические окончания, существуют полупостоянно с момента конфигурации шлюза, это аналоговые телефонные интерфейсы оборудования, поддерживающие одно телефонное соединение, или цифровые каналы. 

Виртуальные окончания, существующие только в течение разговорной сессии, являются интерфейсами со стороны IP сети (например, RTP-окончания), через которые ведутся передача и прием пакетов. Виртуальные окончания создаются шлюзом при получении от контроллера команды Add и ликвидируются при получении команды Subtract, тогда как физические окончания при получении команды Add или Subtract, соответственно, выводятся из нулевого контекста или возвращаются обратно в нулевой контекст. Окончание имеет уникальный идентификатор (TerminationID), который назначается шлюзом при конфигурации порта. Идентификаторы физических окончаний формируются в MG, например, идентификатором порта может служить номер тракта E1 и номер временного канала внутри тракта. Иногда команды могут относиться ко всему шлюзу, тогда используется общий идентификатор окончаний (TerminationID) – «Root». Также используется механизм  групповых символов wildcard: ALL и CHOOSE.

Первый позволяет адресоваться сразу к нескольким окончаниям одновременно, а последний позволяет предоставить право выбора любого подходящего окончания шлюзу. Окончания обладают рядом  свойств (properties), каждое из которых имеет уникальный идентификатор (propertyID), например, окончания могут обладать способностью генерировать речевые подсказки, акустические и вызывные сигналы и подсказки, а также выявлять сигналы DTMF.

При создании окончаний некоторые свойства присваиваются им по умолчанию. При помощи протокола MEGACO контроллер может изменять свойства окончаний шлюза. Свойства окончаний группируются в дескрипторы, которые включаются в команды управления окончаниями.

Существует ряд общих свойств окончаний и ряд свойств, относящихся к медиапотокам. Общие свойства называются свойствами состояния окончания. Свойства, которые не могут быть описаны базовым протоколом, определяются в «пакетах» о которых будет сказано ниже.

Окончания, как уже говорилось, могут генерировать и выдавать сигналы, при этом говорят, что сигнал применен на окончании. Окончания могут быть запрограммированы на обнаружение событий, при возникновении которых MG должен будет отослать извещение контроллеру или выполнить определенные действия. На окончании может накапливаться статистика и потом выдаваться по запросу контроллера и при удалении окончания из контекста.

Контекст (Context)

Контекст – это отображение связи между несколькими окончаниями, т. е. абстрактное представление соединения двух или более портов (физических и/или виртуальных) одного шлюза. В любой момент времениокончание может относиться только к одному контексту, который имеет свой уникальный идентификатор. 

Существует особый вид контекста – нулевой. Все окончания, входящие в нулевой контекст, не связаны ни между собой, ни с другими портами. Например, абстрактным представлением свободного (незанятого) канала в модели соединений является окончание в нулевом контексте.

В общем случае для присоединения окончания к контексту служит команда Add. При этом, если контроллер не специфицирует существующий контекст, к которому должен быть доставлен порт, то шлюз создает новый контекст. Удаление окончания из контекста производится командой Subtract. Перемещение окончания из одного контекста в другой производится командой Move.

Максимальное  количество окончаний, включенных в контекст, ограничивается возможностями шлюза. Если  он поддерживает только соединения точка-точка, то их будет всего  два.

Атрибутами контекста являются:

•идентификатор  контекста – ContextID;

•топология  контекста (кто кому передает и от кого принимает информацию). Топология контекста описывает потоки информации внутри контекста, т. е. внутри  шлюза, в то  время как подобный параметр окончания – режим работы окончания,  описывает внешние потоки шлюза, входящие и исходящие;

•приоритет  используется, для того чтобы указать шлюзу на первоочередную важность обслуживания контекста. Система приоритетов включает 16 уровней, изменяющихся от низшего нулевого до наивысшего 15-го;

•индикатор  «аварийного вызова» позволяет получить высший приоритет в обслуживании. Протокол  имеет средства, чтобы управлять  параметрами контекста.

Удаление  контекста происходит автоматически после исключения из него последнего окончания.

4.3 Сообщения протокола H.248/MEGACO

Дескрипторы

Параметры команд H.248 сгруппированы в объекты, которые называются дескрипторами. Дескриптор  состоит из названия и списка элементов. Некоторые элементы могут иметь численные  значения. Многие команды содержат общие дескрипторы, т. е. конкретный дескриптор  может встречаться в нескольких разных командах. Общий  вид дескрипторов можно представить  следующим образом:

Название дескриптора = <Идентификатор ID> {параметр = значение, параметр = значение…}.

Не все  команды должны обязательно содержать те или иные дескрипторы, в ряде команд дескрипторы  лишь опциональны (табл. 1). Определенные в протоколе дескрипторы перечислены в табл.1.

Таблица. 1 Таблица дескрипторов

 

 

По умолчанию значения  всех дескрипторов, за исключением дескриптора состояния окончания и дескриптора местного управления, устанавливаются пустыми (т. е. без значений). Дескрипторы, как следует из названия – это некие «описатели», которые содержат значения параметров, присваиваемых окончаниям, контекстам или всему шлюзу.

Команды

Команды  протокола обеспечивают управление логическими единицами модели обслуживания вызова – контекстами  и окончаниями.

Команды позволяют управлять свойствами контекстов и окончаний. Большинство  команд могут передаваться только контроллером, за исключением команд Notify и ServiseChange. Приведем полный список используемых команд (табл.2).

Таблица. 2 Список используемых команд

 

Транзакции

Команды, передаваемые  между MGC и MG группируются в транзакции, каждая из которых снабжается  идентификатором TransactionID, необходимым для соотнесения запросов и ответов  транзакций. Транзакция состоит из одного или  более действий. Действие состоит из серии команд, указаний модифицировать или проверить (выдать) свойства контекста, причем область всех этих операций должен ограничиваться одним контекстом.

Сообщения

Несколько транзакций  протокола могут помещаться в его сообщение. Сообщение снабжается заголовком, определяющим отправителя. Идентификатор  сообщения (Message Identifier, MID) устанавливается равным назначенному имени (например,  доменному адресу/доменному  имени/имени устройства) объекта, передающего сообщение. По умолчанию предлагается использовать доменное имя. Сообщение H.248 – это, по сути, только транспортный механизм, в отличие от сообщений многих других сетевых протоколов, имеющих собственные функции (рис. 14).

 

Рис. 14. Структура  сообщений H.248/MEGACO

Пакеты (Packages)

Разные типы шлюзов могут иметь различные окончания, сильно разнящиеся по характеристикам. Для сглаживания таких различий протокол позволяет окончаниям иметь опциональные свойства, события, сигналы и статистику, реализуемые шлюзом. Для обеспечения возможности взаимодействия MG и MGC такие опции группируются в «пакеты» или Packages, и обычно окончание выполняет или реализует ряд таких  «пакетов». Контроллер может  запросить у шлюза статистику, чтобы знать, какие пакеты он может  выполнять.

Пакет – это отдельная рекомендация, в которой описываются свойства, события, сигналы и статистика и все процедуры, с ними связанные. Например, если описывается  событие, такое как обнаружение неисправности соединения, в пакете перечисляются действия, которые шлюз должен выполнить при его обнаружении.

Для того, чтобы  поддерживать конкретный пакет, MG должен поддерживать все свойства, сигналы, события  и статистику, определенную в нем.

4.4 Процедура установления и разрушения соединения

Установление и разрушение соединения в MEGACO/H.248, как и в большинстве сетевых протоколов, варьируется в зависимости от ситуации на сети и участвующих сторон. Одним из базовых вызовов является сценарий установления соединения между двумя резидентными шлюзами (Рис.15).

Резидентные шлюзы – это такие шлюзы, в которые включаются 1–2 абонентские линии, т. е. они отвечают за сопряжение 1–2 абонентских терминалов с сетью IP-телефонии. Наибольшее распространение такой сценарий нашел в корпоративном секторе.

Другим типом  шлюза является транспортный шлюз – шлюз, который соединяет сети ТфОП и IP, т. е. в него включаются не абоненты, а СЛ к телефонным станциям.

 

Рис 14. Алгоритм установления и разрушения соединения с помощью протокола MEGACO

В нашем  случае через сеть IP-телефонии взаимодействуют два аналоговых терминала, включенных в резидентные шлюзы.

1.        Шлюз MG1 регистрируется  у контроллера MGC при помощи команды ServiceChange.

2.        Контроллер     подтверждает            регистрацию шлюза,            высылая         ответ   на команду

ServiceChange.

3.        Шлюз имеет свободные аналоговые порты, которые должны быть запрограммированы для отслеживания изменения сопротивления абонентского шлейфа, означающего поднятие абонентом трубки, после чего шлюз должен передать абоненту акустический сигнал «Ответ станции». Программирование производится при помощи команды Modify с

соответствующими параметрами (указанными в дескрипторах), причем программируется порт, находящийся в нулевом контексте. В команде указывается режим функционирования порта –дуплексный (SendReceive).

4.        Шлюз MG1 подтверждает выполнение команды Modify.

5.        Подобным же образом (шаги 1–4) программируется аналоговый порт шлюза MG2.

6.        Далее  шлюз MG1 обнаруживает, что абонент A поднял трубку, и извещает об этом событии Media Gateway Controller при помощи команды Notify.

7.        Контроллер  подтверждает получение команды Notify.

8.        На следующем  шаге MGC, командой Modify дает шлюзу инструкцию накапливать цифры номера вызываемого абонента. Кроме того, после получения первой цифры номера необходимо остановить передачу акустического сигнала «Ответ станции».

9.        Шлюз подтверждает получение команды Modify.

10.    Цифры  номера вызываемого абонента собираются шлюзом MG1, после чего передаются к контроллеру в  команде Notify. 11. Полученное  сообщение подтверждается шлюзом.

12.  Далее  контроллер MGC анализирует цифры номера вызываемого абонента, полученные от шлюза MG1, и определяет,  что соединение должно проходить через шлюз MG2, к которому подключен вызываемый абонент. К вновь  образованному контексту в шлюзе MG1 добавляются при помощи команды Add физический порт (аналоговый абонентский интерфейс) и виртуальный порт (RTP-порт). В этот  момент шлюз, к кото- рому прикреплен  вызывающий абонент, не имеет информации о шлюзе MG2 (такой как IP-адрес, RTP-порт и поддерживаемые  алгоритмы декодирования принимаемой речевой информации), поэтому  контроллер MGC предписывает шлюзу MG1 только принимать информацию (режим ReceiveOnly). Кроме того, контролер MGC специфицирует в команде Add предпочтительные для использования алгоритмы  кодирования.

13.  Шлюз MG1 создает новый виртуальный порт (RTP-порт) и указывает его транспортный адрес. Кроме  того, шлюз выбирает алгоритмы кодирования информации, которые будут использоваться в соединении, основываясь на предпочтениях контроллера.

14.  Контроллер  MGC посылает  команду Add и создает в шлюзе MG2 контекст для установления  дуплексного соединения (режим.SendReceive) с вызывающим пользователем.

15.  Создание контекста подтверждается, физический  порт шлюза MG2 соединяется с указанным  UDP/RTP портом. Отметим, что RTP-порт имеет номер отличный от номера порта Megaco/H.248, по которому производится сигнальный обмен.

16.  Контроллер,  командой Modify предписывает шлюзу MG1 начать передачу вызывающему абоненту  акустического сигнала «Контроль посылки вызова (КПВ)».

17.  Шлюз MG1 подтверждает передачу указанного акустического сигнала в физический порт.

18.  Контроллер MGC предписывает физическому порту шлюза MG2 начать передачу вызывного сигнала.

19.  Шлюз MG2 подтверждает передачу сигнала «Посылка вызова» вызываемому абоненту.

20.  На этом  этапе обоим абонентам, участвующим в соединении, посылаются соответствующие сигналы, и шлюз MG2 ждет, пока вызываемый абонент примет входящий вызов, после чего между двумя шлюзами будут организованы двунаправленные разговорные  каналы.

21.  Шлюз MG2 обнаружил,  что вызываемый абонент поднял трубку, и извещает об этом контроллер MGC командой Notify.

22.  Контроллер  подтверждает получение команды Notify.

23.  Далее контроллер MGC командой Modify предписывает шлюзу MG2 прекратить передачу вызывного сигнала.

24.  Шлюз MG2 подтверждает  выполнение команды.

25.  Далее, контроллер  командой Modify разрешает шлюзу MG1 не только принимать, но и передавать  информацию (режим SendReceive), и останавливает передачу вызывающему абоненту акустического сигнала «КПВ».

26.  Шлюз MG1 подтверждает  выполнение команды.

27.  После этого начинается разговорная  фаза соединения, в течение которой участники обмениваются речевой информацией. Следующим шагом контроллер MGC может проверить RTP-порт в  шлюзе MG2, отправив команду AuditValue.

28.  Шлюз MG2 выполняет  команду. В ответе на команду AuditValue передается вся запрашиваемая  информация, в том числе статистика, собранная за время соединения.

29.  Вызываемый абонент  первым завершает соединение, и шлюз MG2 извещает об этом контроллер MGC командой  Notify.

30.  Контроллер MGC подтверждает  получение сообщения Notify.

31.  Получив  информацию от любого из шлюзов о том,  что один из абонентов положил трубку, контроллер MGC завершает  соединение. К обоим шлюзам передается команда

Subtract.

32.  В ответе  на команду Subtract каждый  из портов, участвующих в соединении на шлюзах MG1 и MG2, возвращает  статистику, собранную за время соединения. В общем случае, контроллер  может запрашивать статистическую информацию только у одного  из портов.

Контрольные вопросы

1.      Функция  протоколов MGCP и MEGACO

2.      Кто  разработал протокол MEGACO?

3.      Функциональные  элементы распределенного шлюза.

4.      Показать пример  сети на базе архитектуры распределенного шлюза.

5.      Почему решили  разработать MEGACO взамен MGCP?

6.      Какими  логическими объектами оперирует модель установления соединения

MEGACO?

7.      Какими  атрибутами обладает контекст?

8.      Что такое  дескрипторы? Их назначение.

9.      Что описывает  дескриптор LocalControl?

10.  Назначение  команды Add.

11.  Структура сообщений MEGACO

12.  Что такое  «пакеты» MEGACO?

5. ОБЕСПЕЧЕНИЕ КАЧЕСТВА IP-ТЕЛЕФОНИИ

5.1 Показатели качества IP-телефонии

Трафик в сети формируется множеством потоков данных, генерируемых приложениями пользователей. Приложения предъявляют различные требования к рабочим характеристикам сети. Структура существующих в сети запросов на доставку данных определяется типами сетевых приложений. Каждому типу приложения приписывают соответствующий уровень обслуживания (Grade of Service, GoS). Каждому уровню обслуживания соответствует: полоса пропускания канала, задержка/джиттер и доля потерянных пакетов. Способность сети обеспечивать различные уровни обслуживания может быть классифицирована по трем критериям: 

            негарантированная доставка данных (best-effort service);     дифференцированное обслуживание (differentiated service);     гарантированное обслуживание (guaranteed service). 

Негарантированная доставка данных не может рассматриваться как некая ответственность сети за качество обслуживания. Негарантированная доставка пакетов является в наше время единственной услугой, поддерживаемой в Internet. Для большинства современных приложений, ориентированных на передачу файлов по протоколу FTP (File Transfer Protocol), качество доставки вполне удовлетворяет требованиям пользователей. Для оптимального обслуживания всех запросов от приложений, представленных в сети, требуется выделение определенных сетевых ресурсов (полосы пропускания каналов, задержки, доли потерянных пакетов). 

Дифференцированное обслуживание предполагает разделение сетевого трафика на классы на основе требований к качеству обслуживания. Средства распределения ресурсов сети должны отличать классы обслуживания (Class of Service, CoS) друг от друга и обслуживать в соответствии с требованиями приложений. Необходимо подчеркнуть, что, в отличие от положений Рекомендации ITU-T E.800, дифференцированное обслуживание само по себе не предполагает обеспечения гарантий предоставления услуг доставки информации. Каждому классу трафика средства обработки в сети приписывают приоритет. При существующей загрузке сети приоритет доставки определяется классом. Дифференцированное обслуживание часто называют мягким качеством обслуживания (soft Quality of Service, soft QoS). Дифференцированное обслуживание применяют в сетях, где трафик приложений высок и требует оперативного контроля и распределения. Решение этой задачи возможно в том случае, если трафику административного управления будет назначен самый высокий приоритет. Оставшиеся классы приоритета назначаются пользовательскому трафику. Такая классификация трафика позволяет администратору в любой момент быть уверенным в связности узлов сети. 

Гарантированное обслуживание предполагает предварительное резервирование сетевых ресурсов для всех видов трафика. Гарантированное обслуживание часто называют жестким качеством обслуживания (hard Quality of Service, hard QoS), особенность которого состоит в жесткости требований к ресурсам сети, выделяемым для трафика на всем пути его доставки к получателю. К сожалению, в сетях с протоколом IP обеспечить такую гарантию пока не представляется возможным. Это, в частности, характерно для магистрали Internet. Приближением к идеологии гарантированного обслуживания является агрегированное (объединенное, укрупненное) резервирование ресурсов, которое требует хранения в базовых маршрутизаторах Internet небольшого объема информации о резервируемых ресурсах. 

Немалая доля современных приложений характеризуется высокими требованиями к задержке доставки данных получателю. Большинству интерактивных приложений (речевой обмен, мультимедиа) можно удовлетворить при задержке, не превышающей 100 мс. Решение задачи, связанной с ответственностью за качество доставки информации в IPсети, обеспечивается благодаря использованию байта типа обслуживания (Type of Service, ToS) в заголовке IP-пакета. Байт ToS используется для указания абстрактных параметров требуемого качества обслуживания. На основании этих параметров производится выбор реальных характеристик механизмов обслуживания при передаче дейтаграммы через сеть (RFC 791: Internet Protocol Specification/Postel J., 1981). До конца 80-х годов протокол IP игнорировал поле ToS. Лавинообразный рост трафика и увеличение количества сетевых приложений Internet в 90-е годы привели к необходимости поддержки байта ToS. В наше время целью рабочей группы IETF является обеспечение приложений средствами формулирования требований к ресурсам сети при сквозном обслуживании (генерирование содержимого байта ToS) и разработка соответствующих механизмов обеспечения качества доставки маршрутизаторами. С помощью байта ToS реализуется так называемое дифференцированное обслуживание (DiffServ) в масштабах Internet. 

IP-телефония является одной из технологий передачи данных, где важна минимизация задержки информации при передаче от источника до получателя. Решение этой задача обеспечивается современными методами кодирования и передачи информации, а также увеличением пропускной способности каналов. Использование пакетной передачи речевой информации и подавление пауз в разговоре позволяют экономно использовать сетевые ресурсы и относительно успешно конкурировать IP телефонии с традиционными телефонными сетями. 

Для оценки качества услуги пользователем оператор (провайдер услуг) должен проводить систематический опрос его мнения. В рекомендации ITU-T E.432 предложено оценку результатов опроса производить по усредненному мнению (Mean Opinion Score, MOS). Сущность метода состоит в том, что результаты опроса пользователей или экспертов разделяют на 4 уровня: отличный, хороший, средний и недостаточный (таблица

3). 

Таблица 3 – Показатели качества доставки речевой информации службой с коммутацией пакетов
Показатель	Уровни качества услуги
	Отличный (Excellent)	Хороший (Good)	Средний (Fain)	Недостаточный (Poor)
Время установления соединения, с.	0-1	1-3	3-5	Более 5
Время доставки пакета, мс	0-150	150-250	250-450	Более 450

Показатели качества обслуживания и нормативы для них в сетях с протоколом IP пока еще не установлены. В таблице 4 приведены предварительные показатели качества услуг доставки в сетях с IP. 

Таблица 4 - Предварительные показатели качества услуг доставки в сетях с технологией IP
Характеристики службы	Показатели качества службы
	Быстрота (скорость)	Безошибочность	Надежность
Доступность	Задержка доступа	Вероятность неправильного доступа	Вероятность отказа в доступе
Доставка сообщений	А) Средняя задержка	А) вероятность ошибок в	Коэффициент потери пакета
пользователя	доставки пакета IP; Б) джиттер задержки пакета IP	пакетах IP; Б) вероятность ложных пакетов IP	IP
Освобождение	Задержка освобождения	Вероятность неправильного освобождения	Вероятность отказа в освобождении
Критерии отказа службы: коэффициент готовности Кг , среднее время между отказами.

Качество услуг IP-телефонии может быть соотнесено с одним из четырех классов:     отличное (Excellent), когда полученное качество сравнимо с качеством услуги PSTN; 

•       хорошее (Good), к которому относится услуга с потенциальной возможностью предоставления качества, сравнимого с качеством услуги PSTN, но при наличии задержек может достигаться путем оптимизации использования полосы пропускания; 

•       среднее (Fain), сравнимое с качеством услуг беспроводной связи, например, в сетях подвижной связи стандарта GSM, и может быть реализовано в IP-сетях, не подверженных перегрузкам; 

•       недостаточное (Poor), при котором обеспечивается “приемлемое” взаимодействие пользователей, но со значительно ухудшенным качеством речи при отсутствии верхней границы на сквозные задержки, обеспечивается через глобальную часть

Internet. 

При разделении качества услуг IP-телефонии на классы учитывается пять показателей (таблица 5): 

            сквозное качество голоса в одном направлении;       сквозная задержка; 

•       время установления соединения;      коэффициент потерь пакетов IP;          джиттер (jitter) задержки. 

Таблица 5 – Классы качества услуг IP-телефонии
Класс качества услуги передачи речи		Excellent	Good	Fain	Poor
Качество голоса в одном направлении		Не хуже, чем по	Не хуже,	Не хуже,	-
		G.711	чем по G.726 для V=32 Кбит/с	чем GSM- FR
Сквозная задержка		< 150мс	< 250мс	< 450мс	> 450мс
Время установления соединения	При прямой IPадресации	< 1.5 сек	< 4 сек	< 7 сек
	Перевод номера абонента с форматом, соответствующим Е.164, в IP-адрес	< 2 с	< 5 с	< 10 с
	Перевод номера абонента с форматом, соответствующим Е.164, в IP-адрес через расчетную организацию	< 3 с	< 6 с	< 15 с
	Перевод имени email в IP-адрес	< 4 с	< 13 с	< 25 с
Коэффициент потерь пакетов IP		0 %	3 %	15 %	25 %
Пиковое дрожание фазы (джиттер)		0 мс	75 мс	125 мс	225 мс

На рисунке 15 приведены факторы, влияющие на качество IP-телефонии. 

Качество речи включает:  

•       диалог – возможность пользователя связываться и разговаривать с другим пользователем в реальном времени и полнодуплексном режиме; 

•       разборчивость – чистота и тональность речи; 

•       эхо – слышимость собственной речи; 

•       уровень – громкость речи. 

 

Рис.15- Факторы, влияющие на качество IP-телефонии 

Качество сигнализации включает:  

•       установление вызова (доступ к службе) – скорость успешного доступа и время установления соединения; 

•       завершение вызова – скорость разъединения; 

•       DTMF – определение и фиксация сигналов многочастотного набора номера. 

Факторы, которые влияют на качество IP-телефонии, могут быть разделены на две категории: 

1.Факторы, влияющие на качество IP-сети:   максимальная пропускная способность - максимальный объем пользовательских и служебных данных, которые она способна передать; 

•       задержка – промежуток времени, требуемый для передачи пакета через сеть; 

•       джиттер – изменение задержки пакетов потока в течение сеанса связи; 

•       потеря пакетов – доля пакетов, потерянных во время сеанса связи при передаче через сеть. 

2.Факторы, влияющие на качество шлюза:  

•       требуемая полоса пропускания – различные вокодеры требуют различную полосу. Например, вокодер G.723 требует полосы 16,3 Кбит/с для каждого речевого канала; 

•       задержка – время, необходимое цифровому сигнальному процессору DSP или другим устройствам обработки для кодирования и декодирования речевого сигнала; 

•       буфер джиттера – сохранение поступающих пакетов с пользовательскими данными до тех пор, пока все пакеты не будут получены и можно будет передать данные в требуемой последовательности для минимизации джиттера; 

•       потеря пакетов – доля пакетов, потерянных при сжатии и/или передаче в оборудовании IP- телефонии; 

•       подавление эхо – механизм для подавления эхо, возникающего при передаче по сети; 

•       управление уровнем – возможность регулирования громкости речи. 

Показатели качества речевого взаимодействия “из конца в конец” зависят и от характеристик терминального оборудования. Определено три типа терминалов: 

•       тип А, который соответствует классам качества услуг “Excellent” и “Good” и характеризуется широкой полосой пропускания (выше, чем 64 Кбит/с); 

•       тип В, который соответствует классам качества услуг “Good” и “Fain” и характеризуется средней полосой пропускания (64 Кбит/с) как, например, в NISDN; 

•       тип С, который соответствует классам качества услуг “Fain” и “Poor” и характеризуется малой полосой пропускания (меньше 25 Кбит/с) как, например, в случае модемной связи. 

5.2 Обслуживание очередей

Алгоритмы обслуживания очередей позволяют предоставлять разный уровень QoS трафику разных классов. Обычно используется несколько очередей, каждая из которых занимается пакетами с определенным приоритетом. Требуется, чтобы высокоприоритетный трафик обрабатывался с минимальной задержкой, но при этом не занимал всю полосу пропускания, и чтобы трафик каждого из остальных типов обрабатывался в соответствии с его приоритетом.

Обслуживание очередей включает в себя алгоритмы:

          организации очереди;              обработки очередей.

1. Алгоритмы организации очереди

Существует два основных алгоритма организации очереди: Tail Drop и Random Early Detection.

Алгоритм Tail Drop

Tail drops - отсечения конца очереди. Задается максимальный размер очереди (в пакетах или в байтах). Когда очередь полна, ни один вновь поступивший пакет туда уже не помещается и потому отбрасывается. Такое управление очередью приводит к повторной синхронизации параметров соединения. После синхронизации TCP сразу посылает столько пакетов, сколько допускает размер окна подтверждения. Подобный всплеск нагрузки опять приводит к отсечению конца очереди, что опять порождает необходимость повторной синхронизации.

Чтобы избежать возникновения заторов, на маршрутизаторах зачастую организуются очереди большого размера. К сожалению, несмотря на то что увеличение размеров очереди благоприятно сказывается на пропускной способности, большие очереди могут приводить к увеличению времени задержки, что становится причиной нестабильного поведения TCP-соединений.

Алгоритм Random Early Detection (RED)

RED позволяет более "справедливо" разделить канал между TCP-соединениями. Он позволяет контролировать нагрузку с помощью выборочного случайного уничтожения некоторых пакетов до того, как очередь будет заполнена полностью и протоколы, подобные TCP, начнут снижать скорость передачи, а также предотвращает повторную синхронизацию. Кроме того, выборочная "потеря" пакетов помогает TCP быстрее найти подходящую скорость передачи данных и удерживать размер очереди и время задержки на разумном уровне. Вероятность "потери" пакета конкретного соединения прямо пропорциональна пропускной способности, используемой этим соединением, а не числу пакетов, т. е. большие пакеты уничтожаются чаще маленьких, что дает достаточно справедливое распределение полосы пропускания.

При работе с RED пользователю необходимо определиться со значениями трех параметров: минимум (min), максимум (max) и превышение (burst). 

Минимум - это минимальный размер очереди в байтах, выше которого начнется выборочная потеря пакетов. Максимум - это "мягкий" максимум, алгоритм будет пытаться удержать размер очереди ниже этого предела. Превышение - максимальное число пакетов, которые могут быть приняты в очередь сверх установленного максимального предела.

Минимальный размер очереди рассчитывается, исходя из максимально допустимого времени задержки в очереди и пропускной способности канала. Если установить минимальный предел слишком маленьким, это приведет к снижению пропускной способности, слишком большим - к увеличению времени задержки.

Максимальный размер очереди нужно задавать по меньшей мере в два раза больше минимального, чтобы снизить вероятность повторной синхронизации. На медленных линиях, с небольшим минимальным пределом размера очереди, максимальный предел следует задавать в четыре, а иногда и более раз больше минимального.

Предел превышения отвечает за поведение RED на пиковых нагрузках. Кроме того, необходимо будет определиться с предельным размером очереди ( limit ) и средним размером пакета ( avpkt ). Когда очередь достигает предельного размера, RED переходит к алгоритму "отсечения конца".

При малых размерах очередей метод RED более эффективен, чем другие методы. Он также более устойчив к трафику, имеющему "взрывной" характер.

2. Алгоритмы обработки очередей Стратегия FlFO

Алгоритм обслуживания очередей First In-First Out (FIFO), также называемый First Come First Served, является самым простым. Пакеты обслуживаются в порядке поступления без какой-либо специальной обработки.

Такая схема приемлема, если исходящий канал имеет достаточно большую свободную полосу пропускания. Алгоритм FIFO относится к так называемым неравноправным схемам обслуживания очередей, так как при его использовании одни потоки могут доминировать над другими и захватывать несправедливо большую часть полосы пропускания. В связи с этим применяются равноправные схемы обслуживания, предусматривающие выделение каждому потоку отдельного буфера и равномерное разделение полосы пропускания между разными очередями.

Очередь с приоритетами

Очередь с приоритетами (Priority Queuing) - это алгоритм, при котором несколько очередей FIFO (могут использоваться алгоритмы Tail Drop, RED и т. д.) образуют одну систему очередей.

При приоритетной организации очередей (PQ) важный трафик получает самую быструю обработку в каждом пункте, в котором она используется. Этот метод назначает строгий приоритет важного трафика и может обеспечить гибкое задание уровня приоритета в соответствии с сетевыми протоколами. При приоритетной организации очереди каждый пакет помещается в одну из четырех очередей - с высоким, средним и низким приоритетом ожидания - на основе присвоенного приоритета. Назначение разным потокам нескольких разных приоритетов производится по ряду признаков, таких как источник и адресат пакета, транспортный протокол, номер порта. Пакеты, которые не подверглись классификации этим механизмом занесения в список приоритетов, по умолчанию направляются в нормальную очередь. Во время передачи этот алгоритм предоставляет очередям с более высоким уровнем приоритета преференциальный режим по сравнению с очередями с низким уровнем приоритета.

Class-Based Queuing (CBQ)

Классовые дисциплины широко используются в случаях, когда различные виды трафика необходимо обрабатывать по-разному. Примером классовой дисциплины может служить CBQ.

Когда трафик передается на обработку классовой дисциплине, он должен быть отнесен к одному из классов (классифицирован). Определение принадлежности пакета к тому или иному классу выполняется фильтрами.

Фильтры, присоединенные к дисциплине, возвращают результат классификации (класс пакета), после чего пакет передается в очередь, соответствующую заданному классу. Каждый из классов в свою очередь может состоять из подклассов и иметь свой набор фильтров для выполнения более точной классификации своей доли трафика. В противном случае пакет обслуживается дисциплиной очереди класса.

Кроме того, в большинстве случаев классовые дисциплины выполняют шейпинг (формирование) трафика, с целью переупорядочивания пакетов и управления скоростью их передачи. Это совершенно необходимо в случае перенаправления трафика с высокоскоростного интерфейса (например, Еthernet) на медленный (например, модем).

Это позволяет различным приложениям совместно использовать одну и ту же сеть, причем каждое из них предъявляет свои специфические минимальные требования к ширине полосы или к задержке.

Взвешенные очереди

Для резервирования полосы пропускания в сети IP может использоваться метод WFQ (Weighted Fair Queuing). Метод WFQ позволяет для каждого вида трафика выделять определенную часть полосы пропускания. Оператор через систему административного управления может задать количество очередей. В случае если одна очередь не использует полностью выделенную ей полосу пропускания, то свободный резерв полосы пропускания может задействоваться для передачи информации из следующей очереди.

Стратегия справедливых (взвешенных) очередей WFQ используется по умолчанию для интерфейсов низкого быстродействия. WFQ делит трафик на несколько потоков, используя в качестве параметров (для IP-протокола) IP-адреса и порты получателя и отправителя, а также поле IP-заголовка ToS ( Type of Service ). Значение ToS служит для квалификации части выделяемой полосы потока. Для каждого из потоков формируется своя очередь. Максимально возможное число очередей равно 256. Очереди обслуживаются в соответствии с карусельным принципом (round-robin). Более высокий приоритет имеют потоки с меньшей полосой, например, Telnet. По умолчанию каждая из очередей имеет емкость 64 пакета (но допускается значение и менее 4096 пакетов). В сетях существует 8 уровней приоритета. Следует иметь в виду, что WFQ не поддерживается в случае туннелирования или шифрования. Поток с низким весом получает более высокий уровень обслуживания, чем поток с высоким уровнем. Когда задействованы биты ToS, WFQ реализует приоритетное обслуживание пакетов согласно значению этого кода. Весовой фактор обратно пропорционален уровню приоритета.

Справедливые очереди, базирующиеся на классах (CBWFQ)

Дальнейшим развитием технологии WFQ является формирование классов потоков, задаваемых пользователем. Алгоритм CBWFQ предоставляет механизм управления перегрузкой. Параметры, которые характеризуют класс, те же, что и в случае WFQ (только вместо ToS используется приоритет). В отличие от WFQ здесь можно в широких пределах перераспределять полосу пропускания между потоками. Для выделения класса могут привлекаться ACL (Access Control List) или даже номер входного интерфейса. Каждому классу ставится в соответствие очередь. В отличие от RSVP данный алгоритм гарантирует полосу лишь в условиях перегрузки. Всего может быть определено 64 класса. Нераспределенная полоса может использоваться потоками согласно их приоритетам.

Очереди с малой задержкой (LLQ)

В некоторых случаях, например, в случае VoIP, важнее обеспечить малую задержку, а не широкую полосу пропускания. Для таких задач разработан алгоритм LLQ (Low Latency Queuing), который является модификацией CBWFQ. В этом алгоритме пакеты всех приоритетов, кроме наивысшего, вынуждены ждать, пока очередь более высокого приоритета будет опустошена. Разброс задержки в высокоприоритетном потоке может быть связан только с ожиданием завершения передачи пакета низкого приоритета, начавшейся до прихода приоритетного кадра. Такой разброс определяется диапазоном длин кадров.

6. Протокол резервирования ресурсов - RSVP

Одним из средств обеспечения качества IP-телефонии и особенно интернет-телефонии является использование протокола резервирования ресурсов (Resource Reservation  

Protocol, RSVP), рекомендованного комитетом IETF. С помощью RSVP мультимедиапрограммы могут потребовать специального качества обслуживания

(specific quality of service - QoS) посредством любого из существующих сетевых протоколов - главным образом IP, хотя возможно использовать и UDP, - чтобы обеспечить качественную передачу видео- и аудиосигналов.

Протокол RSVP предусматривает гарантированное QoS благодаря тому, что через каждый компьютер, или узел, который связывает между собой участников телефонного разговора, может передаваться определенное количество данных.

Протокол RSVP предназначен только для резервирования части пропускной способности. Используя RSVP, отправитель периодически информирует получателя о свободном количестве ресурсов сообщением RSVP Path (рис. 16). Транзитные маршрутизаторы по мере прохождения этого сообщения также анализируют имеющееся у них количество свободных ресурсов и подтверждают его соответствующим сообщением RSVP Resv, передаваемым в обратном направлении. Если ресурсов достаточно, то отправитель начинает передачу. Если ресурсов не достаточно, получатель должен снизить требования или прекратить передачу информации.

 

Рис. 16. Применение протокола RSVP

RSVP - это протокол сигнализации, который обеспечивает резервирование ресурсов для предоставления в IP-сетях услуг эмуляции выделенных каналов. Протокол позволяет системам запрашивать, например, гарантированную пропускную способность такого канала, предсказуемую задержку, максимальный уровень потерь. Но резервирование выполняется лишь в том случае, если имеются требуемые ресурсы.

Одной из особенностей RSVP является то, что запросы на резервирование ресурсов направляются только от получателей данных отправителям, а не наоборот. Такой подход обусловлен тем, что лишь устройство-получатель знает, с какой скоростью оно должно получать данные, чтобы надежно декодировать аудио- или видеосигналы. Другая особенность RSVP - резервирование производится лишь для одного направления. Кроме того, RSVP не допускает смешения аудио- и видеосигналов на зарезервированном канале.

Когда RSVP-программы закончат сеанс связи, они должны вызвать функцию отмены, предусмотренную этим протоколом. Отмена аннулирует все запросы на ресурсы, сделанные программой, и позволяет другим прикладным программам использовать коммуникационные возможности Интернета. Если программе не удается выполнить отмену, то предусмотренные протоколом средства по истечении некоторого промежутка времени обнаружат это и автоматически отменят запрос на ресурсы.

Недостатком протокола RSVP является то, что полоса пропускания, выделяемая источнику информации, при снижении активности источника не может быть использована для передачи другой информации. Поскольку для реализации QoS протокол RSVP требует резервирования ресурсов или каналов связи, небрежные или безответственные пользователи могут захватить ресурсы сети, инициируя несколько сеансов QoS подряд. Как только канал зарезервирован, он становится недоступным для других пользователей, даже если тот, кто его затребовал, ничего не передает. К сожалению, в RSVP отсутствует четкий механизм предотвращения подобных ситуаций, и решение этой проблемы возлагается на сетевых администраторов. Очевидно, что необходимо предусмотреть более жесткий контроль, чтобы RSVP имел успех. Такой технологией стала MPLS (Multiprotocol Label Switching) - это технология быстрой коммутации пакетов в многопротокольных сетях, основанная на использовании меток. 

6.1 Архитектура MPLS обеспечивает построение магистральных сетей, имеющих практически неограниченные возможности масштабирования, повышенную скорость обработки трафика и высокую гибкость с точки зрения организации дополнительных сервисов. Кроме того, технология MPLS позволяет интегрировать сети IP и АТМ, за счет чего поставщики услуг смогут не только сохранить средства, инвестированные в оборудование асинхронной передачи, но и извлечь дополнительную выгоду из совместного использования этих протоколов. 

Преимущества технологии MPLS:

•       отделение выбора маршрута от анализа IP-адреса (дает возможность предоставлять широкий спектр дополнительных сервисов при сохранении масштабируемости сети);

•       ускоренная коммутация (сокращает время поиска в таблицах);

•       гибкая поддержка QoS , интегрированных сервисов и виртуальных частных сетей;

•       эффективное использование явного маршрута;

•       сохранение инвестиций в установленное ATM-оборудование;      разделение функциональности между ядром и граничной областью сети.

Сеть MPLS подразделяется на две функционально различные области - ядро и граничную область. Ядро образуют устройства, минимальным требованием к которым является поддержка MPLS и участие в процессе маршрутизации трафика для того протокола, который коммутируется с помощью MPLS. Маршрутизаторы ядра занимаются только коммутацией. Все функции классификации пакетов по различным FEC, а также реализацию таких дополнительных сервисов, как фильтрация, явная маршрутизация, выравнивание нагрузки и управление трафиком, берут на себя граничные LSR. В результате интенсивные вычисления приходятся на граничную область, а высокопроизводительная коммутация выполняется в ядре, что позволяет оптимизировать конфигурацию устройств MPLS в зависимости от их местоположения в сети.

Таким образом, главная особенность MPLS - отделение процесса коммутации пакета от анализа IP-адресов в его заголовке, что открывает ряд привлекательных возможностей.

Очевидным следствием описанного подхода является тот факт, что очередной сегмент LSP может не совпадать с очередным сегментом маршрута, который был бы выбран при традиционной маршрутизации. Поскольку на установление соответствия пакетов определенным классам FEC могут влиять не только IP-адреса, но и другие параметры,     можно             реализовать,   например,         назначение     различных LSP пакетам, относящимся       к          различным     потокам RSVP или         имеющим       разные приоритеты обслуживания.          Конечно,        подобный       сценарий         удается           осуществить и          в обычных маршрутизируемых сетях, но решение на базе MPLS проще и к тому же гораздо лучше масштабируется.

Каждый из классов FEC обрабатывается отдельно от остальных - не только потому, что для него строится свой путь LSP, но и в смысле доступа к общим ресурсам (полосе пропускания канала         и          буферному     пространству).           В         результате технология MPLS позволяет         очень эффективно    поддерживать            требуемое качество обслуживания, не нарушая предоставленных пользователю гарантий. Применение в LSR таких             механизмов    управления         буферизацией            и          очередями, как WRED, WFQ или CBWFQ, дает возможность оператору сети MPLS контролировать распределение ресурсов и изолировать трафик отдельных пользователей.

Использование явно задаваемого маршрута в сети MPLS свободно от недостатков стандартной IP-маршрутизации от источника, поскольку вся информация о маршруте содержится в метке и пакету не требуется нести адреса промежуточных узлов, что улучшает управление распределением нагрузки в сети.

Таблица 16.  Сравнение технологий IntServ, DiffServ, MPLS

Параметр	IntServ	DiffServ	MPLS
Метод обеспечения QoS	Резервирование	Приоритезация	Перемаршрутизация
Число              обслуживаемых классов QoS	3	3	0
Перечень задаваемых показателей качества	Полоса пропускания	Скорость передачи трафика	-
	Максимальная сетевая задержка	Сетевая задержка
	Джиттер	Коэффициент потери пакетов
Необходимость использования дополнительных протоколов	RSVP	Нет	LDP, CR-LDP, RSVP
Требования    к производительности маршрутизаторов	Высокие	Низкие	Средние
Эффективность масштабирования сети	Невысокая	Высокая	Высокая
Совместимость оборудования разных производителей	Средняя	Высокая	Средняя
Гарантированность обеспечения качества	Высокая	Средняя	Высокая                         с использованием RSVP

Так как для обеспечения качества только анализируется поле заголовка пакета IP и не используются никакие вспомогательные протоколы сигнализации, то проблема совместимости оборудования разных производителей неактуальна.

Технология DiffServ может использоваться в транзитной сети. Но в условиях однородного трафика, например только голосового, принцип применения приоритетов теряет смысл и сеть начинает работать в режиме Best Effort.

MPLS (многопротокольная коммутация по меткам) предназначена для ускорения коммутации пакетов в транспортных сетях. Основное отличие этой технологии от рассмотренных ранее в том, что MPLS изначально не является технологией обеспечения качества и становится таковой только при использовании протокола RSVPTE.

На границе сети MPLS маршрутизаторы помечают пакеты специальными метками, определяющими дальнейший маршрут следования пакета к месту назначения. В результате анализируются не адреса IP, а короткие цифровые метки, что существенно снижает сетевую задержку и требования к производительности маршрутизаторов. Для корректного взаимодействия их между собой и обмена информацией о создаваемых метках используются протоколы распределения меток (LDP, CR-LDP, RSVP-TE и др.).

Маршрут может также задаваться административно. В этом случае заранее определяется весь перечень узлов, через которые он будет проходить. Если для соединения требуется гарантия определенного уровня качества, то для распределения меток применяется протокол RSVP-TE, и на маршруте резервируются необходимые ресурсы. В RSVP-

TE предусмотрены контроль и обновление установленного соединения, так что в случае повреждения в сети можно динамически перевести потоки трафика на резервный маршрут.

Технология MPLS характеризуется высокой масштабируемостью и рассматривается в качестве наиболее перспективной для передачи трафика IP. Она стандартизована IETF, поэтому, как и в случае с IntServ, при отклонении от спецификаций могут возникнуть проблемы с совместимостью оборудования разных производителей.

7.Особенности учета и биллинга IP-услуг

Рассмотрим основные особенности учета и биллинга IP-услуг. Биллинг (от англ. billing - составление счета) - это прежде всего система выставления счетов за потребленные услуги. Условиями для выставления счета являются:

1.      Наличие пакета услуг, присущих традиционной телефонии.

Исходя из общих принципов реализации сети IP-телефонии, ее пользователи должны получать те же услуги, что и при использовании традиционной телефонной связи ТфОП. Однако использование IP-сети в качестве транспортной архитектуры позволяет провайдерам предоставлять пользователям целый набор дополнительных услуг, основанных на протоколе IP (передача данных, факсимильных сообщений, электронной почты, видео и др.). Особенности предоставления услуг IP-телефонии и других видов IP-услуг выдвигают специфические требования к организации системы биллинга и менеджмента пользователей.

2.      Ведение учета в режиме реального времени.

Особенность состоит в том, что IP-телефония основывается на непосредственном взаимодействии с пользователями - поэтому провайдеры должны постоянно следить за каждым их действием. Информация о действиях провайдера не должна запаздывать, так как это может отрицательно повлиять на действия пользователя. В конечном счете, провайдеры должны быть чрезвычайно гибки и оперативны при предоставлении услуг, которые они предлагают, должны быстро предлагать новые услуги для продажи и эффективно управлять пользователями.

3.      Конфиденциальность разнородной информации.

Основная проблема, возникающая при организации биллинга услуг IP, заключается в значительном отличии по содержанию этих услуг друг от друга. Электронная почта, веб-серфинг, IP-телефония, чат и некоторые другие услуги требуют сбора различной информации.

Условно можно разделить услуги следующим образом:

o        основанные на соединении (IP-телефония); o           основанные на транзакциях; o     услуги по передаче файлов; o           услуги доступа к базам данных.

Информация должна собираться в различных узлах сети, возможно, принадлежащих различным операторам. При этом возникает задача обеспечения конфиденциальности такого рода данных.

4.      Ведение учетной информации.

В отличие от коммутируемых сетей, где учетные данные состоят, в основном, из событий (начало и завершение сеанса связи, использование дополнительных услуг, цифры номера), в сетях IP услуги определяются метриками (количество переданных и принятых байтов, число пакетов, номера портов, адреса IP). Набор метрик зависит от предоставляемых услуг. Информация, соответствующая предоставленной услуге, может быть фрагментирована и отправлена на систему учета несколькими пакетами. Более того, информация об услуге может быть отправлена с нескольких узлов. Система сбора и обработки учетной информации должна обладать достаточной вычислительной мощностью и вместительностью для хранения данных. Также необходимы механизмы для уменьшения объема учетной информации.

5.      Контроль и регулирование качества обслуживания.

Одной из характеристик услуг, предоставляемых сетью IP, является качество обслуживания - QoS. В отличие от ТфОП, обеспечивающей фиксированное качество обслуживания, в IP-сетях оно может варьироваться. Уровень QoS может зависеть от абонемента пользователя или от запрашиваемой услуги. Биллинговая система должна уметь учитывать качество обслуживания, предоставляемое пользователю.

6.      Возможность взаимодействия с другими сетями и службами.

Оператор, предоставляя абоненту определенную услугу, может задействовать при этом несколько различных сетей и служб. Например, одновременно могут быть задействованы ТфОП, сеть IP-телефонии, справочная служба, услуга уведомления о вызове из ТфОП по Интернету. Оператору и пользователю необходимо знать общую картину предоставленных услуг. Получить ее можно, собирая и сопоставляя учетные данные от разных сетей и служб.

Рис. 17. Обобщенная схема сбора статистической и биллинговой информации в IPсети

7.      Гибкость системы.

Биллинговые системы для предоставления IP-услуг должны обладать большей гибкостью, чем системы, используемые на сетях операторов традиционной телефонии. Это позволит компании, использующей систему учета и биллинга, сконфигурировать ее в точном соответствии со своими нуждами.

8.      Гибкость систем расчета с пользователем.

Часто провайдеры IP-услуг используют способ расчета с абонентами по предоплатным схемам. В таком случае необходимо осуществлять обработку учетной информации и биллинг в реальном масштабе времени. Это позволит прекратить предоставление услуги абоненту при истечении средств на его счету.

Для удобства расчетов абонентов с оператором может применяться веб-интерфейс. Подобная услуга позволяет абонентам быстро осуществлять платежи и проще вести контроль над расходами. Например, предложенный пользовательский интерфейс "Личного кабинета" дает возможность легко и полно контролировать всю статистику по совершенным звонкам, удобно настраивать множество сервисных функций системы, а также всегда контролировать свой счет и вносить на него средства несколькими разными способами - с помощью платежных карт, покупки кодов, сетевых платежных систем и т. д.

Многие IP-услуги предоставляются с использованием сетей нескольких операторов и узлов различных производителей. Биллинг подобных услуг требует согласованного сбора учетной информации со всех задействованных элементов сети.

Индустриальных стандартов в настоящее время для этого нет. Кроме того, нет четко установленных стандартов для форматов записи и протоколов передачи этой информации на серверы учета и в биллинговые системы.

Вместе со многими проблемами учет и биллинг IP-услуг дает операторам множество новых возможностей. Учетные данные могут быть использованы для лучшего понимания нужд и требований пользователей и быстрого ввода в эксплуатацию необходимых услуг. Также они помогают при анализе использования абонентами тех или иных ресурсов, могут применяться для нахождения оптимальной конфигурации сети, управления трафиком, планирования емкостей хранилищ информации и обнаружения недобросовестных пользователей (рис. 17).

7.2. Требования к системе биллинга и менеджмента пользователей IP-телефонии

Работа в реальном масштабе времени

При традиционной телефонной связи программное обеспечение, которое выполняет расчеты за пользование услугами телефонной связи, не имеет непосредственного контакта с абонентом во время разговора. Детальная информация о вызовах (CDR) поступает от телефонных станций в течение месяца и только в конце месяца (или расчетного периода) вся собранная информация о вызовах передается в биллинг-систему.

Этот метод расчетов за услуги связи не подходит для рынка услуг IP-телефонии, который часто не регулируется и является чрезвычайно конкурентным. Провайдеры IPтелефонии должны иметь возможность следить за любым действием каждого заказчика, и информация о них должна поступать не в конце месяца, когда уже слишком поздно осуществлять воздействие.

Поэтому система менеджмента и биллинга, используемая для поддержки услуг IPтелефонии, должна уметь отслеживать и управлять действиями абонентов в реальном масштабе времени (рис. 18). Система биллинга и менеджмента пользователей реального масштаба времени даст возможность провайдерам получать информацию немедленно и использовать ее в своей работе.

 

Рис. 18. Схема взаимодействия обслуживания вызова IP-телефонии при использовании комплексной системы биллинга и менеджмента реального масштаба времени

Кроме того, система биллинга и менеджмента пользователей должна не только обеспечивать расчеты в реальном масштабе времени, но и позволять развертывать новые услуги достаточно быстро, чтобы воспользоваться преимуществом появления их на рынке. При необходимости система должна рассчитывать, отслеживать и анализировать трафик и состояние счетов пользователей. Система должна быть гибкой, чтобы эффективно отвечать на конкурентное давление и удовлетворять требованиям провайдеров IP-телефонии.

Поддержка предоплаты

Опыт обслуживания IP-телефонии показывает, что предоплаченные услуги составляют главную часть вызовов IP-телефонии. Предоплаченные телефонные карточки позволяют провайдерам IP-телефонии избегать недоплаты и задолженности по оплате. Система биллинга и менеджмента пользователей в реальном масштабе времени должна обеспечивать жесткие требования провайдеров по контролю за возможностями предоплаченных карт. В этом случае провайдеры могут предлагать любые предоплаченные услуги, включая дебетные карты, непополняемые и пополняемые предоплаченные счета. Другими словами, система биллинга и менеджмента пользователей должна позволять создавать комплексную архитектуру реального времени, которая обеспечит:

•       поиск наилучшего пути для вызова;

•       множественный доступ при одном предоплаченном счете;

•       уведомление по электронной почте при уменьшении ниже нормы суммы на счете;

•       пополнение счета через телефон или веб-интерфейс;

•       получение информации о зональных тарифах, остатках на счетах и другой информации по обработке и маршрутизированию заранее оплаченных вызовов в реальном времени.

Расчеты с абонентами подразумевают:

•       формирование счета для клиентов, работающих в кредит;

•       поддержку различных периодов оплаты счетов - неделя, две недели, месяц;

•       возможность настройки печатной формы счета;

•       ввод и учет платежей абонента;          поддержка расчетов в нескольких валютах.

Два способа работы с клиентами

 

Рис. 19. Способы работы с клиентами

 

Рис. 20. Тарифные планы

Может быть предусмотрена гибкая система формирования цены, например, в зависимости от типов дней и временных периодов. Существует два способа назначения цены - по кодам доступа и по тарифным зонам.

Поддержка вторичных провайдеров

Вторичные провайдеры (субпровайдеры) позволяют первичным провайдерам воспользоваться преимуществом модели бизнеса вне своей фирменной марки, когда их корпоративные пользователи становятся "виртуальными" провайдерами IPтелефонии или провайдерами фирменных услуг (Branded Service Provider - BSP). Такие вторичные провайдеры предлагают продукты или услуги интернет-телефонии под их собственной корпоративной маркой без необходимости создания инфраструктуры менеджмента и поддержки услуг первичной сети.

Системы биллинга и менеджмента пользователей вторичных провайдеров должны поддерживаться подобной системой первичного провайдера для обеспечения всех услуг IP-телефонии. Это дает возможность первичным провайдерам предложить своим вторичным провайдерам полный диапазон услуг по биллингу и менеджменту - создание счетов, тарификация, расчет, составление счетов, менеджмент пользователями и выписка счетов.

Система биллинга и менеджмента должна гарантировать абсолютную защиту данных пользователей, тарифных планов, счетов и сообщений и обеспечивать безопасный доступ вторичного провайдера к системе в реальном масштабе времени.

Идентификация в реальном масштабе времени

Идентификация означает проверку индивидуальной подлинности пользователя. При услугах IP-телефонии - делает ли пользователь вызов из дома или офиса, с обычного телефона или компьютера - все вызовы должны быть связаны с определенным пользователем даже при его путешествии. Система биллинга и менеджмента пользователей IP-телефонии должна поддерживать надежные механизмы идентификации, чтобы опознавать пользователя уникально, и обеспечивать изменение этих механизмов в реальном времени вне зависимости от местонахождения пользователя в момент совершения им звонка.

Авторизация обеспечивает разрешение предоставления пользователю тех услуг, которые он требует. В традиционных биллинг-системах отсутствует взаимодействие с пользователями в реальном масштабе времени, и в них нет никакой встроенной возможности обеспечения авторизации.

 

Рис. 21. Интеграция биллинг-системы с системой управления правами доступа

На высоко-конкурентном рынке IP-услуг провайдеры должны иметь возможность быстро отвечать на изменяющиеся рыночные условия. Таким образом, системы биллинга и менеджмента пользователей IP-телефонии должны позволять провайдеру быстро и легко создавать новые пакеты услуг телефонной связи, набор планов тарификации и быстро предлагать на рынок новые услуги.

Возможные варианты расширения списка услуг:

•       Dial-up;

•       выделенные линии (учет трафика);    Web-hosting, mail и др.

Гибкость системы

Чтобы оставаться лидерами в предоставлении любых IP-услуг, провайдеры должны иметь возможность быстро добавить или изменить услуги, информацию о пользователе, тарифы и другие данные без прерывания выполняемых функций и без расходов на дополнительное программирование. Программное обеспечение системы биллинга и менеджмента пользователей IP-телефонии должно строиться по блочнофункциональному принципу для обеспечения его быстрого внедрения у провайдера и возможностей масштабирования. Кроме этого, система должна работать с любым сетевым окружением для сбора детальной информации о вызовах (CDR) и интегрироваться с любыми прикладными системами финансового учета (рис. 22).

 

Рис. 22. Функциональные уровни системы биллинга и менеджмента IP-телефонии

7.3. Обзор систем биллинга и менеджмента пользователей IP-телефонии Рассмотрим некоторые характеристики наиболее распространенных систем.

Система Internet Management System

Система Internet Management System (IMS 3.1) фирмы Belle Systems является многофункциональной системой биллинга и менеджмента пользователей IP-телефонии, основанной на взаимодействии с сетевыми элементами. Данная система позволяет конфигурировать и управлять широким спектром сетевого оборудования, включая серверы доступа, маршрутизаторы и голосовые шлюзы фирмы Cisco. В систему встраивается сервер RADIUS для обеспечения идентификации пользователей при доступе через коммутируемую сеть. Система IMS обеспечивает гибкие схемы тарификации для пользователей, возможность контроля параметров QoS, поддержку систем финансового учета и бизнес-управления. Система рассчитана на поддержку более 20 миллионов счетов и 1 миллиона пользователей и предназначена для крупных операторов связи.

Система iPhoneEX

Система может поддерживать от 100 до 100.000 пользователей. Составление счетов может выполняться из одного центрального пункта для всех узлов сети и в каждом узле сети. Система IPhonEX обеспечивает четыре различных формы расчетов с пользователями:

•       неограниченный кредит - пользователи имеют неограниченную возможность получения услуг интернет-телефонии;

•       ограниченный кредит - при достижении предела кредита учетная запись автоматически блокируется в реальном масштабе времени и пользователю дается отказ в

предоставлении услуг до оплаты кредита;

•       дебетовая плата/телефонные карточки - при достижении заранее оплаченного количества минут разговора дальнейшие запросы на услугу отвергаются и учетная запись блокируется;

•       дебетовая плата с пополнением - производится определенная предоплата, когда стоимость разговоров достигает оплаченного количества, учетная запись блокируется, но имеется возможность доплатить снова.

В состав системы IPhonEX входят следующие модули:

•       модуль межсетевого биллинга Inter-Billing system - обеспечивает взаиморасчеты между провайдерами интернет-телефонии в сети. Модуль позволяет распределять затраты между различными узлами и различными операторами. Обеспечивает детальные сообщения данных по требованию для каждого провайдера;

•       модуль управления вызовами Call Management Module - обеспечивает пользователям большой набор сложных запросов сообщений управления;

•       модуль безопасности Guard Module - обеспечивает обнаружение несанкционированного доступа с помощью контроля за определенным набором параметров, задаваемых самим пользователем;

•       модуль трафика Traffic - является инструментом для анализа загрузок шлюза. Полученные данные могут служить основой для оптимального распределения ресурсов и наиболее эффективных мер экономии финансовых затрат.

Система Intranet IPT

Система Intranet IPT фирмы Portal Software объединяет управление всеми основными операциями бизнеса IP-телефонии, включая способность регистрировать, управлять пользователями и организовывать расчеты за предоставленные услуги. Ее архитектура функционирует в реальном масштабе времени и является открытой средой развития, обеспечивая платформу для создания службы управления телефонной связи в IP-сети.

Особенности работы системы Intranet IPT в реальном масштабе времени включают:

•       регистрацию пользователя;

•       идентификацию вызывающего абонента;

•       проверку предела кредита;

•       добавление к заранее оплаченной сумме и включение в учетную запись;

•       работу с кредитными карточками;

•       возможность выбора маршрута наименьшей стоимости;    междоменное согласование и регулирование тарифов.

Система Talking NT Enterprise SQL

Система Talking NT обеспечивает составление счетов в реальном масштабе времени, гибкий выбор маршрута наименьшей стоимости, качество обслуживания по требованию, предупреждение об окончании предоплаты, автоматическое завершение вызова при окончании оплаты, управление вызовом со стороны пользователя.

Система Talking NT обеспечивает следующие дополнительные возможности:

•       заранее оплаченная и без предварительной оплаты дебетовая карточка;

•       международный обратный вызов;

•       заранее оплаченный беспроводный доступ;

•       услуга персонального номера;

•       пополняемая кредитная карточка.

Пример использования системы Talking NT на сети поясняется (рис. 23).

 

Рис. 23. Пример использования системы Talking NT Enterprise SQL

Система Telephony Gateway Billing Manager

Стандартные особенности включают средства контроля доступа к услугам и биллинг в реальном времени на базе предоплаты или постоплаты, а также различные средства управления учетными записями. Система может масштабироваться для обработки фактически неограниченного числа учетных записей и может быть сконфигурирована для защищенного доступа в любой точке через Интернет (рис. 24).

 

Рис. 24. Структурная схема системы биллинга Telephony Gateway Billing Manager

Система BizBill

Биллинговая система BizBill фирмы Biztrans позволяет провайдерам Интернета предоставлять услуги интернет-телефонии через их узлы доступа и обеспечивает все расчетные операции в одном центре. Система BizBill обеспечивает интеграцию расчетов за Интернет и интернет-телефонию, рассчитывает баланс и выдает необходимую информацию. Используемый в системе интерфейс Интернета дает возможность пользователю регистрироваться интерактивно.

Система IAF Horizon

Система IAF Horizon фирмы Select Technology Group является многофункциональной платформой для поддержки IP-услуг. В дополнение к традиционным услугам тарификации IP-телефонии с предоплатой система IAF Horizon обеспечивает:

•       предоставление услуг по заранее оплаченным телефонным карточкам с оценкой остатка в реальном масштабе времени;

•       поддержку управления вызовом во время соединения;

•       управление телефонной карточкой, включая определение размера оплаты и контроль оплаченного времени соединения;

•       использование сообщений интерактивной системы ответа IVR, которые могут быть записаны и настроены на язык вызывающего пользователя;

•       простоту создания и управления алгоритмами тарификации, включая создание различных вариантов тарификации применительно к географическим комбинациям;

•       перенаправление вызова и блокирование номера;

•       расширенные возможности составления счетов, например, с посекундной оплатой, со свободным периодом и с различными коэффициентами и параметрами дисконтирования.

Система IAF Horizon обеспечивает аутентификацию в реальном масштабе и расчет с абонентами сети интернет-телефонии, построенной на базе оборудования фирм Cisco и Ericsson.

Список источников

1.  Гольдштейн, Б.С. IP-телефония / Б.С. Гольдштейн, А.В. Пинчук – М.: Радио и cвязь, 2019.

2.  А.А. Атцик., А.Б. Гольдштейн - IP-коммуникации в NGN: учебное пособие СПбГУТ. – СПб, 2018.

3.  Internet: www.cisco.ru, www.cisco.com,

4.  https://www.itu.int/en/ITU-D/Regulatory-Market/Documents/Session3_Kucheryaviy.pdf

Краткое описание документа:

МЕТОДИЧЕСКОЕ ПОСОБИЕ ЛЕКЦИОННОГО МАТЕРИАЛА ПО ДИСЦИПЛИНЕ: «ЭКСПЛУАТАЦИЯ ОБЪЕКТОВ СЕТЕВОЙ ИНФРАСТРУКТУРЫ» предназначено для специальности: 09.02.06 «Сетевое и системное администрирование». Лекции написаны по разделу IP-телефонии.