Адресация

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

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

Подавляющее большинство сетей сейчас использует протокол IPv4 (Интернет - протокол версии 4), хотя уже разработана шестая версия протокола IP, которая применяется в некоторых недавно созданных крупных сетях. Схема адресации протокола IPv4, который был определён в RFC 791, предусматривает размер адресного поля 32 бита, что даёт 232 (или 4 294 967 296) потенциальных адресов.

IP-адрес любой рабочей станции состоит из адреса сети и адреса компьютера в этой сети. В архитектуре адресации предусмотрено пять форматов адреса, каждый из которых начинается с одного, двух, трёх или четырёх битов, идентифицирующих класс сети (класс А, В, С, D или Е). Область сетевого идентификатора (Network ID) определяет конкретную сеть в классе, а область Host ID идентифицирует конкретный компьютер в сети1.

• Адреса класса А идентифицируются начальным битом 0. Следующие семь битов определяют конкретную сеть (число возможных значений - 128 или 27). Остальные 24 бита определяют конкретный компьютер в сети, при возможном количестве компьютеров -1 б 777 216 (224). Адреса класса А предназначены для очень крупных сетей с большим количеством рабочих станций.
Первые адреса класса А были присвоены таким компаниям как IBM Corporation, Hewlett-Packard Company, Ford Motor Company и др.

• Адреса класса В идентифицируются начальной двухбитовой двоичной последовательностью 10. Следующие 14 битов определяют сеть, при возможном количестве сетей 16 384 (214). Остальные 16 битов определяют конкретный компьютер, с возможным количеством компьютеров - 65 536 (216).

• Адреса класса С идентифицируются начальной трёхбитовой последовательностью 110. Следующие 21 бит определяют сеть, с возможным количеством сетей - 2 б97 152. Остальные 8 битов определяют конкретный компьютер в сети, с возможным количеством компьютеров - 256 (28). Большинство организаций имеют адреса класса С.

• Адреса класса D идентифицируются начальной четырёхбитовой последовательностью 1110. Адреса этого класса предназначены для групповой передачи, и оставшиеся 28 битов определяют групповой адрес.

• Адреса класса Е идентифицируются начальной четырёхбитовой двоичной последовательностью 1111. Адреса этого класса зарезервированы для будущего использования.

Способ, при помощи которого записываются все IP-адреса, называется пунктирной десятичной системой обозначений. Каждое 32-битовое адресное поле разделено на четыре поля в виде ххх.ххх.ххх.ххх, и каждому полю даётся десятичное числовое значение от 0 до 255, выраженное в виде одного октета (28 = 256 или 0-255). Адреса класса А начинаются с 1-127, адреса класса В - с 128-191, и адреса класса С - с 192-223.

1 Строго говоря, адрес идентифицирует только сетевой интерфейс рабочей станции, т.е. точку подключения к сети.

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


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

Как уже отмечалось, протокол IP версии 4 предусматривает размер адресного поля 32 бита, что даёт 232 (или 4 294 967 296) потенциальных адресов. Однако возрастающая популярность технологии TCP/IP привела к истощению плана нумерации протокола IPv4 аналогично тому, как популярность подключённых к телефонной сети факсимильных аппаратов, сотовых телефонов, пейджеров, компьютерных модемов и даже копировальных машин привела к истощению плана нумерации ТфОП. Дополнительной проблемой является тот факт, что очень большое количество адресов класса А и класса В было выделено крупным организациям, которые в них на самом деле не нуждались. В связи с тем, что фактически использовался только небольшой процент адресов, огромное количество доступных адресов было потеряно. Это напоминает расточительность, с которой выделялись телефонные номера в городских телефонных сетях (за исключением МГТС) блоками по 10 000 номеров, зачастую вне зависимости оттого, сколько их требовалось реально - 100 или 1000.

Чтобы смягчить, по крайней мере - частично, эту проблему, комитет IETF в начале 90-х годов опубликовал в документах RFC 1518 и RFC 1519 положение о бесклассовой междоменной маршрутизации (CfDR). Технология CIDR построена на концепции суперсети (supernetting), состоящей из группы подсетей, каждой из которых присваивается адрес подсети.

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

Протокол IPv6 решает этот вопрос путём расширения адресного поля до 128 битов, обеспечивая тем самым 2128 потенциальных адресов, ЧТО Составляет величину 340.282.366.920.938.463.463.374.607.431.768.211.456.

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

Но вернемся к протоколу IPv4. Компьютер, подключенный к сети Интернет, кроме IP-адреса может идентифицироваться доменным именем. Сеть Интернет разделена на логические области (домены). Адреса в системе имён доменов (DNS), администрирование которых лежит на ICANN, имеют стандартный вид, представляющий собой последовательность имен, разделенных точками, например:

компьютер, организация, домен. Подавляющее большинство из 45 миллионов (или около того) зарегистрированных доменов верхнего уровня (TLD) является коммерческими. Домены TLD, которые идентифицируются как суффикс доменного имени, бывают двух типов: обобщённые домены верхнего уровня (net, corn, org) и коды стран (ru, fi, ua).

Сам же ICANN получил от IANA полномочия по администрированию Интернет-адресов.


При администрировании со стороны IANA, ответственность за присвоение TLD возлагалась на центр сетевой информации Интернет(InterNIC) компании Network Solutions Inc. В течение первых десятков лет существования Интернет, присвоение доменов было бесплатным. Позже, InterNIC начал брать плату за домены .сот в размере $70 за первые два года и $35 за каждый следующий год. В 1999 году InterNIC потерял монопольное право на присвоение доменов, так как в апреле 1999 года были утверждены четыре конкурентные организации на испытательный срок до 25 июня 1999 года. ICANN также объявил, что ряд других заявителей удовлетворяют его критериям аккредитации, и они будут аккредитованы по окончании испытательного срока.

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

4.4 Уровни архитектуры Интернет

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

Для того, чтобы классифицировать различные протоколы и понять их место в общей структуре технологии межсетевого взаимодействия, удобно воспользоваться так называемым “многоуровневым представлением сетевых протоколов”. В рамках такого представления подразумевается, что протоколы более высокого уровня используют функции протоколов более низкого уровня. Классической, хотя и представляющей сейчас, скорее, академический интерес, моделью такого рода является семиуровневая модель взаимодействия открытых систем (Open Systems Interconnection - OSI), разработанная ITU-T в рамках неудавшейся попытки создать международный стандарт семейства сетевых протоколов. Вместе с тем, некоторые результаты данного проекта являются хорошим материалом для учебников, чем мы и воспользуемся.

Рис. 4.1 иллюстрирует взаимоотношения архитектуры Интернет, определенной ARPA, с моделью OSI, а также поясняет функции каждого из уровней.



Архитектура Интернет была разработана агентством ARPA для соединения компьютеров в государственных, военных, академических и других организациях, в основном, на территории США, что обусловило ее практический характер. С другой стороны, модель OSI охватывала более широкий круг вопросов передачи информации, и в ее рамках не был конкретизирован тип взаимодействующих систем, что породило более “дробное” разбиение на уровни. Однако между той и другой архитектурой имеется очевидное соответствие.

Первый уровень модели ARPA - уровень сетевого интерфейса -поддерживает физический перенос информации между устройствами в сети, т.е. объединяет функции двух уровней OSI - физического и звена данных. Уровень сетевого интерфейса обеспечивает физическое соединение со средой передачи, обеспечивает, если это необходимо, разрешение конфликтов, возникающих в процессе организации доступа к среде (например, используя технологию CSMA/CD в сети Ethernet), упаковывает данные в пакеты. Пакет2 -это протокольная единица, которая содержит информацию верхних уровней, и служебные поля (аппаратные адреса, порядковые номера, подтверждения и т.д.), необходимые для функционирования протоколов этого уровня.



Рис. 4.1 Уровни модели OSI и архитектуры Интернет


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

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



2 Иногда при рассмотрении протоколов этого уровня (Ethernet, HDLC) употребляется также термин кадр (frame).

Протокол преобразования адресов (Address Resolution Protocol -ARP) преобразует IP-адреса в адреса, использующиеся в локальных сетях (например, Ethernet). На некоторых рисунках, изображающих архитектуру и взаимосвязь протоколов, ARP размещают ниже IP, чтобы показать его тесную взаимосвязь с Уровнем Сетевого Интерфейса.

Протокол контрольных сообщений - Internet Control Message Protocol (ICMP) предоставляет возможность программному обеспечению рабочей станции или маршрутизатора обмениваться информацией о проблемах маршрутизации пакетов с другими устройствами в сети. Протокол ICMP - необходимая часть реализации стека протоколов TCP/IP.

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

Конечные пользователи взаимодействуют с компьютером на уровне приложений. Разработано множество протоколов, используемых соответствующими приложениями. Например, приложения передачи файлов используют протокол FTP. Web-приложения используют протокол HTTP. Оба протокола FTP и HTTP базируются на протоколе TCP. Приложение Telnet обеспечивает подключение удаленных терминалов. Протокол эксплуатационного управления сетью SNMP позволяет управлять конфигурацией оборудования в сети и собирать информацию об его функционировании, в том числе, и о аварийных ситуациях. Приложения, созданные для организации речевой связи и видеосвязи, используют протокол RТР для передачи информации, чувствительной к задержкам. Х Window - популярный протокол для подключения к интеллектуальному графическому терминалу. Этот список можно продолжать практически бесконечно.



Таким образом, IP- сети используют для передачи информации разнообразные протоколы, причем функции протоколов не зависят оттого, какие данные передаются. Иными словами, IP, ARP, ICMP, TCP, UDP и другие элементы стека протоколов TCP/IP предоставляют универсальные средства передачи информации, какой бы она ни была природы (файл по FTP, Web - страница или аудиоданные).

4.5 Протокол IP версии 4

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

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

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



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

На рис. 4.2 показана структура протокольной единицы протокола IP-дейтаграммы.

Поле версия (version) идентифицирует используемую версию протокола IP, в рассматриваемом случае указывается версия 4. Необходимость этого поля объясняется тем, что в переходный период в сети могут использоваться протоколы разных версий.

Поле длина заголовка (header length), состоящее из 4 битов, определяет длину заголовка, причем длина указывается как количество блоков размером 32 бита. В типичном случае значение этого поля равно 5.

3 При рассмотрении протокола IP версии 6 и вопросов обеспечения качества обслуживания, мы увидим некоторые отклонения от этого принципа.

Версия (Version)		Длина заголовка
Тип обслуживания
Общая длина
Идентификатор фрагмента
Флаги		Смещение фрагмента
Время жизни
Протокол
Контрольная сумма заголовка
Адрес отправителя
Адрес получателя
Опциональные поля и заполнение
Данные

Рис. 4.2 IP-дейтаграмма

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

Поле общая длина (Total Length) определяет общую длину дейтаграммы в октетах (байтах), включая заголовок и полезную нагрузку. Максимальная длина дейтаграммы составляет 65535 октетов, однако, на практике, все рабочие станции и маршрутизаторы работают с длинами, не превышающими 576 байтов. Это объясняется тем, что при превышении указанной длины, снижается эффективность работы сети.



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

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

Поле флагов (Flags) обеспечивает возможность фрагментации дейтаграмм и, при использовании фрагментации, позволяет идентифицировать последний фрагмент дейтаграммы.

Поле смещение фрагмента (Fragment Offset) определяет положение фрагмента относительно исходной дейтаграммы в единицах, равных 8 октетам.

Поле время жизни (TTL - Time To Live) используется для ограничения времени, в течение которого дейтаграмма находится в сети. Каждый маршрутизатор сети должен уменьшать значение этого поля на единицу, и отбрасывать дейтаграмму, если поле TTL приняло нулевое значение. Наличие поля TTL ограничивает возможность бесконечной циркуляции дейтаграммы по сети, например, в случае, если по какой-либо причине маршрут, по которому она следует, оказался “закольцованным”.

Поле протокол (Protocol) идентифицирует протокол верхнего уровня (TCP, UDP и т.д.).

Поле контрольная сумма заголовка (Header Checksum) обеспечивает возможность контроля ошибок в заголовке. Алгоритм подсчета контрольной суммы весьма прост, поскольку обычно протоколы нижнего уровня имеют более развитые средства контроля ошибок.

IP-дейтаграммы содержат в заголовке два адреса - отправителя (Source) и получателя (Destination), которые не меняются на протяжении всей жизни дейтаграммы.

Подробнее структура и функции протокола IPv4 описаны в RFC-791.

4.6 Протокол IP версии 6

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


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

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

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

Комитет IETF намеревается решить существующие проблемы с помощью межсетевого протокола нового поколения - IPng, известного также как IPv6.

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

В результате было решено подвергнуть протокол IP модернизации, преследуя следующие основные цели:

• создание новой расширенной схемы адресации;

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

• обеспечение защиты данных.

Работы по модернизации протокола IP начались в 1992 году, когда было предложено несколько альтернативных вариантов спецификаций. С тех пор в рамках IETF была проделана огромная работа, в результате которой в августе 1998 года были приняты окончательные версии стандартов, определяющих как общую архитектуру IPv6 (RFC 2460 “Internet Protocol, Version 6 (IPv6) Specification”), так и отдельные компоненты данной технологии (RFC 2373 “IP Version 6 Addressing Architecture”).



Итак, рассмотрим более подробно особенности IPv6.

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

Вместо существующих двух уровней иерархии адреса (номер сети и номер узла) в протоколе IPv6 предлагается использовать четыре уровня, что предполагает трехуровневую идентификацию сетей и один уровень для идентификации узлов. За счет увеличения числа уровней иерархии в структуре адреса, новый протокол эффективно поддерживает технологию агрегации адресов (CIDR), которая упоминалась выше. Благодаря этой особенности, а также усовершенствованной системе групповой адресации и введению нового типа адресов (anycast), IPv6 позволяет уменьшить затраты ресурсов оборудования на маршрутизацию.

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

FEDC:OA96:0:0:0:0:7733:567A.

Для сетей, поддерживающих обе версии протокола - IPv4 и IPv6, -имеется возможность использовать для младших 4 байтов традиционную десятичную запись, а для старших - шестнадцатиричную:

0:0:0:0:0:FFFR 194.135.75.104.

Типы адресов. Для IPv6 определены следующие основные типы адресов:

• unicast;

• multicast;

• anycast.

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

Адрес типа unicast представляет собой уникальный идентификатор сетевого интерфейса рабочей станции или маршрутизатора и по смыслу полностью идентичен уникальному адресу IPv4.


Однако в версии 6 отсутствует понятие класса сети и фиксированное разбиение адреса на адрес сети и адрес узла по границам байтов.

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

Адрес типа anycast - новый тип адреса, определяющий, как и multicast, группу интерфейсов. Но пакет с таким адресом доставляется не всем членам группы, а какому-либо одному, как правило, “ближайшему” с точки зрения маршрутизатора. Такой адрес синтаксически никак не отличается от адреса типа unicast и выделяется из того же диапазона. Anycast-адрес может быть присвоен только сетевым интерфейсам маршрутизатора. Интерфейсам маршрутизатора будут присваиваться индивидуальные unicast-адреса и общий anycast-адрес. Адреса anycast ориентированы на определение маршрута узлом-отправителем. Например, у абонента есть возможность обеспечить прохождение своих пакетов через сеть конкретного поставщика, указав в цепочке адресов маршрута anycast-адрес, присвоенный всем маршрутизаторам в сети этого поставщика. В таком случае пакет будет передан на “ближайший” подходящий маршрутизатор именно этой сети.

В рамках системы адресации IPv6 имеется также выделенное пространство адресов для локального использования, т.е. для сетей, не входящих в Интернет. Существует две разновидности локальных адресов: для “плоских” сетей, не разделенных на подсети (Link-Local), и для сетей, разделенных на подсети (Site-Local), различающиеся значением префикса.



В настоящий момент распределено порядка 15% адресного пространства IPv6, что определяет широкие возможности развития сетей и приложений, их использующих.

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

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

Основной заголовок дейтаграммы IPv6 длиной 40 байтов имеет следующий формат (рис. 4.3).

Версия (4 бита)	Класс Трафика (8 битов)	Метка Потока (20 битов)
Длина (16 битов)	След.Заголовок (8 битов)	Лимит Переходов (8 битов)
Адрес Отправителя (128 битов)
Адрес Получателя (128 битов)

Рис. 4.3 Формат основного заголовка дейтаграммы IPv6

Поле Класс Трафика (Traffic Class) эквивалентно по назначению полю Тип Обслуживания (Type Of Service), а поле Лимит Переходов

(Hop Limit) - полю Время Жизни (Time To Live) протокола IPv4, рассмотренного в предыдущем параграфе.

Поле Метка Потока (Flow Label) позволяет выделять и особым образом обрабатывать отдельные потоки данных без необходимости анализировать содержимое пакетов. Это очень важно с точки зрения снижения нагрузки на маршрутизаторы.

Поле Следующий Заголовок (Next Header) является аналогом поля Протокол (Protocol) IPv4 и определяет тип заголовка, следующего за основным. Каждый следующий дополнительный заголовок также содержит поле Next Header. Если дополнительные заголовки отсутствуют, то это поле содержит значение, присвоенное тому из протоколов TCP, UDP, OSPF, который используется для переноса полезной нагрузки данной дейтаграммы.



В рамках спецификаций IPv6 определены заголовки следующих типов.

Заголовок Routing - содержит информацию о маршруте, выбранном отправителем дейтаграммы.

Заголовок Fragmentation -содержит информацию о фрагментации дейтаграммы и обрабатывается только конечными узлами сети.

Заголовок Authentication - содержит информацию, необходимую для проверки подлинности отправителя дейтаграммы.

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

Заголовок Hop-by-Hop Options - специальные параметры обработки пакетов.

Заголовок Destination Options - дополнительные параметры для узла назначения.

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

Дополнительные заголовки обрабатываются только конечными узлами и краевыми маршрутизаторам. Это упрощает логику работы маршрутизаторов и позволяет легче реализовать важные функции на аппаратном уровне.

Функции поддержки фрагментации переносятся в конечные узлы или краевые маршрутизаторы. Конечные узлы должны найти минимальный размер пакета вдоль всего пути до узла назначения (эта технология называется Path MTU discovery и уже используется для протокола IPv4) и не передавать пакеты с размером, превышающим найденное значение. Маршрутизаторы, поддерживающие протокол IPv6, в ядре сети могут не обеспечивать фрагментации, а только передавать сообщение протокола IСМР - “слишком длинный пакет” к конечному узлу, который должен соответственно уменьшить размер пакета.

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

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



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

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

• Установка на некоторых сетевых узлах сразу двух стеков протоколов, так что при взаимодействии с рабочими станциями, поддерживающими разные версии протокола, используется соответствующий стек протоколов TCP/IP. Маршрутизаторы могут в данном случае обрабатывать оба протокола независимо друг от друга.

• Конвертирование протоколов при помощи специальных шлюзов, которые преобразуют пакеты IPv4 в пакеты IPv6 и обратно. Важнейшая часть этого процесса - преобразование адресов. Для упрощения данной процедуры применяются так называемые “IРv4-совместимые адреса IPv6”, которые содержат в четырех младших байтах адрес, используемый в протоколе IPv4.

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

4.7 Протокол TCP

Протокол управления передачей информации - Transmission Control Protocol (TCP) - был разработан для поддержки интерактивной связи между компьютерами. Протокол TCP обеспечивает надежность и достоверность обмена данными между процессами на компьютерах, входящих в общую сеть.

К сожалению, протокол TCP не приспособлен для передачи мультимедийной информации.


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

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

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

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

Логическая структура сетевого программного обеспечения, реализующего протоколы семейства TCP/IP в каждом узле сети Internet, изображена на рис. 4.4.

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


Понимание этой логической структуры является основой для понимания всей технологии TCP/IP.

Рис. 4.4 Структура сетевого программного обеспечения стека протоколов TCP/IP


Ниже рассматриваются более подробно возможности, принципы построения и основные функции протокола TCP.

1 Потоки, стек протоколов, механизм портов и мультиплексирование

Чтобы установить соединение между двумя процессами на разных компьютерах сети, необходимо знать не только Internet-адреса компьютеров, но и номера тех ТСР-портов (sockets), которые процессы используют на этих компьютерах. Любое TCP-соединение в сети Internet однозначно идентифицируется двумя IP-адресами и двумя номерами ТСР-портов.

Рассмотрим потоки данных, перенос которых обеспечивают протоколы. При использовании протокола TCP данные передаются между прикладным процессом и модулем TCP. Типичным прикладным протоколом, использующим протокол TCP, является FTP (File Transfer Protocol, Протокол переноса файлов). Стек протоколов в этом случае выглядит следующим образом: FTP/TCP/IP/Ethernet. При использовании протокола UDP (User Datagram Protocol, Протокол дейтаграмм пользователя) данные передаются между прикладным процессом и модулем UDP. Транспортными услугами протокола UDP пользуется, например, SNMP (Simple Network Management Protocol, Простой протокол эксплуатационного управления сетью). Его стек протоколов выглядит так: SNMP/UDP/IP/ Ethernet.

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

Модули TCP, UDP и драйвер Ethernet являются мультиплексорами типа n x 1. Действуя как мультиплексоры, они переключают несколько входов на один выход. Они также являются демультиплексорами типа 1 х п. Как демультиплексоры, они переключают один вход на один из многих выходов в соответствии с определенным полем в заголовке протокольного блока данных (в Ethernet-кадре это поле “тип”).


Когда Ethernet-кадр попадает в драйвер сетевого интерфейса Ethernet, он может быть направлен либо в модуль ARP, либо в модуль IP. (Значение поля “тип” в заголовке кадра указывает, куда должен быть направлен Ethernet-кадр.)

Если IP-пакет попадает в модуль IP, то содержащиеся в нем данные могут быть переданы либо модулю TCP, либо UDP, что определяется полем “Protocol” в заголовке IP-пакета. Если TCP-сообщение попадает в модуль TCP, то выбор прикладной программы, которой должно быть передано сообщение, производится на основе значения поля “порт” в заголовке TCP-сообщения.

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

Назначение портов для приложений на каждом компьютере производится независимо. TCP может самостоятельно выбирать порт, с которым будет работать приложение, или приложение укажет, с каким портом на данном компьютере оно будет работать. Однако, как правило, часто используемые приложения-сервисы, например, такие как HTTP, FTP, SMTP и др., используют одни и те же номера портов, которые уже стали общеизвестными. Это делается для того, чтобы к данному процессу на компьютере можно было присоединиться, указывая только адрес машины. Например, lnternet-браузер, если ему не указать дополнительно, ищет по указанному адресу приложение, работающее с портом 80 (наиболее распространенный порт для серверов WWW). Кроме того, рабочая станция может быть снабжена несколькими сетевыми интерфейсами, тогда она должна осуществлять мультиплексирование типа n х т, т. е. между несколькими прикладными программами и несколькими интерфейсами.

4.7.2 Установление TCP-соединения и передача данных

Режим участия в установлении TCP-соединения может быть активным и пассивным. При пассивном участии рабочая станция ожидает сигнал открытия ТСР-канала от встречного оборудования и не пытается открыть ТСР-канал сама.


Этот режим обычно используется процессами, которые предоставляют свой сервис через общеизвестный номер своего порта (например, HTTP, SMTP и т. д.). При активном режиме участия рабочая станция сама инициирует открытие ТСР-канала. Соединение будет также установлено, если два процесса активно откроют канал навстречу друг другу. Такая гибкость в установлении соединения особенно важна в распределенных сетях, когда компьютеры работают асинхронно.

Процедура установления TCP-соединения выглядит следующим образом. Рабочая станция, инициирующая открытие ТСР-канала, передает пакет с флагом SYN, в котором указывается номер порта и начальный порядковый номер пакетов данных. Встречная станция передает на указанный адрес ответ с флагами SYN и АСК, в котором указывается начальный порядковый номер пакетов данных. Сторона, инициирующая установление TCP-соединения, подтверждает получение пакета с флагами SYN и АСК передачей пакета с установленным флагом АСК.

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

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

4.7.3 Механизмы обеспечения достоверности

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

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


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

При передаче информации каждому байту данных присваивается порядковый номер, поэтому, в какой бы последовательности эти байты ни достигали точки назначения, они всегда будут собраны в изначальной последовательности. Порядковый номер первого байта данных в передаваемом сегменте называется порядковым номером сегмента. Нумерация проводится “с головы состава”, т. е. от заголовка пакета. TCP-пакет содержит также “подтверждающий номер” (acknowledgment number), который представляет собой номер следующего ожидаемого пакета. Иными словами, подтверждающий номер означает: “до сих пор я все получил”. Механизм с использованием “подтверждающего номера” исключает дублирование пакетов при повторной отправке не доставленных данных.

Кроме определения порядка следования информационных пакетов, “порядковый номер” играет важную роль в механизме синхронизации соединения и в контроле потерянных пакетов при разрывах соединения.

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

Так, при установлении нового соединения генерируется 32-битовое число ISN (Initial Sequence Number). Генератор может использовать 32 младших разряда машинного таймера, который меняется каждые 4 микросекунды (полный цикл - 4,55 часа).


Это число и служит отсчетом нумератора пакетов. Кроме того, каждая дейтаграмма в сети имеет ограниченное время жизни MSL - Maximum Life Time, которое значительно меньше периода генератора. Таким образом, в сети гарантируется невозможность появления пакетов с одинаковыми номерами.

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

4.7.4 Механизм управления потоком данных

Протокол TCP предоставляет получателю пакетов возможность регулировать передаваемый к нему отправителем поток данных. Этот механизм основан на том, что при передаче флага подтверждения получения пакета (АСК) в ТСР-сегменте передается указатель объема данных (так называемое “окно” TCP-соединения), которые могут быть переданы отправителем, не дожидаясь от получателя разрешения отправить следующую порцию данных. Иными словами, указывается размер свободного места в буферном накопителе, куда записываются только что принятые данные, ожидающие дальнейшей обработки и передачи соответствующим процессам. Этот механизм позволяет избежать “пробок” при обмене данными между системами, обладающими разной производительностью.

“Окно” задается количеством байтов, отсчитываемых от последнего подтвержденного байта (acknowledgment number). Нулевой размер окна означает, что отправитель должен приостановить передачу до тех пор, пока он не будет уведомлен о готовности получателя к приему данных. Необходимо заметить, что в этом случае отправитель передает однобайтовые пакеты.

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

Механизм управления потоком данных позволяет протоколу TCP оптимизировать скорость достоверного обмена данными между процессами в сети Интернет.



4.7.5 Состав и назначение полей заголовка

Пакеты протокола TCP переносятся в поле “Данные” IP-дейтаграммы. Заголовок пакета TCP следует за заголовком дейтаграммы. Структура заголовка пакета TCP представлена на рис. 4.5.

Порт отправителя	Порт получателя
Порядковый номер
Номер при подтверждении
Смещение данных	Резерв	U R G	А С К	Р S Н	R S Т	S Y N	FIN	Окно
Контрольная сумма	Указатель срочности
Опции | Заполнение
Данные

Рис. 4.5 Заголовок пакета TCP Порт отправителя (Source Port, 6 битов). Порт получателя (Destination Port, 16 битов).


Порядковый номер (Sequence Number, 32 бита). Если в пакете отсутствует флаг SYN, то это - номер первого октета данных в этом пакете. Если флаг SYN в пакете присутствует, то номер данного пакета становится номером начала последовательности (ISN), и номером первого октета данных становится номер ISN+1.

Номер при подтверждении (Acknowledgment Number, 32 бита) -если пакет содержит установленный флаг АСК, то это поле содержит номер следующего ожидаемого получателем октета данных. При установленном соединении пакет подтверждения отправляется всегда.

Поле величины смещения данных (Data Offset,4 бита) указывает количество 32-битовых слов заголовка TCP-пакета.

Резерв (Reserved, 6 битов) - зарезервированное поле. Флаги управления (слева направо):

URG - флаг срочности,

АСК - флаг пакета, содержащего подтверждение получения,

PSH - флаг форсированной отправки,

RST - сброс соединения,

SYN - синхронизация порядковых номеров,

FIN - флаг окончания передачи со стороны отправителя.

Окно (Window, 16 битов) - поле содержит количество байтов данных, которое отправитель данного сегмента может принять, считая от байта с номером, указанным в поле Номер при подтверждении.

Поле контрольной суммы (Checksum, 16 битов).

Поле указателя срочности данных (Urgent Pointer, 16 битов). Это поле содержит номер пакета, начиная с которого следуют пакеты повышенной срочности. Указатель принимается во внимание только в сегментах с установленным флагом URG.



Опции (Options) - поле дополнительных параметров, может быть переменной длины.

Заполнение (Padding) - поле, заполняемое нулями для выравнивания заголовка до размера, кратного 32-битам.

Более подробное описание протокола TCP можно найти в RFC-793, RFC-1180.

4.8 Протокол UDP

Протокол передачи пользовательских дейтаграмм - User Datagram Protocol (UDP) значительно проще рассмотренного в предыдущем параграфе протокола TCP и предназначается для обмена дейтаграммами между процессами компьютеров, расположенных в объединенной системе компьютерных сетей.

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

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

К заголовку IP-пакета протокол UDP добавляет служебную информацию в виде заголовка UDP-пакета (рис. 4.6).

Порт отправителя		Порт получателя
Длина		Контрольная сумма
Данные
…

Рис. 4.6 Формат UDP-пакета

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

Порт получателя (Destination Port) - поле идентифицирует порт рабочей станции, на которую будет доставлен пакет.

Длина (Length) - это поле информирует о длине UDP-пакета в октетах, включая как заголовок, так и данные. Минимальное значение длины равно восьми.

Контрольная сумма (Checksum) - поле проверки правильности передачи данных заголовка пакета, псевдозаголовка и поля полезной нагрузки пакета. Если данное поле не используется, оно заполняется нулями.

Модуль IP, реализованный в принимающей рабочей станции, передает поступающий из сети IP-пакет модулю UDP, если в заголовке этого пакета указано, что протоколом верхнего уровня является протокол UDP.При получении пакета от модуля IP модуль UDP проверяет контрольную сумму, содержащуюся в его заголовке. Если контрольная сумма равна нулю, значит, отправитель ее не подсчитал. Протоколы UDP и TCP имеют один и тот же алгоритм вычисления контрольной суммы (RFC-1071), но механизм ее вычисления для UDP-пакета имеет некоторые особенности. В частности, UDP-дейтаграмма может содержать нечетное число байтов, и в этом случае к ней, для унификации алгоритма, добавляется нулевой байт, который никуда не пересылается.

Более подробную информацию о протоколе UDP можно найти в RFC-768.

Алгоритмы установления соединения

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

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

7.6.1 Установление соединения с участием сервера переадресации

В этом параграфе описан алгоритм установления соединения с участием сервера переадресации вызовов. Администратор сети сообщает пользователям адрес сервера переадресации. Вызывающий пользователь передает запрос INVITE (1) на известный ему адрес сервера переадресации и порт 5060, используемый по умолчанию (Рисунок 7.9). В запросе вызывающий пользователь указывает адрес вызываемого пользователя. Сервер переадресации запрашивает текущий адрес нужного пользователя у сервера определения местоположения (2), который сообщает ему этот адрес (3). Сервер переадресации в ответе 302 Moved temporarily передает вызывающей стороне текущий адрес вызываемого пользователя (4), или он может сообщить список зарегистрированных адресов вызываемого пользователя и предложить вызывающему пользователю самому выбрать один из них.
Вызывающая сторона подтверждает прием ответа 302 посылкой сообщения АСК (5).

Рис. 7.9 Сценарий установления соединения через сервер переадресации

Теперь вызывающая сторона может связаться непосредственно с вызываемой стороной. Для этого она передает новый запрос INVITE (6) с тем же идентификатором Call-ID, но другим номером CSeq. В теле сообщения INVITE указываются данные о функциональных возможностях вызывающей стороны в формате протокола SDP. Вызываемая сторона принимает запрос INVITE и начинает его обработку, о чем сообщает ответом 100 Trying (7) встречному оборудованию для перезапуска его таймеров. После завершения обработки поступившего запроса оборудование вызываемой стороны сообщает своему пользователю о входящем вызове, а встречной стороне передает ответ 180 Ringing (8). После приема вызываемым пользователем входящего вызова удаленной стороне передается сообщение 200 OK (9), в котором содержатся данные о функциональных возможностях вызываемого терминала в формате протокола SDP. Терминал вызывающего пользователя подтверждает прием ответа запросом АСК (10). На этом фаза установления соединения закончена и начинается разговорная фаза.

По завершении разговорной фазы любой из сторон передается запрос BYE (11), который подтверждается ответом 200 OK (12).

7.6.2. Установление соединения с участием прокси-сервера

В этом параграфе описан алгоритм установления соединения с участием прокси-сервера. Администратор сети сообщает адрес

этого сервера пользователям. Вызывающий пользователь передает запрос INVITE (1) на адрес прокси-сервера и порт 5060, используемый по умолчанию (Рисунок 7.10). В запросе пользователь указывает известный ему адрес вызываемого пользователя. Прокси-сервер запрашивает текущий адрес вызываемого пользователя у сервера определения местоположения (2), который и сообщает ему этот адрес (3). Далее прокси-сервер передает запрос INVITE непосредственно вызываемому оборудованию (4). Опять в запросе содержатся данные о функциональных возможностях вызывающего терминала, но при этом в запрос добавляется поле Via с адресом прокси-сервера для того, чтобы ответы на обратном пути шли через него.


После приема и обработки запроса вызываемое оборудование сообщает своему пользователю о входящем вызове, а встречной стороне передает ответ 180 Ringing (5), копируя в него из запроса поля То, From, Call-ID, CSeq и Via. После приема вызова пользователем встречной стороне передается сообщение 200 OK (6), содержащее данные о функциональных возможностях вызываемого терминала в формате протокола SDP. Терминал вызывающего пользователя подтверждает прием ответа запросом АСК (7). На этом фаза установления соединения закончена и начинается разговорная фаза.

По завершении разговорной фазы одной из сторон передается запрос BYE (8), который подтверждается ответом 200 OK (9).

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

Рис. 7.10 Сценарий установления соединения через прокси-сервер

Реализация дополнительных услуг на базе протокола SIP

В этом параграфе рассматриваются примеры реализация дополнительных услуг на базе протокола SIP.

Дополнительная услуга “Переключение связи” позволяет пользователю переключить установленное соединение к третьей стороне. На рисунке 7.11 приведен пример реализации этой услуги. Пользователь В устанавливает связь с пользователем А, который, переговорив с В, переключает эту связь к пользователю С, а сам отключается.

Рис. 7.11 Дополнительная услуга "Переключение связи"

Дополнительная услуга “Переадресация вызова” позволяет пользователю назначить адрес, на который, при определенных условиях, следует направлять входящие к нему вызовы. Такими условиями могут быть занятость пользователя, отсутствие его ответа в течение заданного времени или и то, и другое; возможна также безусловная переадресация. Оборудование пользователя, заказавшего эту услугу, получив сообщение INVITE В, проверяет условия, в которых оно получено, и если условия требуют переадресации, передает сообщение INVITE с заголовком Also, указывая в нем адрес пользователя, к которому следует направить вызов. Терминал вызывающего пользователя, получив сообщение INVITE с таким заголовком, инициирует новый вызов по адресу, указанному в поле Also.


В нашем случае пользователь А вызывает пользователя В, а терминал последнего переадресует вызов к пользователю С (Рисунок 7.12).

Дополнительная услуга “Уведомление о вызове во время связи” позволяет пользователю, участвующему в телефонном разговоре, получить уведомление о том, что к нему поступил входящий вызов (Рисунок 7.13).

Рис. 7.12 Дополнительная услуга "Переадресация вызова"


Рис. 7.13 Дополнительная услуга "Уведомление о вызове во время связи"

Услуга реализуется с помощью заголовка Call-Disposition, в котором содержится инструкция по обслуживанию вызова. Вызывающий пользователь передает запрос INVITE с заголовком Call-Disposition: Queue, который интерпретируется следующим образом: вызывающий пользователь хочет, чтобы вызов был поставлен в очередь, если вызываемый пользователь будет занят. Вызываемая сторона подтверждает исполнение запроса ответом 182 Queued, который может передаваться неоднократно в течение периода ожидания. Вызываемый пользователь получает уведомление о входящем вызове, а когда он освобождается, вызывающей стороне передается финальный ответ 200 ОК.

Аннотация

Успехи IP-телефонии являются сегодня наиболее наглядным доказательством необходимости и неизбежности конвергенции сетей и услуг связи. Книга посвящена этой новой и перспективной технологии. Рассматриваются системно-сетевые аспекты IP-телефонии, методы и алгоритмы кодирования речевой информации, основные подходы и протоколы Н.323, SIP, MGCP, MEGACO, вопросы качества обслуживания QoS, аспекты реализации оборудования IP-телефонии и его тестирования.

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

УДК 621.395.34
Г63
ББК 32.881
Гольдштейн B.C., Пинчук А.В., СуховицкийА.Л.
IP-Телефония. — М.: Радио и связь, 2001. — 336с.: ил.
Г63
ISBN 5-256-01585-0

Научно-техническое издание
ИБ № 3003 ISBN 5-256-01585-0

© Гольдштейн B.C., ПинчукА.В., СуховицкийА.Л., 2001

B.S. Goldstein, A.V. PintchukandA.L. Souhovitsky
IP-Telephony, Moscow, Radio i Sviaz, 2001.
The success of IP-telephony is today the most clear proof of the necessity and inevitability of the convergence of the telecommunication networks and services. The book is devoted to this new and promising technology. Discussed here are system and networking aspects of IP-telephony, voice coding methods and algorithms, Н.323, SIP, MGCP, and MEGACO basic approaches and protocols, Quality of Service (QoS) issues, IP telephony equipment implementation and testing aspects.
The book is primarily intended for engineers, programmers, managers, and professionals involved in the development and maintenance of IP-telephony systems and facilities. For college students and post-graduates studying in these areas. For all those who are interested in state-of-the-art telecommunications technologies.
Scientific and technical edition

Copyright © B.S. Goldstein, A.V. PintchukandA.L. Souhovitsky, 2001

в себя три основных протокола:

Семейство протоколов Н.323 включает в себя три основных протокола: протокол взаимодействия оконечного оборудования с привратником - RAS, протокол управления соединениями - Н.225 и протокол управления логическими каналами - Н.245.

Эти три протокола, совместно с Интернет-протоколами TCP/IP, UDP, RTP и RTCP, а также с описанным в [6] протоколом Q.931, представлены на рис.6.1. Суть изображенной на этом рисунке иерархии заключается в следующем. Для переноса сигнальных сообщений Н.225 и управляющих сообщений Н.245 используется протокол с уcтановлением соединения и с гарантированной доставкой информации - TCP. Сигнальные сообщения RAS переносятся протоколом с негарантированной доставкой информации - UDP. Для переноса речевой и видеоинформации используется протокол передачи информации в реальном времени - RTP. Контроль переноса пользовательской информации производится протоколом RTCP.

С учетом того, что стек протоколов TCP/IP и протоколы UDP, RTP и RTCP уже рассматривались в главе 4, материал данной главы будет посвящен протоколам RAS, Н.225 и Н.245. Степень детализации их рассмотрения определяется конечной целью - изложению сценария базового процесса обслуживания вызова, в упрощенном виде уже упоминавшегося в главах 1 и 2.

Таблица. 6.1 Семейство протоколов Н.323

Гарантированная доставка информации по протоколу TCP	Негарантированная доставка информации по протоколу UDP
Н.245	Н.225	Потоки речи и видеоинформации
Управление соединением (Q.931)	RAS	RTCP	RTP
TCP	UDP
IP
Канальный уровень
Физический уровень

6.2 Протокол RAS

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

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

1. Обнаружение привратника.



2. Регистрация оконечного оборудования у привратника.
3. Контроль доступа оконечного оборудования к сетевым ресурсам.
4. Определение местоположения оконечного оборудования в сети.
5. Изменение полосы пропускания в процессе обслуживания вызова.
6. Опрос и индикация текущего состояния оконечного оборудования.
7. Оповещение привратника об освобождении полосы пропускания, ранее занимавшейся оборудованием.
Выполнение первых трех процедур, предусмотренных протоколом RAS, является начальной фазой установления соединения с использованием сигнализации Н.323. Далее следуют фаза сигнализации Н.225.0 (Q.931) и обмен управляющими сообщениями Н.245. Разъединение происходит в обратной последовательности: в первую очередь закрывается управляющий канал Н.245 и сигнальный канал Н.225.0, после чего по каналу RAS привратник оповещается об освобождении ранее занимавшейся оконечным оборудованием полосы пропускания.
Для переноса сообщений протокола RAS используется протокол негарантированной доставки информации UDP. В связи с этим ITU-T рекомендовал передавать повторно те сообщения RAS, получение которых не было подтверждено в течение установленного промежутка времени. Оконечное оборудование или привратник, не имеющие возможности в текущий момент времени ответить на полученный запрос, могут передавать сообщение RIP (Request in Progress) для индикации того, что запрос находится в стадии обработки. При приеме сообщения RIP привратник и оконечное оборудование должны перезапустить свои таймеры.
Важно отметить, что в сети без привратника сигнальный канал RAS вообще не используется.
6.2.1 Обнаружение привратника
Для взаимодействия оконечного оборудования с привратником нужно, чтобы устройству стал известен сетевой адрес подходящего привратника. Процесс определения этого адреса называется обнаружением привратника. Определены два способа обнаружения - ручной и автоматический.
Ручной способ заключается в том, что привратник, обслуживающий данное устройство, определяется заранее при конфигурации этого устройства.


Первая фаза установления соединения начинается сразу с запроса регистрации устройства, который передается на уже известный сетевой адрес привратника и на UDP-порт 1719, а в случае взаимодействия с привратником, поддерживающим первую версию протокола Н.323, - на порт 1718.
При автоматическом способе обнаружения привратника устройство передает запрос Gatekeeper Request (GRQ) в режиме многоадресной рассылки (multicasting), используя IP-адрес 224.0.1.41 - Gatekeeper UDP Discovery Multicast Address - и UDP порт 1718 - Gatekeeper UDP Discovery Port. Ответить оконечному оборудованию могут один или несколько привратников, передав на адрес, указанный в поле rasAddress запроса GRQ, сообщение Gatekeeper Confirmation (GCF) с предложением своих услуг и с указанием транспортного адреса канала RAS (рис.6.2.). Если привратник не имеет возможности зарегистрировать оконечное оборудование, он отвечает на запрос сообщением Gatekeeper Reject (GRJ).
Если на GRQ отвечает несколько привратников, оконечное оборудование может выбрать по своему усмотрению любой из них, после чего инициировать процесс регистрации. Если в течение 5 секунд ни один привратник не ответит на GRQ, оконечное оборудование может повторить запрос. Если ответ опять не будет получен, необходимо прибегнуть к ручному способу обнаружения привратника.

Рис. 6.2 Автоматическое обнаружение привратника

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


В то же время, следует сказать о том, что режим многоадресной рассылки в IP-сетях не очень распространен, поэтому, скорее всего, автоматическое обнаружение привратника найдет применение только в корпоративных сетях. Следует также отметить, что привратник должен уметь принимать и обрабатывать множество запросов от одного и того же оборудования, так как процедура обнаружения может периодически повторяться, например, при включении питания или при входе в сеть.
6.2.2 Регистрация оконечного оборудования
После выполнения процедуры обнаружения привратника оконечное оборудование должно быть присоединено к зоне сети, обслуживаемой данным привратником. Для этого оборудование должно сообщить привратнику свою адресную информацию: список alias-адресов и транспортных адресов. Этот процесс называется регистрацией оконечного оборудования у привратника.
В предыдущей главе уже упоминалось, что если в качестве оконечного оборудования выступают шлюз или устройство управления конференциями, то они могут зарегистрировать у привратника несколько транспортных адресов для каналов сигнализации RAS и Н.225.0 (Q.931). Кроме того, для повышения надежности работы сети оконечному оборудованию разрешается иметь дополнительные транспортные адреса, что дает возможность иметь в одном оборудовании два сетевых интерфейса или предусматривать дублирующее оборудование. Дополнительные транспортные адреса указываются в параметре alternateEndpoint некоторых сообщений сигнализации RAS.
Процесс регистрации представлен на рис.6.3. Оконечное оборудование передает запрос регистрации Registration Request (RRQ) на сетевой адрес привратника, либо полученный при выполнении процедуры его автоматического обнаружения, либо известный априори. Стоит отметить, что запрос направляется на общеизвестный номер UDP-порта 1719. Этот порт имеет соответствующее название - Gatekeeper UDP Registration and Status Port. Привратник отвечает на запрос подтверждением Registration Confirmation (RCF) или отказом в регистрации Registration Reject (RRJ).


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

Если оконечное оборудование не указывает свой alias-адрес в запросе RRQ, привратник может сам назначить такой адрес и вернуть его в сообщении RCF.
Регистрация оконечного оборудования должна быть проведена перед началом установления первого соединения с любым другим оборудованием. Этот процесс может периодически повторяться, например, при включении питания оборудования, поэтому привратник должен уметь обрабатывать множество запросов регистрации от одного и того же оборудования.
Если привратник получает запрос RRQ, содержащий те же самые alias-адрес и транспортный адреса оконечного оборудования, что и в предыдущем RRQ, он должен ответить подтверждением RCF. Если привратник получает запрос RRQ с тем же, что и в предыдущем RRQ, alias-адресом, но с другим транспортным адресом, он может либо подтвердить регистрацию, либо отказать в ней, в зависимости от внутренней политики сети. При приеме запроса RRQ, содержащего тот же, что и предыдущий RRQ, транспортный адрес, но другой alias-адрес оборудования, привратник должен закрепить за принятым транспортным адресом тот alias-адрес, который был принят последним, и подтвердить запрос. Заметим, что привратник может проверять наличие права пользователей на проведение вышеуказанных изменений.
Оконечное оборудование может регистрироваться на определенный промежуток времени, указывая в параметре timeToLive сообщения RRQ длительность этого промежутка в секундах. Привратник может подтвердить регистрацию сообщением RCF с параметром timeToLive, имеющим то же или меньшее значение.
В течение указанного промежутка времени оконечное оборудование может продлить регистрацию, передав сообщение RRQ с параметром keepAlive. Получив это сообщение, привратник должен перезапустить таймер.
По истечении назначенного промежутка времени регистрация считается недействительной. В этом случае привратник может передать сообщение об отмене регистрации, и оконечное оборудование должно пройти повторную регистрацию.


Оконечное оборудование может отменить регистрацию у привратника, передав сообщение Unregister Request (URQ); привратник должен ответить подтверждением Unregister Confirmation (UCF). Такая процедура позволяет оборудованию изменить свой alias-адрес или транспортный адрес. Если оборудование не было зарегистрировано у привратника, последний должен ответить на требование URQ отказом Unregister Reject (URJ).
Привратник может отменить регистрацию оборудования, передав сообщение Unregister Request (URQ), при получении которого оконечное оборудование должно ответить подтверждением Unregister Confirmation (UCF). Теперь, чтобы получить возможность участия в любом соединении, оконечное оборудование должно перерегистрироваться у того же привратника или зарегистрироваться у нового.
Оборудование, не зарегистрированное у привратника, не может требовать от него допуск к участию в любых соединениях. Привратник не выполняет для этого оборудования такие функции как управление полосой пропускания, преобразование адресов и другие предусмотренные рекомендацией Н.323 функции. Кроме того. привратник может запретить оконечному оборудованию своей зоны принимать вызовы от оборудования, которое у него не зарегистрировано.
6.2.3 Доступ к сетевым ресурсам
В начальной фазе установления соединения, а также после получения запроса соединения (сообщения Setup), оборудование обращается к привратнику при помощи запроса Admission Request (ARQ) с просьбой разрешить соединение с другим оборудованием (рис. 6.4), что является началом процедуры доступа к сетевым ресурсам. Важно отметить, что процедура доступа выполняется всеми участниками соединения.
В сообщении ARQ обязательно содержится идентификатор оборудования, пославшего сообщение ARQ, и контактная информация того оборудования, с которым желает связаться оборудование, пославшее сообщение ARQ. Контактная информация оборудования включает в себя alias-адрес и/или транспортный адрес сигнального канала, но, как правило, в запрос ARQ помещается только alias-адрес вызываемого оборудования.


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

Рис. 6.4 Управление доступом к сетевым ресурсам
Как показано в примере на рис.6.4, привратник может выделить требуемую полосу пропускания или снизить предел суммарной скорости, передав сообщение Admission Confirm (ACF). В этом же сообщении, кроме суммарной скорости, указывается транспортный адрес сигнального канала встречного оборудования, если сигнальный канал будет организован непосредственно между тем и другим оборудованием, или адрес привратника, если он будет маршрутизировать сигнальные сообщения.
Если процедура доступа инициируется вызывающим оборудованием, то после получения ответа ACF, на указанный в этом сообщении адрес передается сообщение Setup и делается попытка установить сигнальное соединение Н.225.0. Следует отметить, что инициирование процедуры доступа к сетевым ресурсам вызываемым оборудованием начинается уже после установления сигнального канала и получения по нему сообщения Setup.
Если требуемая полоса недоступна, привратник передает сообщение Admission Reject (ARJ).
6.2.4 Определение местоположения оборудования в сети
Оконечное оборудование или привратник, которые имеют alias-адрес некоторого оборудования и желают узнать его контактную информацию (адреса сигнального канала и канала RAS), могут послать запрос Location Request (LRQ) по адресу канала RAS отдельно взятого привратника или по общему адресу всех привратников (режим Gatekeeper's Discovery Multicast). Привратник, у которого зарегистрировано указанное оборудование, должен ответить сообщением Location Confirmation (LCF), содержащим требуемую контактную информацию.


Эта процедура называется определением местоположения оконечного оборудования в сети (рис.6.5).
Рис. 6.5 Определение местоположения оборудования в сети

Привратник, получивший на транспортный адрес своего канала RAS запрос LRQ, должен ответить отказом Location Reject (LRJ), если искомое оборудование у него не зарегистрировано. Те же привратники, у которых искомое оборудование не зарегистрировано, а сообщение LRQ было получено в режиме многоадресной рассылки Gatekeeper's Discovery Multicast, вообще не должны отвечать на запрос.
Вышеописанная процедура используется, в частности, тогда, когда в сети имеется несколько зон и вызов выходит за пределы одной зоны. Привратник, у которого зарегистрировано вызывающее оборудование, передает запрос адреса сигнального канала вызываемого оборудования.
Кроме того, оконечное оборудование или привратник могут передавать в поле destinationlnfo запроса LRQ номер абонента ТфОП в формате Е.164 с целью определить местонахождение шлюза, посредством которого может быть установлено соединение.
6.2.5 Изменение полосы пропускания
В процессе обслуживания вызова оконечное оборудование или привратник могут предпринять попытку изменить в ту или иную сторону суммарную скорость передачи информации. Данная процедура называется изменением полосы пропускания.
Оконечное оборудование может изменять суммарную скорость, не обращаясь за разрешением к привратнику, если после этого изменения средняя суммарная скорость не превысит предела, определенного при получении доступа к сетевым ресурсам.
Оконечное оборудование, которому нужно превысить указанный предел, должно передать привратнику запрос Bandwidth Change Request (BRQ), но до получения ответа средняя суммарная скорость должна быть не выше этого предела. Если привратник может выделить требуемую полосу пропускания, он отвечает сообщением Bandwidth Change Confirm (BCF). Далее речевые и видеоканалы закрываются, а затем при помощи управляющих сообщений Н.245 открываются каналы с новой скоростью передачи и приема информации.


Если же привратник по каким- либо причинам не может удовлетворить требование оборудования, он отклоняет это требование и передает сообщение Bandwidth Change Reject (BRJ). Сценарий процедуры представлен на рис.6.6.

Рис. 6.6 Изменение полосы пропускания в процессе обслуживания вызова
В процессе обслуживания вызова привратник может изменить в ту или иную сторону выделенную оборудованию полосу пропускания, передав сообщение BRQ. Если это требование предписывает снизить скорость, оконечное оборудование обязано подчиниться, т.е. передать подтверждение BCF и переустановить логические каналы.

Если сообщением BRQ привратник предлагает увеличить скорость, то решение принять или не принимать это предложение остается за оконечным оборудованием.
6.2.6 Опрос текущего состояния оборудования
Привратник в любой момент времени может определить текущее состояние оборудования, т.е. установить, доступно ли ему это оборудование. Данный процесс называется опросом текущего состояния оборудования (рис.6.7). Очевидно, что если питание оборудования выключено, или если в его работе возникла какая-либо неисправность, то оборудование становится недоступным.
Рис. 6.7 Опрос текущего состояния оборудования

Запрос информации о текущем состоянии (статусе) оборудования производится привратником при помощи сообщения Information Request (IRQ). Интервал между посылками IRQ оставлен на усмотрение производителя, но должен быть не меньше 10с. Получив запрос IRQ, оконечное оборудование должно передать запрашиваемую информацию в сообщении Information Request Response (IRR).
Привратник может дать оконечному оборудованию предписание передавать сообщения IRR без запросов с его стороны. Для этого привратник использует сообщение ACF, в поле irrFrequency которого указывается частота, с какой оконечное оборудование должно выдавать информацию о своем текущем состоянии. Получив такое предписание, оконечное оборудование должно передавать сообщения IRR с указанной частотой в течение всего времени обслуживания вызова, причем привратник может запрашивать дополнительную информацию, используя сообщения IRQ, как было описано выше.


Оконечное оборудование, желающее убедиться в том, что сообщения IRR, посылаемые без предварительных запросов со стороны привратника, достигают адресата, может требовать от привратника подтверждений получения сообщений IRR. Наличие поля willRe-spondToIRR в сообщениях RCF или ACF, получаемых от привратника, означает его согласие удовлетворить данное требование. Привратник может подтверждать получение сообщения IRR сообщением IACK или сообщать о потере или задержке сообщения IRR с помощью сообщения INAK. Оба сообщения IACK и INAK используются, когда сообщения IRR переданы (привратникам версии 2 или выше) с полем needResponse, которому присвоено значение TRUE.
Существует еще один вариант использования сообщений IRR. Привратник может потребовать от оконечного оборудования присылать копии всех или некоторых сигнальных сообщений, передаваемых и принимаемых этим оборудованием. Если оборудование может удовлетворить данное требование, оно передает запрашиваемую информацию в сообщениях IRR сразу же после того, как получит или отправит сигнальное сообщение.
6.2.7 Освобождение полосы пропускания
Как уже упоминалось ранее, процедура завершения соединения выглядит следующим образом: сначала закрываются логические каналы, затем управляющий и сигнальный каналы. В конечной фазе завершения соединения оборудование извещает привратник об освобождении раннее занимавшейся полосы пропускания (рис.6.8). Оконечное оборудование передает своему привратнику сообщение Disengage Request (DRQ), на которое тот должен ответить подтверждением Disengage Confirm (DCF). Следует отметить, что после того, как полоса пропускания освобождена, оконечное оборудование не должно передавать незапрашиваемые сообщения IRR.
Рис. 6.8 Освобождение полосы пропускания

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


В случае, если привратник инициирует завершение конференции, сообщение DRQ должно передаваться каждому ее участнику.
6.2.8 Метка доступа
Метка доступа передается в некоторых сообщениях сигнализации RAS и в сообщении Setup, причем имеются два основных варианта ее использования.
Первый вариант служит для сокрытия транспортного адреса и alias-адреса оконечного оборудования. Пользователь, желающий сохранить в тайне свои адреса, сообщает каким-либо образом вызывающему пользователю метку доступа, о наличии которой привратник заранее оповещен в процессе регистрации. Вызывающий абонент использует метку доступа для установления соединения с вызываемым абонентом, причем сигнальные каналы непременно должны проходить через привратник, который маршрутизирует сигнальные сообщения от одного абонента к другому.
Во втором варианте использования метки доступа она назначается привратником и должна передаваться во всех сообщениях, служащих для установления соединения. Примером такого использования метки доступа может служить установление соединения со шлюзом. По наличию метки шлюз определяет, что устанавливать соединение с его участием абоненту разрешено.
В заключение этого параграфа приведем итоговую таблицу (табл. 6.1) сообщений протокола RAS, рассмотренных выше. В этой и следующих аналогичных таблицах для удобства читателей, работающих также с рекомендациями ITU-T, используются следующие обозначения: О (options) - необязательное, М (mandatory) - обязательное.
Таблица 6.1 Сообщения RAS

Сообщение RAS	Передача оконечным оборудованием	Приём оконечным оборудованием	Передача привратником	Приём привратником	Примечания
GRQ	0			М	Gatekeeper Request (Запрос привратника) Любой привратник, принявший это сообщение, должен на него ответить
GCF		0	М		Gatekeeper Confirm (Подтверждение привратника) Привратник идентифицирует себя
GRJ		0	М		Gatekeeper Reject (Отказ привратника) Указывается причина
RRQ	М			М	Registration Request (Запрос регистрации)
RCF		М	М		Registration Confirm (Подтверждение регистрации)
RRJ		М	М		Registration Reject (Отказ в регистрации) Указывается причина
URQ	0	М	0	М	Unregistratton Request (Запрос отмены регистрации) Терминал желает отменить регистрацию у привратника
UCF	M	0	M	0	Unregistration Confirm (Регистрация отменена)
URJ	0	0	M	0	Unregistration Reject (Отказ в отмене регистрации) Указывается причина.
ARQ	M			M	Admission Request (Запрос доступа)
ACF		M	M		Admission Confirm (Подтверждение доступа)
ARJ		M	M		Admission Reject (Отказ в доступе) Указывается причина
BRQ	M	M	0	M	Bandwidth Request (Запрос изменения полосы пропускания)
BCF	M	M	M	0	Bandwidth Confirm (Подтверждение изменения полосы пропускания)
BRJ	M	M	M	0	Bandwidth Reject (Отказ в предоставлении полосы) Указывается причина
IRQ		M	M		Information Request (Запрос информации)
IRR	M			M	Information Response (Ответ на запрос информации)
IACK		0	Условное		InfoRequestAck (Подтверждение получения сообщения IRR)
INAK		0	Условное		InfoRequestNak (Индикация потери или задержки сообщения IRR)
DRQ	M	M	0	M	Disengage Request (Запрос разъединения). Информирует привратник, что оконечное оборудование освобождает ранее занимавшуюся полосу пропускания, или оборудование о том, что ему необходимо освободить занимаемую полосу пропускания
DCF	M	M	M	M	Disengage Confirm (Подтверждение получения сообщения DRQ)
DRJ	M	M	M	M	Disengage Reject (Отклонение запроса/разъединения) Передаётся привратником, если оконечное оборудование не было зарегистрировано у данного привратника
LRQ	0		0	M	Location Request (Запрос местоположения) Запрос предоставления транспортного адреса оконечного оборудования
LCF		0	M	0	Location Confirm (Сообщение о местоположении оборудования) Сообщается транспортный адрес искомого оконечного оборудования
LRJ		0	M	0	Location Reject (Отказ дать сведения о местоположении оборудования) Указывается причина, вероятнее всего -"искомое оборудование не зарегистрировано у привратника"
NSM	0	0	0	0	Non-Standard Message (Нестандартное сообщение) Передаются данные, не специфицированные в рекомендации Н. 225.0
XRS	M	M	M	M	Unknown Message Response (Ответ на неизвестное сообщение) Передаётся оконечным оборудованием всякий раз, когда оно получает нераспознанное сообщение
RIP	Условное	M	Условное	M	Request in Progress (Запрос обрабатывается) Передаётся оконечным оборудованием, если ответ на сообщение не может быть послан до срабатывания таймера RAS
RAI	0			M	Resource Availability Indication (Индикация доступности ресурсов) Передаётся шлюзом привратнику, чтобы уведомить его о ресурсе шлюза для каждого из протоколов серии Н и о соответствующих скоростях передачи
RAC		0	M		Resource Availability Confirm (Подтверждение индикации доступности ресурсов) Ответ привратника на сообщение RAI

6.3 Сигнальный канал Н.225.0
Процедуры управления соединениями в сетях Н. 323 специфицированы Международным союзом электросвязи в рекомендации Н.225.0. Данные процедуры предусматривают использование в базовом процессе обслуживания вызова ряда сигнальных сообщений Q.931 [7], причем должен быть реализован симметричный обмен сигнальными сообщениями в соответствии с приложением D к рекомендации Q.931. Это требование не распространяется на взаимодействие шлюза с сетью коммутации каналов.
Для реализации дополнительных услуг в соответствии с рекомендацией Н.450 в сетях, построенных по рекомендации Н.323, привлекаются сигнальные сообщения Q.932. В дан ном. параграфе рассматриваются наиболее часто используемые сигнальные сообщения.
Сообщение Setup передается вызывающим оборудованием с целью установить соединение. Это сообщение передается на общеизвестный TCP порт 1720 вызываемого оборудования (см. рис.1.4 главы 1).
Сообщение Call Proceeding передается вызывающему оборудованию, чтобы известить его о том, что вызов принят к обслуживанию.
Сообщение Alerting передается вызывающему оборудованию и информирует его о том, что вызываемое оборудование не занято, и что пользователю подается сигнал о входящем вызове.
Сообщение Connect передается вызывающему оборудованию и информирует его о том, что вызываемый пользователь принял входящий вызов. Сообщение Connect может содержать транспортный адрес управляющего канала Н.245.
Сообщение Release Complete передается вызывающим или вызываемым оборудованием с целью завершить соединение. Это сообщение передается только в том случае, когда открыт сигнальный канал.
Сообщение Q.932 Facility используется для обращения к дополнительным услугам в соответствии с Рекомендациями ITU H.450.X.
Транспортировку сигнальных сообщений обеспечивает протокол с установлением соединения и с гарантированной доставкой информации -Transport Control Protocol (TCP). В соответствии с первой и второй версиями рекомендации Н.323 для каждого нового вызова открывается отдельный сигнальный канал.


Начиная с третьей версии рекомендации Н.323, один сигнальный канал Н.225. 0 может переносить сообщения, относящиеся к разным вызовам и имеющие разные метки соединения (call reference). Наличие такой возможности позволяет значительно уменьшить время установления соединения с участием шлюзов и объем передаваемой служебной информации.

Оборудование, поддерживающее управление множеством сигнальных соединений в одном сигнальном канале, присваивает в сигнальных сообщениях значение TRUE информационному полю multipleCalls. Оборудование может ограничивать количество сигнальных соединений, использующих один сигнальный канал, назначая определенный порог. Если этот порог достигнут, оборудование передает отказ в попытке установить соединение - сообщение Release Complete - с указанием причины newConnectionNeeded (требуется открыть новый сигнальный канал).
Кроме того, в версии 3 рекомендации Н.323 говорится о том, что сигнальный канал Н.225.0 может быть организован перед тем, как по нему потребуется передавать сигнальную информацию, и оставаться открытым после завершения соединения. Оборудование, поддерживающее постоянно открытый сигнальный канал, должно присваивать в сигнальных сообщениях значение TRUE информационному полю maintainConnection. Желательно также указывать на эту возможность при регистрации у привратника, что позволит привратнику (в случае маршрутизации им сигнальной информации) подключаться к оборудованию в любой момент после регистрации.
В сетях, не имеющих привратника, открывается сигнальный канал Н.225.0, непосредственно связывающий вызывающее оконечное оборудование с вызываемым. В этом случае вызывающий пользователь должен знать транспортный адрес сигнального канала (Call Signalling Transport Address) оборудования вызываемого пользователя.
В сетях с привратником вызывающее оборудование передает по транспортному адресу канала RAS привратника сообщение ARQ с указанием alias-адреса вызываемого пользователя. Если сигнальные сообщения будет маршрутизировать привратник (Gatekeeper Routed Call Signalling), то в ответном сообщении он передает транспортный адрес своего сигнального канала, что представлено на рис. 6.9.


Если же сигнальный канал будет, согласно рис. 6.10, устанавливаться непосредственно между вызывающим и вызываемым оборудованием (Direct Endpoint Call Signalling), то передается транспортный адрес сигнального канала вызываемого оборудования. Выбор варианта передачи сигнальных сообщений оставлен за привратником, хотя оконечное оборудование может указывать, какой вариант для него предпочтителен. И в первом, и во втором случае сигнальный канал Н.225 выполняет одни и те же функции и переносит одни и те же сообщения.
При маршрутизации сигнальных сообщений привратником сигнальный канал может закрываться сразу после установления соединения или оставаться открытым в течение всего соединения для предоставления дополнительных услуг. Закрыть сигнальный канал может только привратник, но если в соединении участвует шлюз, то сигнальный канал должен оставаться открытым до окончания соединения. При закрытии сигнального канала оконечным оборудованием должно сохраняться текущее состояние соединения. Привратник может в любой момент соединения снова открыть сигнальный канал.
Рис. 6.9 Маршрутизация сигнальной информации привратником
Рис. 6.10 Передача сигнальной информации напрямую
После обмена с привратником сообщениями ARQ и ACF по каналу RAS вызывающее оборудование передает запрос соединения Setup либо по транспортному адресу сигнального канала привратника (если сигнальные сообщения будет маршрутизировать привратник), либо по транспортному адресу сигнального канала вызываемого оборудования (если сигнальный канал будет связывать вызывающее и вызываемое оборудование непосредственно). В ответ на сообщение Setup вызываемое оборудование может передать сообщение Call Proceeding, означающее, что вся информация, необходимая для установления соединения, получена, и вызов принят к обслуживанию. Далее от вызываемого оборудования может поступить сообщение Alerting, означающее, что вызываемому пользователю подается вызывной сигнал. После того как пользователь принимает вызов, вызывающему оборудованию передается сообщение Connect с транспортным адресом управляющего канала Н.245 вызываемого оборудования, если управляющий канал связывает вызывающее и вызываемое оборудование напрямую (рис.6.11), или транспортный адрес канала Н.245 привратника, если управляющие сообщения маршрутизирует привратник (рис.6.12).


В некоторых случаях, например, для проключения разговорных каналов в предответном состоянии, транспортный адрес управляющего канала Н.245 включается в сообщения Call Proceeding или Alerting.

Рис. 6.12 Маршрутизация управляющих сообщений привратником

И, по аналогии с рассмотрением в предыдущем параграфе протокола RAS, завершим краткое описание сигнального канала Н.225.0 перечнем сообщений, сведенным в таблицу 6.2.
Таблица 6.2 Сообщения протокола Н.225.0

Сообщение Q.931/Q.932	Передача	Прием
Alerting (Аналог "КПВ")	М	М
Call Proceeding (Соединение устанавливается)	0	Условное
Connect (Соединение установлено)	М	М
Connect Acknowledge (Подтверждение установления соединения)	Не разрешено	Не разрешено
Progress (Особенности маршрута)	0	0
Setup (Запрос соединения)	М	М
Setup Acknowledge (Подтверждение приема запроса Setup)	0	0
Disconnect (Разъединение)	Не разрешено	Не разрешено
Release (Освободить ресурсы)	Не разрешено	Не разрешено
Release Complete (Ресурсы освобождены)	М	М
Resume (Возобновить соединение)	Не разрешено	Не разрешено
Resume Acknowledge (Соединение возобновлено)	Не разрешено	Не разрешено
Resume Reject (Отказ возобновить соединение)	Не разрешено	Не разрешено
Suspend (Прервать соединение)	Не разрешено	Не разрешено
Suspend Acknowledge (Соединение прервано)	Не разрешено	Не разрешено
Suspend Reject (Отказ прервать соединение)	Не разрешено	Не разрешено
User Information (Информация пользователя)	0	0
Congestion Control (Управление потоком сообщений USER INFORMATION)	Не разрешено	Не разрешено
Information (Информация)	0	0
Notify (Уведомление)	0	0
Status (Статус)	М	М
Status Inquiry (Запрос статуса)	0	М
Facility (Дополнительная услуга)	М	М
Hold (Удержать соединение)	Не разрешено	Не разрешено
Hold Acknowledge (Соединение удерживается)	Не разрешено	Не разрешено
Hold Reject (Отказ удержать соединение)	Не разрешено	Не разрешено
Retrieve (Снять с удержания)	Не разрешено	Не разрешено
Retrieve Acknowledge (С удержания снято)	Не разрешено	Не разрешено
Retrieve Reject (Отказ снять с удержания)	Не разрешено	Не разрешено

6.4 Управляющий канал Н.245
Ранее в книге уже упоминалось, что в рекомендации ITU-Т Н.245 определен ряд независимых процедур, которые должны выполняться для управления информационными каналами. К ним относятся процедуры:
• определения ведущего и ведомого устройств (Master/slave determination);
• обмена данными о функциональных возможностях (Capability Exchange);
• открытия и закрытия однонаправленных логических каналов (Logical Channel Signalling);
• открытия и закрытия двунаправленных логических каналов (Bidirectional Logical Channel Signalling);
• закрытия логических каналов (Close Logical Channel Signalling);
• определения задержки, возникающей при передаче информации от источника к приемнику и в обратном направлении (Round Trip Delay Determination);
• выбора режима обработки информации (Mode Request);
• сигнализации по петле, создаваемой для целей технического обслуживания оборудования (Maintenance Loop Signalling).
Для выполнения вышеуказанных процедур между оконечными устройствами или между оконечным оборудованием и устройством управления конференциями или привратником организуется управляющий канал Н.245. При этом оконечное оборудование должно открывать один (и только один) управляющий канал для каждого соединения, в котором оно участвует. Примечательно, что терминалы. устройства управления конференциями, шлюзы и привратники могут участвовать одновременно в нескольких соединениях и, следовательно, открывать несколько управляющих каналов.
Перенос управляющей информации Н.245 осуществляется протоколом TCP по нулевому логическому каналу, который должен быть постоянно открытым с момента организации канала Н.245 и вплоть до его ликвидации. Следует отметить, что нормальные процедуры открытия и закрытия логических каналов, описываемые в этой главе, для управления нулевым логическим каналом не применяются.
По управляющему каналу Н.245 передаются сообщения четырех категорий: запросы, ответы, команды и индикации. Получив сообщение-запрос, оборудование должно выполнить определенное действие и немедленно передать обратно сообщение-ответ.


Получив сообщение-команду, оборудование также должно выполнить определенное действие, но отвечать на команду не должно. Сообщение-индикация служит для того, чтобы информировать о чем-либо получателя, но не требует от него ни ответа, ни каких бы то ни было действий.
Ниже в этом параграфе дается краткое описание основных процедур Н.245, выполняемых в процессе управления логическими каналами.
6.4.1 Определение ведущего и ведомого
Процедура определения ведущего и ведомого оборудования используется для разрешения конфликтов, возникающих между двумя устройствами при организации конференции, когда ведущим в ней может быть любое из этих устройств, или между двумя устройствами, которые одновременно пытаются открыть двунаправленный логический канал. Устройства обмениваются сообщениями master-SlaveDetermination (рис.6.13), в поле terminalType которых помещается значение, соответствующее типу данного оборудования (таблица 6.3), а в поле statusDeterminationNumber - случайное число из интервала [0 - (224-'!)]. Ведущим становится оборудование, поместившее большее число в поле terminalType, а при совпадении типов оборудования - большее число в поле statusDeterminationNumber.
Рис. 6.13 Первый вариант определения ведущего и ведомого оборудования

В ответ на полученные сообщения masterSlaveDetermination оба устройства передают сообщения masterSlaveDetermlnatlonAck, в которых указывается, какое оборудование является для данного соединения ведущим, а какое - ведомым. При этом любое оборудование стандарта Н.323 должно быть способно работать и в качестве ведущего, и в качестве ведомого.
Следует отметить, что активный МС в конференции должен использовать значение 240. При этом в конференции может быть только один активный контроллер. В ходе конференции активный контроллер не должен меняться.
Таблица 6.3 Значения поля TerminalType для разных типов оборудования

Тип оборудования стандарта Н.323	Значение в поле TerminalType
Терминал	Шлюз	Привратник	MCU
Оборудование, не содержащее МС	50	60	-	-
Оборудование, содержащее МС, но без МР	70	80	120	160
Оборудование, содержащее МС и МР для данных	-	90	130	170
Оборудование, содержащее МС и МР для данных и речи	-	100	140	180
Оборудование, содержащее МС и МР для данных, для речи и для видеоинформации	-	110	150	190

Существует вариант процедуры Master- Slave Determination, предусматривающий сокращение числа передаваемых сообщений (рис.6.14).
Рис. 6.14 Второй вариант определения ведущего и ведомого оборудования
В этом варианте оборудование, передавшее сообщение master-SlaveDetermination и получившее в ответ сообщение masterSlave-DeterminationAck, передает сообщение masterSlaveDetermina-tlonAck.

6.4.2 Обмен данными о функциональных возможностях
Оборудование стандарта Н.323, в общем случае, способно принимать и передавать речь, видеоинформацию и данные. Это означает, что оборудование обычно содержит приемник и передатчик информации. Как правило, устройства поддерживают несколько алгоритмов кодирования и декодирования информации каждого вида, которые подробно обсуждались в главе 3. Для согласования режимов работы передающей и принимающей сторон используется процедура, называемая обменом данными о функциональных возможностях оборудования(рис.6.15).

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


Таким образом, алгоритмы, которые используются для кодирования передаваемой информации, указывать не обязательно, и в существующих продуктах IP-телефонии, реализованных на базе Н.323, для речи и видеоинформации обычно указываются только алгоритмы, которые используются для декодирования принимаемой информации.
В сообщение TerminalCapabilitySet включается поле capability Table - таблица функциональных возможностей, где каждому алгоритму кодирования/декодирования присвоен порядковый номер. Например, возможности приема речевой информации, закодированной по алгоритму G.723.1, соответствует номер 1, возможности приема речевой информации, закодированной по алгоритму G.728, - номер 2, возможности приема видеосигналов, закодированных по алгоритму Н.263, - номер 3 и т. д.
Указанные порядковые номера объединяются в список альтернативных режимов alternativeCapabilitySet. Оборудование может использовать любой (но только один) из режимов, указанных в списке. Например, список альтернативных режимов {G.711, G.723.1, G.728} означает, что оборудование может функционировать в любом из указанных режимов обработки речи, но только в одном.
В свою очередь, альтернативные режимы объединяются в наборы одновременно возможных режимов функционирования simulta-neousCapabilltles. Например, набор одновременно возможных режимов, содержащий список альтернативных режимов обработки видеоинформации {Н.261, Н.263} и список альтернативных режимов обработки речевой информации {G.711, G.723.1, G.728}, означает, что оборудование может использовать любой из указанных алгоритмов кодирования видеоинформации совместно с любым из списка алгоритмов кодирования речевой информации.
Другой пример: набор одновременно возможных режимов, содержащий два списка альтернативных режимов обработки видеоинформации {Н.261}, {Н.261, Н.263} и один список альтернативных режимов обработки аудиоинформации {G.711, G.723.1, G.728}, означает, что оборудование может одновременно использовать два алгоритма кодирования видеоинформации (первый - Н.261, второй - Н.261 или Н.263) и один алгоритм декодирования речи (либо G.711, либо G.723.1.


либо G.728).
Функциональные возможности терминала описываются набором дескрипторов (capability Descriptor), каждый из которых состоит из одного набора одновременно возможных режимов функционирования оборудования и номера дескриптора (capabilityDescrlptorNum-ber). Если при обмене данными о функциональных возможностях оборудование указывает более чем один дескриптор, то это означает, что оборудование поддерживает несколько режимов функционирования. Например, наличие в сообщении TerminalCapabilitySet двух дескрипторов: первого - как и в предыдущем примере, т.е. {Н.261, Н.263} и {G.711, G.723.1. G.728}, а второго-{Н.262} и {G.711}, означает, что оборудование, кроме описанного выше режима, поддерживает обработку видеоинформации, закодированной по алгоритму Н.262, совместно с обработкой речи. закодированной по менее сложному, по сравнению с остальными, алгоритму кодирования G.711.
Заметим, что функциональные возможности оборудования, не определенные рекомендацией ITU H.245, могут быть указаны в поле nonStandardParameter.
Оборудование может в любое время передать сообщение TerminalCapabilitySet с дескриптором, добавляющим новые функциональные возможности, или с дескриптором, обеспечивающим исключение некоторых из ранее указанных возможностей. Любое оборудование стандарта Н.323 должно включать в сообщение TerminalCapabilitySet, no крайней мере, один дескриптор. Исключение составляет сообщение EmptyCapabilitySet (пустой набор функциональных возможностей), которое используется для реализации дополнительных возможностей системы.
Оборудование, которое получило от другого оборудования сообщение TerminalCapabllHySet, может подтвердить его получение передачей сообщения TerminalCapabilltySetAck.
При получении сообщения с некорректным набором возможностей оборудование отвечает сообщением TerminalCapabilitySetRe-ject. При срабатывании таймера, запущенного после отправки сообщения TerminalCapabilitySet, оборудование, его пославшее, передает сообщение TerminalCapabilitySetRelease.


6.4.3 Открытие и закрытие логических каналов
Информация, передаваемая источником к одному или более приемникам в сетях, базирующихся на рекомендации Н.323, переносится по логическим каналам, которые идентифицируются уникальным для каждого направления передачи номером канала.
Рекомендацией Н.245 предусмотрена возможность открытия логических каналов двух видов: однонаправленных (uni-directional), т.е. открывающихся в направлении от источника к приемнику информации, и двунаправленных (bi-directional), открывающихся сразу в двух направлениях - от источника к приемнику информации и в обратном направлении.
Однонаправленные логические каналы открываются при помощи процедуры Uni-directional Logical Signalling (рис.6.16).

Рис. 6.16 Процедура открытия однонаправленных логических каналов

В требовании открыть логический канал openLogicalChannel оборудование указывает вид информации, который будет передаваться по этому каналу, и алгоритм кодирования информации. Если логический канал предназначается для переноса речи или видеоинформации, упакованной в пакеты рассмотренного в главе 4 протокола RTP (Real Time Protocol), то в сообщение openLogicalChannel должен включаться параметр mediaControlChannel с указанием транспорт-
ного адреса канала протокола RTCP (Real Time Control Protocol), при помощи которого ведется контроль передачи RTP пакетов.
Оборудование, получившее запрос открыть логический канал для приема данных, вид которых не поддерживается или не распознан, должно ответить сообщением openLogicalChannelReject. Получение корректного сообщения opentogicalChannel оборудование должно подтвердить сообщением openLogicalChannelAck.
Если логический канал открывается для переноса речи или видеоинформации, то принимающая сторона указывает в параметре mеdiaTransportChannel сообщения openLogicalChannelAck транспортный адрес, на который передающая сторона должна передавать RTP пакеты, а в параметре mediaControlChannel, - транспортный адрес канала RTCP.
При открытии каналов для передачи данных, например для приложений Т. 120 параметр mediaControlChannel в сообщениях ореп-LoglcalChannel и openLogicalChannelAck отсутствует.


Когда оборудование открывает однонаправленный логический канал, то, чтобы организовать дуплексную связь, встречное оборудование также должно открыть однонаправленный канал в обратном направлении, используя для этого вышеописанную процедуру Unidirectional Logical Signalling.
Для передачи речи или видеоинформации, как правило, открывается однонаправленный канал от источника к приемнику информации и, независимо, канал в обратном направлении. Поэтому допускается асимметричный режим работы, когда в разных направлениях передачи открывается разное количество каналов и используются разные алгоритмы кодирования информации одного и того же вида.
Если приемная сторона способна работать только в симметричном режиме, она может указать на это ограничение при выполнении процедуры Capabilities exchange.
Следует отметить, что прямой и обратный каналы не должны иметь один и тот же номер, так как номера логических каналов присваиваются независимо для каждого направления передачи. Кроме того, для прямого и обратного логических каналов, относящихся к одной RTP-сессии и имеющих один и тот же идентификатор сессии (sessionID), открывается только один канал RTCP.
В некоторых случаях, например, для обмена данными по протоколу Т. 120, оборудование, инициирующее такой обмен, должно открывать сразу и прямой, и обратный каналы. Делается это с помощью процедуры Bi-directional Logical Signalling, которая практически идентична вышеописанной процедуре Uni-directional Logical Signalling и также предусматривает обмен сообщениями openLogicalChannel и openLogicalChannelAck. Добавляется сообщение - openLogicalChannelConfirm, - которое передается в ответ на сообщение OpenLogicalChannelAck и подтверждает, что двунаправленный логический канал открыт (см. сценарий на рис.6.17). Заметим, что если процедура Uni-directional Logical Signalling для организации дуплексной связи должна выполняться два раза, то процедура Bi-directional Logical Signalling выполняется только один раз.
Рис. 6.17 Процедура открытия двунаправленного логического канала



Закрытие логических каналов может производиться с помощью процедуры CloseLogicalChannel, но она используется, в основном, для поддержки предоставления дополнительных услуг, в первую очередь, - перевода в режим удержания. Для нормального разрушения соединения стороны обмениваются сообщениями endSessionCommand. После обмена этими сообщениями закрываются не только логические каналы, но и управляющий канал Н.245.
6.4.4 Выбор режима обработки информации
Оконечное оборудование в ходе процедуры Capabilitiesexchange может объявить поддерживаемые им режимы передачи информации. Встречное оборудование, получив список возможных режимов передачи информации, может, передав сообщение requestMode, запросить передачу в одном из этих режимов. Устройство, получившее сообщение requestMode, должно, если это возможно, выполнить содержащееся в нем требование (рис.6.18). Оборудование, не желающее находиться под контролем другого оборудования в части выбора режима передачи информации, может просто не указывать. каким способом оно будет ее передавать.
Рис. 6.18 Выбор режима обработки информации

Терминальное оборудование, участвующее в конференции и получившее от контроллера конференций сообщение multipointModeCommand, должно выполнять требования, содержащиеся в сообщениях requestMode, если эти требования не выходят за пределы возможностей оборудования. Примечательно, что в централизованных и децентрализованных конференциях, все сообщения requestMode, передаваемые терминалами, поступают на контроллер конференций, и он принимает решение, удовлетворить полученные требования или нет.
В таблице 6.4 приведены сообщения Н.245, которые оборудование стандарта Н.323 обязано принимать и передавать, а также необязательные и запрещенные сообщения Н.245. Приняв нераспознаваемое сообщение, оборудование Н.323 должно передать в ответ сообщение functlonNotSupported. Следует отметить, что описание наиболее часто используемых сообщений было приведено в данном параграфе.
Таблица 6.4 Управляющие сообщения Н.245

Сообщения Н.245	Прием	Передача
Determination	M	M
Determination Acknowledge	M	M
Determination Reject	M	M
Determination Release	M	M
Capability Set	M	M
Capability Set Acknowledge	M	M
Capability Set Reject	M	M
Capability Set Release	M	M
Open Logical Channel	M	M
Open Logical Channel Acknowledge	M	M
Open Logical Channel Reject	M	M
Open Logical Channel Confirm	M	M
Close Logical Channel	M	M
Close Logical Channel Acknowledge	M	M
Request Channel Close	M	0
Request Channel Close Acknowledge	0	0
Request Channel Close Reject	0	M
Request Channel Close Release	0	M
Multiplex Entry Send	He разрешено	He разрешено
Multiplex Entry Send Acknowledge	He разрешено	He разрешено
Multiplex Entry Send Reject	He разрешено	He разрешено
Multiplex Entry Send Release	He разрешено	He разрешено
Request Mode	M	0
Request Mode Acknowledge	M	0
Request Mode Reject	0	M
Request Mode Release	0	M
Round Trip Delay Request	M	0
Round Trip Delay Response	0	M
Maintenance Loop Request
System Loop	He разрешено	Не разрешено
Media Loop	Обязательно только для шлюзов
Logical Channel Loop	Не разрешено	Не разрешено
Maintenance Loop Acknowledge	0	0
Maintenance Loop Reject	0	M
Maintenance Loop Command Off	M	0
Terminal List Request	0	0
Drop Terminal	0	0
Make Me Chair	0	0
Cancel Make Me Chair	0	0
Enter H.243 Password	0	0
Enter H.243 Terminal Id	0	0
Enter H.243 Conference ID	0	0
Request Terminal ID	0	0
Terminal ID Response	0	0
MC Terminal ID Response	0	0
Enter Extension Address	0	0
Enter Address Response	0	0
Terminal List Response	0	0
Make Me Chair Response	0	0
Conference ID Response	0	0
Password Response	0	0
Send Terminal Capability Set	M	M
Encryption	0	0
Flow Control	M	0
End Session	M	M
Equalize Delay	0	0
Zero Delay	0	0
Multipoint Mode Command	M	0
Cancel Multipoint Mode Command	M	0
Video Freeze Picture	M	0
Video Fast Update Picture	M	0
Video Fast Update GOB	M	0
Video Fast Update MB	M	0
Video Temporal Spatial Trade Off	0	0
Video Send Sync Every GOB	0	0
Video Send Sync Every GOB Cancel	0	0
Terminal ID Request	0	0
Video Command Reject	0	0
Make Me Chair Response	0	0
Broadcast My Logical Channel Me	0	0
Cancel Broadcast My Logical Channel Me	0	0
Make Terminal Broadcaster	0	0
Cancel Make Terminal Broadcaster	0	0
Send This Source	0	0
Cancel Send This Source	0	0
Drop Conference	0	0
Communication Mode Command	M	0
Communication Mode Request	0	0
Communication Mode Response	0	0
Function Not Understood	M	M
Function Not Supported	M	M
Logical Channel Active	0	0
Logical Channel Inactive	0	0
Multipoint Conference	M	0
Cancel Multipoint Conference	M	0
Multipoint Zero Comm	0	0
Cancel Multipoint Zero Comm	0	0
Multipoint Secondary Status	0	0
Cancel Multipoint Secondary Status	0	0
Video Indicate Ready to Activate	0	0
Video Temporal Spatial Trade Off	0	0
Video Not Decoded MBs	0	0
SBE Number	0	0
Terminal Number Assign	M	0
Terminal Joined Conference	0	0
Terminal Left Conference	0	0
Seen By At Least One Other	0	0
Cancel Seen By At Least One Other	0	0
Seen By All	0	0
Cancel Seen By All	0	0
Terminal You Are Seeing	0	0
Request For Floor	0	0
Vendor Indications	0	0
MC Location Indication	M	0
Jitter Indication	0	0
H.223 Skew Indication	Не разрешено	Не разрешено
H2250MaximumSkewlndication	0	M
New ATM Virtual Channel Indication	Не разрешено	Не разрешено
User input	M (0-9, * и #)	M (0-9, * и #)

6.5 Алгоритмы установления, поддержания и разрушения соединения
Процедура установления, поддержания и разрушения соединений в IP-сети с использованием семейства протоколов Н. 323 на страницах этой книги обсуждалась уже дважды, в главах 1 и 2, с разной степенью детализации. Теперь, вооружившись материалами глав 4, 5 и 6, пора продолжить эту цепочку последовательных приближений и рассмотреть алгоритмы установления, поддержания и разрушения соединений по протоколу Н.323 более подробно.
В силу важности этих алгоритмов авторам хотелось бы сохранить легкость восприятия материала. Поэтому они приняли решение рассмотреть наиболее часто применяемые на практике примеры базового соединения в сети, базирующейся на рекомендации Н.323. В качестве примеров взяты случаи:
• вызываемый и вызывающий пользователи зарегистрированы в одном и том же привратнике, который маршрутизирует сигнальную и управляющую информацию;
• вызываемый и вызывающий пользователи соединяются непосредственно друг с другом, привратник в сети отсутствует.
Прежде чем рассматривать эти два сценария, отметим, что в общем случае алгоритмы установления, поддержания и разрушения соединений по Н.323 включают в себя следующие фазы:
• Фаза А. Установление соединения;
• Фаза В. Определение ведущего/ведомого оборудования и обмен данными о функциональных возможностях;
• Фаза С. Установление аудиовизуальной связи между вызывающим и вызываемым оборудованием;
• Фаза D. Изменение полосы пропускания, запрос текущего состояния оборудования, создание конференций и обращение к дополнительным услугам;
• Фаза Е. Завершение соединения.
6.5.1 Базовое соединение с участием привратника
Сценарий этого первого случая приведен на рис.6.19. Вызывающее оборудование передает сообщение ARQ с alias-адресом вызываемого абонента, в ответ на которое привратник передает сообщение ACF с уведомлением, что именно он будет маршрутизировать сигнальные сообщения (Gatekeper routed call signaling), и с указанием транспортного адреса своего сигнального канала.


Далее вызывающее оборудование передает на этот транспортный адрес запрос соединения Setup. Привратник пересылает сообщение Setup вызываемому оборудованию и передает вызывающему оборудованию
сообщение Call Proceeding, означающее, что полученной информации достаточно для обслуживания поступившего вызова. Вызываемое оборудование также отвечает на Setup сообщением Call Proceeding. Если оборудование имеет возможность принять вызов, оно передает запрос допуска к ресурсам сети ARQ, на который привратник может ответить подтверждением ACF или отказом в допуске к ресурсам сети ARJ. В первом случае вызываемое оборудование передает сообщение Alerting, и привратник маршрутизирует его к вызывающему оборудованию. Вызываемому пользователю подается визуальный или акустический сигнал о входящем вызове, а вызывающему дается индикация того, что вызываемый пользователь не занят и ему подается вызывной сигнал. При отказе в допуске к ресурсам сети вызываемое оборудование закрывает сигнальный канал путем передачи привратнику сообщения Release Complete.
После того как вызываемый пользователь примет входящий вызов, привратнику передается сообщение Connect с транспортным адресом управляющего канала Н.245 вызываемого оборудования. Привратник заменяет этот адрес транспортным адресом своего управляющего канала Н.245 и пересылает Connect вызывающему оборудованию, после чего открывается управляющий канал Н.245.
Чтобы ускорить открытие разговорной сессии, управляющий канал может быть открыт вызываемым оборудованием после получения сообщения Setup с транспортным адресом управляющего канала Н.245 вызывающего оборудования или привратника, или вызывающим пользователем после получения сообщения Call Proceeding или Alerting, содержащего транспортный адрес управляющего канала Н.245 вызываемого пользователя или привратника.
После открытия управляющего канала Н.245 начинается обмен данными о функциональных возможностях оборудования. В рассматриваемом нами случае все управляющие сообщения, передаваемые от одного оконечного оборудования к другому, маршрутизируются привратником.


Терминалы обмениваются сообщениями TermlnalCapabilttySet, в которых указываются возможные алгоритмы декодирования принимаемой информации. Следует отметить, что сообщение TermjnalCapabllHySet должно быть первым сообщением, передаваемым по управляющему каналу. Оборудование, принявшее сообщение TermlnalCapabllitySet от другого оборудования, подтверждает его получение передачей сообщения TermlnalCapabllttySetAck.
Затем инициируется процедура определения ведущего/ведомого оборудования, необходимая для разрешения конфликтов, возникающих между двумя устройствами при организации конференции, когда оба они могут быть активными контроллерами конференций, или между двумя устройствами, пытающимися одновременно открыть двунаправленные логические каналы. В ходе процедуры устройства обмениваются сообщениями masterSlaveDetermlnation.
Рис. 6.19 Пример соединения с участием привратника

В ответ на полученные сообщения masterSlaveDetermination оба устройства передают сообщения masterSlaveDeterminationAck, в которых указывается, какое из этих устройств является для данного соединения ведущим, а какое - ведомым.
Напомним, что возможен сценарий процедуры Master-Slave Determination, предусматривающий сокращение количества передаваемых сообщений: оборудование, передавшее сообщение masterSlaveDetermination и получившее в ответ сообщение masterSlaveDeterminationAck, передает сообщение masterSlaveDeterminationAck.
После обмена данными о функциональных возможностях и определения ведущего и ведомого оборудования может выполняться процедура открытия однонаправленных логических каналов. В требовании открыть логический канал (в нашем случае - прямой логический канал) openLogicalChannel оборудование указывает вид информации, который будет передаваться по этому каналу, и алгоритм кодирования. В нашем случае логический канал предназначается для переноса речи, поэтому в сообщение openLogicalChannel включается параметр mediaControlChannel с указанием транспортного адреса канала RTCP, при помощи которого производится контроль передачи RTP пакетов.


В ответ на сообщение openLogicalChannel оборудование должно передать подтверждение openLogicalChannelAck, в котором указывается транспортный адрес, на который передающей стороне следует посылать RTP пакеты, а также транспортный адрес канала RTCP.
Далее открывается разговорная сессия. Оборудование вызывающего пользователя передает речевую информацию, упакованную в пакеты RTP/UDP/IP, на транспортный адрес RTP-канала оборудования вызванного пользователя, а вызванный пользователь передает пакетированную речевую информацию на транспортный адрес RTP-канала оборудования вызывающего пользователя. При помощи канала RTCP ведется контроль передачи информации по RTP каналам.
После окончания разговорной фазы начинается фаза разрушения соединения. Оборудование пользователя, инициирующего разъединение, должно прекратить передачу речевой информации, закрыть логические каналы и передать по управляющему каналу сообщение Н.245 endSessionCommand, означающее, что пользователь хочет завершить соединение. Далее от встречного оборудования ожидается сообщение endSessionCommand, после приема которого управляющий канал Н.245 закрывается. Следующим шагом, если сигнальный канал еще открыт, передается сообщение Release Complete.
Пользователь, получивший команду endSessionCommand от пользователя, инициировавшего разрушение соединения, должен прекратить передачу речевой информации, закрыть логические каналы и передать сообщение endSessionCommand. Далее, если сигнальный канал остался открытым, передается сообщение Release Complete, и сигнальный канал закрывается.
После вышеописанных действий оконечное оборудование извещает привратник об освобождении зарезервированной полосы пропускания. С этой целью каждый из участников соединения передает по каналу RAS запрос выхода из соединения DRQ, на который привратник должен ответить подтверждением DCF, после чего обслуживание вызова считается завершенным.
6.5.2 Базовое соединение без участия привратника
Теперь рассмотрим случай, когда вызываемое и вызывающее оборудование взаимодействуют непосредственно друг с другом, привратник в сети отсутствует (рис.6.20).


Вызывающее оборудование посылает запрос соединения Setup на известный транспортный адрес сигнального канала вызываемого оборудования. Вызываемое оборудование отвечает на Setup сообщением Call Proceeding, а затем - Alerting. Вызываемому пользователю дается визуальный или акустический сигнал о входящем вызове, а вызывающему - индикация того, что вызываемый пользователь не занят и получает вызывной сигнал.
Как только вызываемый пользователь примет входящий вызов, передается сообщение Connect с указанием транспортного адреса управляющего канала Н.245 вызываемого оборудования, после чего открывается управляющий канал Н.245.
И здесь, чтобы ускорить открытие разговорной сессии, управляющий канал тоже может быть открыт вызываемым оборудованием после получения сообщения Setup с транспортным адресом управляющего канала Н.245 вызывающего оборудования, или вызывающим пользователем после получения сообщения Call Proceeding или Alerting, в котором содержится транспортный адрес управляющего канала Н.245 вызываемого оборудования.
После открытия управляющего канала выполняются все процедуры, описанные в первом случае: обмен данными о функциональных возможностях, определение ведущего/ведомого оборудования, открытие однонаправленных логических каналов.
Далее открывается разговорная сессия. Оборудование вызывающего пользователя передает речевую информацию, упакованную в пакеты RTP/UDP/IP, на транспортный адрес RTP-канала оборудования вызываемого пользователя, а оно, в свою очередь, передает пакетированную речевую информацию на транспортный адрес RTP-канала оборудования вызывающего пользователя.
После окончания разговорной фазы начинается фаза разрушения соединения. Оборудование пользователя, инициирующего разъединение, прекращает передачу речевой информации, закрывает логические каналы и передает по управляющему каналу сообщение Н.245 endSessionCommand, означающее, что пользователь хочет завершить соединение. Ожидается сообщение endSessionCommand от встречного оборудования, после чего управляющий канал Н.245 закрывается.


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

Пользователь, получивший команду endSessionCommand от пользователя, инициировавшего разъединение, должен прекратить передачу речевой информации, закрыть логические каналы и передать сообщение endSessionCommand. Далее, если сигнальный канал остался открытым, передается сообщение Release Complete, сигнальный канал закрывается, и обслуживание вызова считается завершенным.
6.5.3 Туннелирование управляющих сообщений
Для ускорения установления соединения может использоваться процесс, известный как инкапсуляция или Туннелирование управляющих сообщений Н.245. При этом передача сообщений Н.245 осуществляется по сигнальному, а не по отдельному управляющему каналу. Одно или несколько сообщений Н.245 переносятся в элементе h245Control информационного поля h323_uu_pdu в любом из разрешенных сообщений Q.931.
Чтобы применить инкапсуляцию сообщений Н.245, вызывающее оборудование должно присвоить значение TRUE элементу h245Tunnelling, передаваемому в сообщении Setup и в последующих сообщениях Q.931. Вызываемое оборудование, получившее в сообщении Setup элемент h245Tunnelling со значением TRUE и желающее использовать инкапсуляцию управляющих сообщений, также должно присвоить значение TRUE элементу h245Tunnelling в сообщении, передаваемом в ответ на сообщение Setup, и в последующих сообщениях Q.931.
Вызываемое оборудование, не поддерживающее Туннелирование управляющих сообщений, присваивает элементу h245Tunnelling, передаваемому в ответе на сообщение Setup, значение FALSE. В этом случае для передачи управляющих сообщений открывается отдельный канал Н.245.

6.5.4 Процедура быстрого установления соединения
Самый быстрый способ установления соединения в сети, базирующейся на рекомендации Н.323, - это использование процедуры Fast Connect. Чтобы инициировать процедуру Fast Connect, вызывающее оборудование передает сообщение Setup с элементом fastStart. Этот элемент может включать в себя одну или несколько структур Open Log icalChannel. Одна из структур OpenLogicalChannel обязательно должна содержать элемент forwardLogicalChannelParametere и может содержать элемент reverseLogicalChannelParameters, но, в то же время, структура OpenLogicalChannel описывает точно один однонаправленный логический канал.


Это означает, что когда описывается прямой логический канал, то в структуре присутствует только элемент forwardLogicalChannelParameters. Элемент содержит информацию об алгоритме, который используется вызывающим оборудованием для кодирования передаваемой информации, и адрес канала RTCR При описании канала обратного направления в элементе forwardLogicalChannelParameters не содержится никакой информации, хотя сам он обязательно присутствует, а в элементе reverseLogicalChannelParameters содержатся сведения об алгоритме декодирования принимаемой информации, транспортный адрес RTP, на который следует передавать информацию, и адрес канала RTCP.
В элементе fastStart может присутствовать несколько альтернативных структур OpenLogica (Channel, различающихся алгоритмами кодирования передаваемой информации или декодирования принимаемой информации, причем наиболее предпочтительные алгоритмы указываются в первую очередь.
Вызываемое оборудование может отклонить процедуру Fast Connect, либо если оно ее не поддерживает, либо если существует потребность в использовании процедур Н.245 с открытием отдельного канала Н.245 или с Туннелированием управляющих сообщений. В этом случае элемент fastStart не включается ни в одно из сообщений, передаваемых после приема Setup, до сообщения Connect включительно. Открытие логических каналов для передачи речевой информации производится с использованием процедур Н.245.
Вызываемое оборудование, получившее сообщение Setup с элементом fastStart и могущее поддержать процедуру Fast Connect, должно включить элемент fastStart в любое из сообщений Q.931, передаваемых после приема Setup, до сообщения Connect включительно. Элемент fastStart содержит структуры OpenLogicalChan-nel, которые выбраны вызываемым оборудованием из структур, предложенных вызывающим оборудованием. И снова одна из структур OpenLogicalChannel содержит элемент forwardLogicalChannel-Parameters со сведениями об алгоритме кодирования информации, с транспортными адресами каналов RTP и RTCP вызываемого оборудования.


Вторая структура OpenLogicalChannel включает в себя элемент forwardLogicalChannelParameters, не содержащий никакой информации, и элемент reverseLogicalChannelParameters со сведениями об алгоритме кодирования информации и с транспортным адресом канала RTCP вызываемого оборудования.
Вызываемое оборудование может начинать передачу информации сразу вслед за любым сообщением Q.931 с элементом fastStart. Это означает, что вызывающее оборудование должно быть готовым к приему информации, закодированной любым из указанных в сообщении Setup способов. Сообщение Q.931 с элементом fastStart, переданное вызываемым оборудованием после получения сообщения Setup, может прийти после начала передачи пользовательской
информации. Если вызывающее оборудование не желает принимать речевую информацию до прихода сообщения Connect, оно присваивает значение TRUE элементу mediaWaitForConnect, передаваемому в сообщении Setup.
Вызывающее оборудование, инициировавшее процедуру Fast Connect, может начать передачу речевой информации сразу после приема любого из разрешенных сообщений Q.931, содержащего элемент fastStart.
При разрушении соединения одним из участников передается сообщение Release Complete, после чего закрывается сигнальный канал и соединение считается завершенным.
Следует отметить, что при использовании процедуры Fast Connect или при Туннелировании управляющих сообщений как одна, так и другая сторона может открыть управляющий канал Н.245, для чего оборудование этой стороны должно включить в любое сообщение Q.931 элемент h245Address. При этом процедура Fast Connect или Туннелирование прерывается.
6.5.5 Установление соединения с участием шлюза
В главе 2 обсуждались основные сценарии установления соединения в IP-телефонии. Напомним приведенные там варианты, предполагающие участие шлюза - элемента сети Н.323, который был рассмотрен в предыдущей главе. Первый вариант - это случай, когда абонент ТфОП вызывает пользователя IP-сети, второй - когда пользователь IP-сети вызывает абонента ТфОП, а в третьем варианте абонент ТфОП вызывает абонента ТфОП, но соединение проходит через IP-сеть.


В первом варианте с точки зрения протоколов Н. 323 соединение устанавливается так же, как соединение участников, включенных в сеть с маршрутизацией пакетов IP. Рассмотрим ситуацию с точки зрения ТфОП. Существует два способа набора номера вызываемого абонента: одноступенчатый и двухступенчатый.
При одноступенчатом способе вызывающий абонент сразу набирает номер вызываемого абонента, и шлюз устанавливает с ним соединение. Пока устанавливается соединение в IP-сети, шлюз может передать вызывающему абоненту ТфОП сообщение Call Proceeding, чтобы перезапустить таймеры. Данный способ может использоваться в корпоративной сети для организации связи между абонентами учрежденческих телефонных станций.
В сетях связи общего пользования применяется двухступенчатый способ, при котором вызывающий абонент сначала набирает телефонный номер шлюза и устанавливает с ним соединение. Затем абонент вводит свой персональный код для идентификации и номер вызываемого абонента; эта информация передается по проключенному разговорному тракту сигналами DTMF. Следует отметить, что необходимость в наборе персонального кода возникает не всегда, так как номер вызывающего абонента может содержаться в сигнальных сообщениях систем сигнализации DSS1 и ОКС7, а при использовании систем сигнализации 2ВСК или аналоговых систем сигнализации - определяться при помощи АОН.
Существует несколько способов идентификации абонентов. В первом случае alias-адрес абонента (PIN-код или телефонный номер) шлюз передает привратнику в сообщении ARQ. Во втором случае идентификационный номер вызывающего абонента, набранный с помощью DTMF, передается специальному серверу. Кроме того, в ТфОП вызов может обрабатываться системой обработки телефонных карт, которая отвечает за идентификацию пользователей и начисление платы. Существует еще один вариант когда функции идентификации абонентов и начисления оплаты возложены на опорную АТС, к которой подключен шлюз.
Во втором сценарии, когда пользователь IP-сети вызывает абонента ТфОП при помощи шлюза, с точки зрения протоколов Н.323 соединение устанавливается так же, как описанное соединение участников, включенных в сеть с маршрутизацией пакетов IP.Вызываемое оборудование организует сигнальный канал Н.225.0 со шлюзом (при участии или без участия привратника). Далее передается требование на установление соединения Setup, которое содержит телефонный номер вызываемого абонента в формате Е. 164. Пока устанавливается соединение в ТфОП, шлюз может передать вызывающему абоненту IP-сети сообщение Call Proceeding, чтобы перезапустить таймеры, если в течение 4 секунд после приема сообщения Setup он не передал сообщения Alerting, Connect или Release Complete. Чтобы указать, что вызов выходит за пределы IP-сети, в сообщения Alerting, Call Proceeding, Progress и Connect должен включаться информационный элемент Progress Indicator.
Сценарий вызова абонента ТфОП абонентом ТфОП является комбинацией двух предыдущих сценариев и с технической точки зрения не содержит никаких новых процедур. О социальном и экономическом аспектах обслуживания вызовов по этому сценарию уже говорилось в главе 2.

Глоссарий

Глоссарий

ACELP Algebraic Code-Excited Linear Prediction. Популярный алгоритм компрессии речевого сигнала (скорость передачи 8 Кбит/с)

ADPCM Adaptive Differential РСМ. Адаптивная дифференциальная ИКМ

API Application Programming Interface. Интерфейс прикладного программирования. Это набор функций, с помощью которых приложения взаимодействуют с операционной системой для выполнения задач

ARP Adress Resolution Protocol. Протокол, обеспечивающий динамическое преобразование адресов Интернет в физические (аппаратные) адреса оборудования локальной сети

ARPA Advanced Research Projects Agency. Специальное агентство при Министерстве обороны США (Department of Defense - DoD), создавшее сеть ARPANET

ASCII American Standard Code for Information Interchange. Американский стандартный код для обмена информацией

ASN.1 Abstract Syntax Notation One. Слецификация абстрактной синтаксической нотации, версия 1. Служит для описания информационных объектов прикладного уровня

BQP Border Gateway Protocol. Одноуровневый многопунктовый протокол динамической междоменной маршрутизации. При выборе маршрута учитывает число пересылок, пропускную способность каналов и др. Выявляет закольцовывание маршрутов.

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

CNG Comfort Noise Generator. Генератор комфортного шума. Используется в системах с компрессией речевого сигнала для устранения эффекта “гробовой тишины” в паузах, когда передача сигнала прекращается, и у слушающего создается иллюзия, что связь прервана.

CS-ACELP Conjugate Structure - Algebraic Code - Excited Linear Prediction. Технология CS-ASELP применяется в кодеках G.729, используемых для передачи речи по сетям Frame Relay. Обеспечивает скорость передачи 8 Кбит/с при длительности кадра 10 мс.

CSRC Contributing Source Identifier. Список полей с идентификаторами источников, речевая информация которых смешивается при создании RTP-пакета. Во время речевой конференции каждый RTP-пакет содержит свой SSRC.

DiffServ Differentiated Services. Система дифференцированного обслуживания графика разных классов, разработанная комитетом IETF

DNS Domain Name System. Сервер имен доменов в Интернет, преобразующий эти имена в IP-адреса.

DSP Digital Signal Processor. Процессор цифровой обработки сигналов.

DTMF Dual Tone Multi-Freqency. Многочастотная система кодирования цифр номера. Имеется две группы частот, и цифра кодируется двумя частотами из разных групп.

DTX Discontinuous Transmission. Прерываемая передача. Кодек прекращает передачу пакетов, когда детектор речевой активности обнаруживает паузу в речи.

DVMRP Distance Vector Multicast Routing Protocol. Один из основных протоколов, на базе которых реализуется многоадресная рассылка в IP-сетях.

Е1 Цифровая система передачи со скоростью 2.048 Мбит/с, используемая в России и других европейских странах.

ЕСМА European Computer Manufacturer's Association. Ассоциация европейских производителей компьютеров.

Е1А Electronic Industries Association. Ассоциация электронной промышленности. Группа, разрабатывающая стандарты передачи данных. Разработчик ряда коммуникационных стандартов, в том числе, стандарты Е1А/Т1А-232 и Е1А/Т1А-449.

ETSI European Telecommunication Standards Institute. Европейский институт стандартов в области связи.

FIFO First In, First Out. Дисциплина обслуживания, при которой первой обслуживается та заявка, которая первой поступила в очередь.

FTP File Transfer Protocol. Протокол переноса файлов. GCP Gateway Control Protocol. Протокол управления шлюзом.

GK Gatekeeper. Привратник. Выполняет функции управления зоной сети Н.323.

GW Gateway. Шлюз. Аппаратно-программный комплекс, обеспечивающий обмен данными между сетями разных типов.

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



ICMP Internet Control Message Protocol Протокол управляющих сообщений в Интернет. Предоставляет программному обеспечению рабочей станции или маршрутизатора возможность обмениваться с другими устройствами информацией, относящейся к маршрутизации пакетов. Является необходимой частью стека протоколов TCP/IP.

IDCP IP Device Control Protocol. Протокол управления оборудованием, реализующим технологию маршрутизации пакетов IP. Предложен фирмой Level 3.

IEEE Institute of Electrical and Electronics Engineers. Институт инженеров электротехнической и электронной отраслей. Ведет исследования в области связи и разрабатывает коммуникационные и сетевые стандарты.

IETF Internet Engineering Task Force. Группа инженерных проблем Интернет. Включает в себя более 80 самостоятельных подгрупп, отвечает за разработку стандартов для Интернет. Устанавливает приоритеты и вырабатывает решения по краткосрочным вопросам и проблемам, включая протоколы, архитектуру и эксплуатацию. Работает под эгидой ISO.

IP Internet Protocol. Протокол межсетевого взаимодействия.

IPOP Internet Point of Presence. Точка присутствия поставщика услуг Интернет в коммутационном оборудовании.

ISO International Organization for Standardization. ISO - это не просто аббревиатура: греческое слово /so означает “равный”. ISO Основана в 1946 г. и представляет собой международную организацию, объединяющую более 75 национальных бюро разных стран. Разработала важнейшие стандарты, в том числе и компьютерные.

ISP Internet Service Provider. Поставщик услуг Интернет. Компания, предоставляющая доступ в Интернет другим компаниям или частным лицам.

ГГО-Т International Telecommunications Union Telecommunication Standardization Sector. Сектор Международного Союза Электросвязи, разрабатывающий рекомендации в области телекоммуникаций. Выполняет функции бывшего CCITT (МККТТ).

LDP Label Distribution Protocol. Протокол распределения меток. Поддерживает процедуры “раздачи” и согласования меток между маршрутизаторами сети MPLS.

LER Label Edge Router.


Пограничный маршрутизатор сети MPLS.

LPC Linear Prediction Coding. Кодирование с линейным предсказанием.

LSP Label Switched Path. Коммутируемый по меткам тракт.

LSR Label Switching Router. Маршрутизатор коммутации по меткам.

MCU Multipoint Control Unit. Устройство управления конференцией. Обеспечивает согласование функциональных возможностей участников конференции, то есть алгоритмов, используемых каждым из них для кодирования речи, видеоинформации и данных; может транскодировать информацию любого вида, если терминалы, участвующие в конференции, используют разные алгоритмы кодирования; в процессе согласования выбирает режим конференции. Производит смешивание или коммутацию информации, принимаемой от участников, и ее распределение.

MEGACO/Н.248 Протокол управления транспортным шлюзом. Создан рабочей группой MEGACO комитета IETF.

MG Media Gateway. Транспортный шлюз.

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

MOS Mean Opinion Score. Характеристика качества передачи речи с применением кодека того или иного типа, получаемая как среднее значение результатов оценки качества большой группой экспертов по пятибалльной шкале.

МР Multipoint processor. Процессор для обработки информации пользователей при централизованных конференциях.

MPLS Multi-Protocol Label Switching. Многопротокольная коммутация по меткам. Основана на том, что пакеты, поступающие в пограничный маршрутизатор сети MPLS извне, разделяются на “классы эквивалентности пересылки”. Каждому классу назначается система меток - коротких заголовков, используемых для маршрутизации пакетов внутри сети MPLS вместо длинных заголовков сетевого уровня.

Multicasting Многоадресная рассылка информации (аудио, видео или данных).

OPWA One Path With Advertising. Вариант алгоритма, который поддерживается протоколом RSVP. С помощью OPWA информация управляющих пакетов RSVP может быть использована для предсказания “сквозного” QoS всего маршрута.

OSI Open System Interconnection. Взаимодействие открытых систем.


Созданная ISO и ITU- T международная программа разработки стандартов сетевой передачи данных.

POTS Plain Old Telephone Service. Услуги традиционной телефонии.

РРР Point-to-Point Protocol. Протокол двусторонней связи. Используется при связи через Интернет. Реализует обмен пакетами между компьютерами или иными устройствами

PSTN Public Switched Telephone Network. Телефонная сеть общего пользования (ТфОП^. Общий термин, используемый для обозначения телефонных сетей во всем мире.

QCIF Quarter-Common Intermediate Format. Обязательный формат изображений, который должны обеспечивать кодеки.

QoS Quality of Service. Качество обслуживания (услуги).

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

RADIUS Remote Authentication Dial-In User Service. Протокол аутентификации и авторизации абонентов, а также убета объема предоставленных им услуг.

RAS Registration Admission and Status. Протокол взаимодействия терминального оборудования с привратником. Входит в семейство протоколов Н.323.

RSVP Resource Reservation Protocol. Протокол резервирования ресурсов.

RTCP Real-time Transport Control Protocol. Протокол контроля транспортировки информации в реальном времени. Организует обратную связь получателя информации с ее отправителем, используемую для обмена сведениями о числе переданных и потерянных пакетов, о задержке, ее джиттере и т.д. Эти сведения отправитель может использовать для изменения параметров передачи с целью улучшить QoS (например, уменьшить коэффициент сжатия информации).

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


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

SGSP Simple Gateway Control Protocol. Простой протокол управления шлюзами. Разработан компанией Telecordia (бывшая компания Bellcore).

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

SNMP Simple Network Management Protocol. Простой протокол эксплуатационного управления сетью.

TAPI Telephony Applications Programming Interface. Интерфейс для программирования телефонных приложений. Это - стандартный программный интерфейс для создания приложений компьютерной телефонии в среде Windows, определяющий набор функций, которые необходимы программе для взаимодействия с телефонами, линиями и коммутаторами. Стандарт TAPI используется при разработке приложений для рабочих станций, выполняющих все интеллектуальные действия.

TCP Transmission Control Protocol. Протокол управления передачей (данных). Основной транспортный протокол в стеке протоколов TCP/IP. Устанавливает связь между двумя компьютерами и организует надежный обмен данными в дуплексном режиме.

TCP/IP Transmission Control Protocol/Internet Protocol. Стек протоколов, обеспечивающих организацию связи между компьютерами в сети Интернет. Встроен в операционную систему UNIX и широко используется при операциях в сети Интернет, являясь de facto сетевым стандартом для передачи данных. Даже те сетевые операционные системы, которые имеют собственные протоколы, поддерживают также и TCP/IP.

TIPHON Telecommunications and Internet Protocol Harmonisation Over Networks. Проект под эгидой ETSI (начат в 1997 г), в котором участвует более 40 крупных компаний. Цель проекта - поддержка рынка, предусматривающего сочетание телекоммуникационных услуг сетей с коммутацией каналов и сетей с коммутацией пакетов.



Т8АР1 Telephony Services Application Programming Interface. API для создания телефонных услуг. Разработан Novell и AT&T. Позволяет программистам конструировать телефонные и CTI-приложения. Аналогичен TAPI, но, в отличие от него, функционирует на платформах Netware. Другое отличие - TAPI используется как для клиентских, так и для серверных приложений, a TSAPI предназначен исключительно для сервера.

UAC User Agent Client. Агент пользователя - клиент. Прикладная программа, которая инициирует SIP-запрос.

UAS User Agent Server. Агент пользователя - сервер. Прикладная программа, которая принимает запрос и от имени пользователя возвращает ответ с информацией о том, что запрос принимается, не принимается или переадресуется.

UDP User Datagram Protocol. Протокол передачи дейтаграмм пользователя. Подобно TCP, использует для доставки данных протокол IP. В отличие от TCP/IP, предусматривает обмен дейтаграммами без подтверждения (то есть доставка не гарантируется).

VAD Voice Activity Detector. Детектор речевой активности. Используется в кодеках со сжатием речевой информации для определения момента окончания паузы в речи.

VolP Voice over Internet Protocol. Технология, позволяющая использовать IP-сеть для передачи речевой информации.

WFQ Weighted Fair Queuing. Взвешенная справедливая очередь. Один из алгоритмов управления обслуживанием очередей.

Интернет аb ovo

Общеизвестна дата начала знаменитого проекта сети пакетной коммутации ARPA - прототипа сегодняшней сети Интернет. Это 1971 год. Однако сама идея сети Интернет имеет гораздо более давнюю историю. Чего стоит одно только определение сетевой структуры, данное Буддой: “Как сеть состоит из множества узлов, так и всё на этом свете связано узлами. Если кто-то полагает, что ячейка сети является чем-то независимым, изолированным, то он ошибается. Она называется сетью, поскольку состоит из множества взаимосвязанных ячеек, и у каждой ячейки своё место и свои обязательства по отношению к другим ячейкам”.

Реальная история Интернет началась, разумеется, спустя много веков после того, как появилось это определение. Авторы данной книги датируют ее начало 1957 годом - датой запуска первого советского искусственного спутника Земли. Именно в ответ на этот запуск США сформировали в составе Минобороны (Department of Defense - DoD) специальное агентство - Advanced Research Projects Agency (ARPA), создавшее сеть ARPANET - прообраз Интернет - и собравшее вокруг себя коллектив исследователей и ученых, заложивших основы сегодняшней сети Интернет. Таким образом, именно события, связанные с запуском первого советского спутника, стимулировали интеллектуальные усилия тысяч разработчиков и саму Интернет-революцию, которая сейчас сотрясает мир. Уже в июле 1961 года Леонард Клейнрок опубликовал первую статью по теории пакетной коммутации “Information Flow in Large Communication Nets”.

В 1964 году последовала работа Пола Барана (Paul Baran, RAND) “On Distributed Communications Networks”

В 1965 году, под эгидой ARPA, компьютеры двух организаций -ТХ-2 в MIT Lincoln Lab и AN/FSQ-32 в System Development Corporation (Santa Monica, CA) - были связаны выделенной телефонной линией на скорости 1200 бит/с. В октябре 1967 года в Гатлинбурге, штат Теннесси, на симпозиуме АСМ собрались представители трех независимых команд-ARPA, RAND e NPL. Последняя из них, Национальная физическая лаборатория (National Physical Laboratory- NPL), построившая экспериментальную сеть пакетной коммутации на скорости 768 Кбит/с, более известна тем, что руководитель разработки Дональд Дэвис является автором термина “пакет”.

В 1969 году на основе мини-компьютера DDP-516 фирмы Honey-well с памятью объемом 12К были созданы четыре первых узла сети ARPANET: Калифорнийский университет в Лос-Анжелесе (University of California Los Angeles - UCLA), Стэнфордский НИИ (Stanford Research Institute - SRI), университет Санта-Барбары и университет штата Юта. Компания AT&T предоставила для этой сети линии со скоростью передачи 50 Кбит/с. Первые пакеты данных были переданы Чарли Клайном (Charley Kline) из UCLA, когда он пытался связаться с компьютером SRI. Первая попытка 29 октября 1969 г. закончилась аварийным отказом системы во время ввода буквы G из слова LOGIN. Пикантность ситуации заключалась в том, что ARPANET определялась как полностью отказоустойчивая компьютерная сеть с распределением вычислительной мощности и резервированием устройств коммутации данных и компьютерных линий связи, способная выдержать ядерный удар. Тогда же первым проектом документа RFC (Request for Comments) “Программное обеспечение рабочих станций (hosts)” было положено начало стандартам Интернет.

Первая публикация, относящаяся к сети Интернет, появилась в 1970 году и была посвящена протоколу взаимодействия рабочих станций в составе сети ARPANET: Ч.Кар, С.Крокер, В.Серф. “Протокол связи рабочих станций в сети ARPA”.

В 1971 году уже имеется 15 узлов (23 рабочие станции), и Рей Момлинсон изобретает программу электронной почты для передачи сообщений по распределенной сети. Оригинальная программа была создана на базе двух программ: программы внутримашинной электронной почты (SENDMSG) и экспериментальной программы пересылки файлов (CPYNET). Из клавиш пунктуации на телетайпе Model 33 производства Tomlinson в марте 1972 г. выбран знак @ в его значении “в”.

Докторская диссертация Боба Меткафа из Гарварда наметила идею сети Ethernet. Эта идея была проверена на компьютерах Alto производства Xerox PARC, и первая сеть Ethernet получила в мае 1973 г. название Alto Aloha System. А число пользователей ARPANET к марту 1973 достигло 2000.


Тогда же в Мичиганском университете создается сеть Merit на базе протокола Х.25, а в Стэнфордском университете начинается разработка набора протоколов, которые должны обеспечивать взаимодействие компьютеров, включённых в сеть ARPANET.

В мае 1974 года Винт Серф из Стэнфорда и Боб Кан (Vint Cerf, Bob Kahn) из агентства перспективных научных проектов Министерства обороны США опубликовали в журнале “IEEE Transactions on Communications” статью “A Protocol for Packet Network Intercommunication” со спецификацией протокола TCP, ставшей вскоре основой Интернет. Об истории этой публикации рассказывается в колонке редактора журнала “Сети и системы связи” (№11, 1999). Серф и Кан решали, чье имя поставить первым в спецификации протокола TCP, и бросили монетку. Первым оказался Винсент Серф, и именно он, со временем, стал известен широкой публике, занял должность вице-президента MCI и получил признание как один из основателей сети Интернет.

Тогда же появляется первый список адресов электронной почты - MsgGroup. Самым популярным неофициальным списком становится список любителей научной фантастики - SF-Lovers. Спустя полтора года разрабатывается спецификация электронной почты (RFC 733). В 1976 году в лаборатории Александра Белла (Bell Laboratories) корпорации AT&T разрабатывается протокол UUCP (Копирование Unix-Unix), который начинает распространяться год спустя вместе с операционной системой UNIX.

В 1978 году протокол TCP разделяется на протоколы TCP и IP, а изложенная в статье Серфа и Кана концепция получает название TCP/IP. Работа над концепцией была завершена в 1980 году, а в 1983 году управление Минобороны США утвердило новый набор компьютерных протоколов в качестве стандарта для ARPANET, вместо протокола NCP (Network Control Protocol), использовавшегося с 1970 года. Чтобы поощрить переход колледжей и университетов на технологию TCP/IP, силами ARPA был облегчен процесс внедрения операционной системы Berkeley UNIX, реализующей протоколы TCP/IP. Этот шаг привел к формированию одного из первых определений понятия “Интернет” как совокупности соединенных между собой сетей, в частности, сетей с использованием стека протоколов TCP/IP, а понятия “Интернет” как совокупности сетей, реализованных на базе технологии TCP/IP.



Сама же ARPANET в конце 1983 года разделилась на две сети:

DARPANET (оборонная сеть) и MILNET (военная сеть). Несмотря на то, что ARPANET официально прекратила своё существование в июне 1990 года, сеть Интернет уцелела. Более того, протокол TCP/IP был усовершенствован и стал чрезвычайно популярен в сферах образования, научно-исследовательских разработок, в коммерции и во многих, многих других, порой неожиданных применениях, примером чему является эта книга. В 1984 году вводится система доменных имен (DNS). Она увязывает IP-адреса с именами компьютеров в Интернет. И в том же 1984 году Уильям Гибсон, в романе “Necromancer”, вводит термин “гиперпространство”. Количество рабочих станций, подключенных к сети, достигает 1000, а к 1987 году их становится уже 10000.

Национальный фонд Науки США, с целью обеспечить взаимодействие своих суперкомпьютерных центров и доступ к Интернет, создает в 1985 году сеть NSFNET (Сеть Национального фонда науки). NSFNET - это высокоскоростная магистральная сеть, состоящая из двухточечных линий связи в узловой конфигурации. Сеть была полностью развёрнута в 1988 году и первоначально работала на скорости 56 Кбит/с. В 1986 году NSFNET организовала ряд региональных сетей, объединённых в магистральную сеть. Позже основные части сети NSFNET были модернизированы для работы на скоростях до ОС-3 (155 Мбит/с) и выше. NSFNET официально прекратила своё существование в 1995 году, и на смену ей пришла сеть MERIT. Первоначально, MERIT была сетью масштаба штата, эксплуатируемой Университетом Мичигана, и региональным компонентом как сети NSFNET, так и Интернет.

В 1988 году Ажако Ойкаринен (Jarkko Oikari-nen) разрабатывает технологию Internet Relay Chat (IRC). Тогда же появился новый термин “хакер”, а 1 ноября 1988 года вирусная программа “Internet Worm” сумела повредить более 6000 рабочих станций.

В 1989 году количество рабочих станций достигает 100000 штук, а в 1990 году - 300000. Появляется первый коммерческий поставщик услуг сети Интернет, а год спустя Тим Бернерс-Ли (Tim Ber-ners-Lee) из организации CERN, Швейцария, выпускает свою разработку Всемирной Паутины - World Wide Web (WWW).


Вскоре программы просмотра WWW стали неотъемлемой частью повседневной жизни, и началась эра бизнеса в сети Интернет. В 1992 году количество рабочих станций превысило 1 миллион, а в 1993 году в Интернет появился адрес www.whitehouse.gov и электронная почта president@whitehouse.gov Б. Клинтона. Понадобилось менее 2 лет, чтобы в Интернет появились адреса правительств большинства других стран, включая, например, адрес Ватикана - www.vatican.va. В том же 1995 году коллектив программистов Sun Microsystems под руководством Джеймса Гозлинга (James Gosling) создали язык программирования Java, радикально изменивший сам смысл программирования Интернет-приложений.

В 1996 году сети Интернет исполнилось 25 лет, а число рабочих станций, подключенных к Интернет, составило 10 миллионов.

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

Эхо

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

Эхо может иметь электрическую и акустическую природу.

Отражения в дифсистеме являются неотъемлемым свойством ТфОП. Поэтому они проявляются при взаимодействии ТфОП и IP-сетей.

С целью экономии кабеля в ТфОП для подключения абонентских терминалов с давних пор используются двухпроводные линии, по которым речевые сигналы передаются в обоих направлениях. Более того, во многих телефонных сетях передача сигналов обоих направлений по двум проводам используется и в соединительных линиях между электромеханическими АТС [6] (хотя теперь для организации связи между АТС всё чаще используется раздельная передача сигналов разных направлений, т.е. четырехпроводная схема их передачи). Для разделения сигналов разных направлений в терминалах абонентов (телефонных аппаратах) и на АТС применяются простые мостовые схемы, называемые дифсистемами (hybrid). Работа этих мостовых схем основывается на согласовании импедансов в плечах моста, одним из плеч которого является двухпроводная абонентская линия. Так как абонентские линии могут очень сильно различаться по своим параметрам (длине, диаметру жил кабеля и т.п.), то достичь точного согласования (тем более, во всей полосе передаваемых частот) невозможно. Вместо этого администрация связи вынуждена ориентироваться на некоторую среднюю величину импеданса для всех абонентских линий своей национальной сети. Это приводит к тому, что сигналы прямого и обратного направления в большинстве случаев не разделяются полностью, и в дифсистеме возникает частичное отражение сигналов.

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

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

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

3.1.3 Устройства ограничения эффектов эха

Существуют два типа устройств, предназначенных для ограничения вредных эффектов эха: эхозаградители и эхокомпенсаторы.

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

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


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

Рис. 3.3 Упрощенная блок-схема эхокомпенсатора

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

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

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



3.2 Принципы кодирования речи

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

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

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

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

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



Рис. 3.4 Дискретизация и квантование аналогового речевого сигнала

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

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

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

После длительных и бурных дебатов в отношении законов кодирования сегодня применяются две основные разновидности ИКМ:

с кодированием по (m-закону и по А-закону. В результате сжатия сигнал с амплитудой, кодируемой 12-13 битами, описывается всего восемью битами. Различаются эти разновидности ИКМ деталями процесса сжатия (m-закон кодирования предпочтительнее использовать при малой амплитуде сигнала и при малом отношении сигнал/шум). Исторически сложилось так, что в Северной Америке используется кодирование по m-закону, а в Европе - по А-закону. Поэтому при международной связи во многих случаях требуется преобразование m-закона в А-закон, ответственность за которое несет страна, в которой используется m-закон кодирования. В обоих случаях каждый отсчет кодируется 8 битами, или одним байтом, который можно считать звуковым фрагментом. Для передачи последовательности таких фрагментов необходима пропускная способность канала, равная 64 Кбит/с. Это определяется простыми арифметическими действиями: 4 000 Гц * 2 = 8 000 отсчетов/с, 8 000 отсчетов/с * 8 битов = 64 Кбит/с, что составляет основу всей цифровой телефонии.


Поскольку ИКМ была первой стандартной технологией, получившей широкое применение в цифровых системах передачи, пропускная способность канала, равная 64 Кбит/с, стала всемирным стандартом для цифровых сетей всех видов, причем - стандартом, который обеспечивает передачу речи с очень хорошим качеством. Соответствующие процедуры кодирования и декодирования стандартизованы ITU-T в рекомендации G.711.

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

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

Существует множество подходов к “сжатию” речевой информации; все их можно разделить на три категории: кодирование формы сигнала (waveform coding), кодирование исходной информации (source coding) и гибридное кодирование, представляющее собой сочетание двух предыдущих подходов.

3.2.1 Кодирование формы сигнала

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

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



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

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

Если отсчеты входного сигнала обозначить как y(i), то предсказанное значение в момент времени i представляет собой линейную комбинацию нескольких р предыдущих отсчетов:

y(i)=a,y(i-1)+a;,y(i-2)+...+apy(i-p) где множители а, называются коэффициентами предсказания.

Разность e(i)=y(i)-y(i) имеет меньший динамический диапазон и может кодироваться меньшим числом битов, что позволяет снизить требования к полосе пропускания.

Описанный метод называется линейным предсказанием, так как он использует только линейные функции предыдущих отсчетов. Коэффициенты предсказания выбираются так, чтобы минимизировать среднеквадратическое значение ошибки предсказания e(i), при этом значения коэффициентов изменяются, в среднем, каждые 10-25 мс.

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



Наиболее совершенным алгоритмом, построенным на описанных выше принципах, является алгоритм адаптивной дифференциальной импульсно-кодовой модуляции (АДИКМ), предложенный ITU-T в рекомендации G.726. Алгоритм предусматривает формирование сигнала ошибки предсказания и его последующее адаптивное квантование. Существует версия этого алгоритма, в которой информационные биты выходного цифрового потока организованы по иерархической схеме, что позволяет отбрасывать наименее значимую информацию, не уведомляя об этом кодер, и получать поток меньшей скорости за счет некоторого ухудшения качества. Документ G.726 специфицирует кодирование при скоростях 40, 32, 24 и 16 Кбит/с, что соответствует передаче 5, 4, 3 или 2 битов на отсчет. Качество речи, передаваемой с использованием АДИКМ G.726 при скорости 32 Кбит/с соответствует качеству речи, обеспечиваемому алгоритмом кодирования G.711.

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

3.2.2 Кодеры исходной информации (вокодеры) и гибридные алгоритмы

Многие методы кодирования используют особенности человеческой речи, связанные со строением голосового аппарата. Кодеры, в которых реализуются такие методы, называют кодерами исходной информации или вокодерами (voice coding).

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


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

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

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

Рис. 3.5 Модель функционирования голосового тракта

Описанный принцип кодирования получил название LPC (Linear Prediction Coding - кодирование с линейным предсказанием), поскольку центральным элементом модели голосового тракта является линейный фильтр. Наиболее известный стандартный алгоритм, построенный по описанному принципу, был стандартизован министерством обороны США под названием LPC-10, где число 10 соответствует количеству коэффициентов фильтра. Данный кодер обеспечивает очень низкую скорость передачи информации 2.4 Кбит/с, однако качество воспроизводимых речевых сигналов оставляет желать лучшего и не удовлетворяет требованиям коммерческой речевой связи - речь носит ярко выраженный “синтетический” характер.

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


LPC-кодеры (вокодеры) используют простую математическую модель голосового тракта и позволяют использовать очень низкие скорости передачи информации 1200-2400 бит/с, однако ценой “синтетического” характера речи.

Гибридные алгоритмы кодирования и алгоритмы типа “анализ путем синтеза” (ABS) представляют собой попытки совместить положительные свойства двух описанных выше основных подходов и строить эффективные схемы кодирования с диапазоном скоростей передачи битов 6-16Кбит/с.

Важное отличие кодеров такого типа состоит в том, что в рамках этих алгоритмов нет необходимости принимать решение о типе воспроизводимого звука (тоновый или нетоновый), так как предусматриваются специальные меры для кодирования сигнала ошибки после прохождения возбуждения через LPC-фильтр. Например, сигнал ошибки может быть закодирован по алгоритму, аналогичному АДИКМ, что обеспечит высокую точность его передачи. ABS-кодеры не могут быть строго классифицированы как кодеры формы сигнала, однако реально целью процедуры минимизации ошибки (рис. 3.6), т.е. различия между входным и синтезированным сигналами, является синтез на выходе кодера сигналов, форма которых наиболее близка к форме входных. ABS-декодер является малой частью кодера и очень прост (рис. 3.7).

Рис. 3.6 Упрощенная блок-схема ABS-кодера

Рис. 3.7 Упрощенная блок - схема ABS - декодера

3.2.3 Процессоры цифровой обработки сигналов для речевых кодеков

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

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



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

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

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

Одними из самых известных производителей DSP являются фирмы Texas Instruments (www.ti.com). Analog Devices (www.analog.com). Motorola (www.motorola.com). на сайтах которых можно получить дополнительную информацию о номенклатуре DSP и об их применении.

Оборудование ПРОТЕЙ-1Р использует DSP с лицензированным у одной из ведущих в дан ной области фирм программным обеспечением, реализующим необходимые алгоритмы (речевые кодеки, факс, модем). Это позволило, опираясь на существующий опыт, резко сократить время выхода оборудования на рынок.Кроме того, в данном случае исключается трудоемкая и длительная процедура лицензирования алгоритмов речевых кодеков (G.723.1, G.729), требующая значительных единовременных финансовых затрат. По такому же пути идут и ведущие мировые производители оборудования VolP (Cisco, Dialogic и др.), лицензируя программное обеспечение DSP у компаний, специализирующихся именно в этой области, и концентрируя свои силы на реализации тех функций, которые традиционно обеспечивают данным производителям оборудования технологическое лидерство.

Качество обслуживания в сетях IP-телефонии

Глава 10 Качество обслуживания в сетях IP-телефонии

10.1 Что понимается под QoS?

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

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

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

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

Вместе с тем, налицо необходимость получения от сети гарантий, что в периоды перегрузки пакеты с информацией, чувствительной к задержкам, не будут простаивать в очередях или, по крайней мере, получат более высокий приоритет, чем пакеты с информацией, не чувствительной к задержкам.
Иначе говоря, необходимо гарантировать доставку такой информации, как речь, видео и мультимедиа, в реальном времени с минимально возможной задержкой. Для этой цели в сети должны быть реализованы механизмы, гарантирующие нужное качество обслуживания (Quality of Service - QoS). Анализу таких механизмов и посвящена эта глава.

Идеальной была бы следующая ситуация. Приложение “договаривается” с сетью о том, что пакеты такого-то потока данных со средней скоростью передачи Х Кбит/с будут доставляться от одного конца соединения к другому с задержкой не более Y мс, и что сеть в течение всего соединения будет следить за выполнением этого договора. Кроме указанной характеристики, сеть должна поддерживать согласованные значения таких параметров передачи как минимально доступная полоса частот, максимальное изменение задержки (джиттер), максимальные потери пакетов.

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

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

Чтобы добиться гарантий качества обслуживания от сетей, изначально на это не ориентированных, необходимо “наложить” на сеть так называемую QoS-архитектуру, которая включает в себя поддержку качества на всех уровнях стека протоколов TCP/IP и во всех сетевых элементах.


Но и при этом обеспечение гарантированного качества обслуживания все равно остается самым слабым местом процесса передачи информации от источника к приемнику.

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

Кроме того, качество обслуживания - это относительное понятие;

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

10.2 Качество обслуживания в сетях пакетной коммутации

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

В сетевых узлах (коммутаторах пакетов) высокоскоростных транспортных сетей Frame Relay проверка и коррекция ошибок не производятся. Эти функции возложены на оборудование пользователя, вследствие чего задержка при передаче информации по таким сетям намного ниже, чем в сетях X. 25.

Одной из широко известных технологий пакетной передачи с гарантированным качеством обслуживания является транспортная технология ATM. И хотя не так давно на ATM возлагались огромные надежды (предполагалось, например, использование ATM в качестве базы для широкополосных сетей ISDN), эта технология не получила широкого распространения из-за своей сложности и высокой стоимости оборудования.


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

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

10.3 Трафик реального времени в IP-сетях

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

Телефонный разговор - это интерактивный процесс, не допускающий больших задержек. В соответствии с рекомендацией ITU-T G. 114 для большинства абонентов задержка речевого сигнала на 150 мс приемлема, а на 400 мс - недопустима.

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



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

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

Как правило, с корпоративными сетями все обстоит сравнительно просто. Они имеют ограниченные размеры и контролируемую топологию, а характер трафика обычно бывает известен заранее. Возьмем простой пример: речь передается по существующей ЛВС, которая слишком загружена, чтобы обеспечить приемлемое качество обслуживания. Решением этой проблемы будет изоляция серверов и клиентов, работающих с графиком данного типа, и сегментация сети. Разбить сеть на сегменты можно, либо установив коммутатор Ethernet, либо добавив порты в маршрутизатор.

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

В сетях традиционных операторов обслуживается трафик разных видов, поэтому в таких сетях, чтобы обеспечить приемлемое качество, целесообразно применять дифференцированное обслуживание разнотипного трафика (Diff-Serv).

10.4 Дифференцированное обслуживание разнотипного трафика - Diff-Serv

Для обеспечения гарантированного качества обслуживания комитет IETF разработал модель дифференцированного обслуживания разнотипного трафика - Diff-Serv.


В соответствии с этой моделью байт ToS (Type of Service) в заголовке IP-пакета получил другое название DS (Differentiated Services), а шесть его битов отведены под код Diff-Serv. Каждому значению этого кода соответствует свой класс PHB (Per-Hop Behavior Forwarding Class), определяющий уровень обслуживания в каждом из сетевых узлов. Пакеты каждого класса должны обрабатываться в соответствии с определенными для этого класса требованиями к качеству обслуживания.

Модель Diff-Serv описывает архитектуру сети как совокупность пограничных участков и ядра. Пример сети согласно модели Diff-Serv приведен на рисунке 10.1.

Рис. 10.1 Модель Diff-Serv

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

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

• класс срочной пересылки пакетов (Expedited Forwarding PHB Group);

• класс гарантированной пересылки пакетов (Assured Forwarding PHB Group).

Механизм обеспечения QoS на уровне сетевого устройства, применяемый в Diff-Serv, включает в себя четыре операции. Сначала пакеты классифицируются на основании их заголовков. Затем они маркируются в соответствии с произведенной классификацией (в поле Diff-Serv). В зависимости от маркировки выбирается алгоритм передачи (при необходимости - с выборочным удалением пакетов), позволяющий избежать заторов в сети.


Заключительная операция, чаще всего, состоит в организации очередей с учетом приоритетов[15].

Хотя эта модель и не гарантирует качество обслуживания на 100%, у нее есть серьезные преимущества. Например, нет необходимости в организации предварительного соединения и в резервировании ресурсов. Атак как в модели Diff-Serv используется небольшое, фиксированное количество классов и трафик абонентов распределяется по общим очередям, не требуется высокая производительность сетевого оборудования.

10.5 Интегрированное обслуживание IntServ

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

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

Класс контролируемой загрузки сети идентичен традиционному подходу “best effort”, но уровень QoS для уже обслуживаемого потока данных остается неизменным при увеличении нагрузки в сети.

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

Спецификация потока (flow specification) нужна для определения необходимого уровня качества обслуживания потока.

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


Этому протоколу посвящен следующий параграф.

Рис. 10.2 Модель IntServ

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

10.6.1 Общие принципы протокола

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

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

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

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

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



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

В основе протокола RSVP лежат три компонента:

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

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

• спецификация фильтра, определяющая тип графика, для обслуживания которого запрашивается ресурс.

10.6.2 Процедура резервирования ресурсов

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

Сообщение Path должно нести в себе шаблон данных отправителя (Sender Template), описывающий тип этих данных. Шаблон специфицирует фильтр, который отделяет пакеты данного отправителя от других пакетов в пределах сессии (по IP-адресу отправителя и, возможно, по номеру порта). Кроме того, сообщение Path должно содержать спецификацию потока данных отправителя Tspec, которая определяет характеристики этого потока.


Спецификация Tspec используется, чтобы предотвратить избыточное резервирование.

Шаблон данных отправителя имеет тот же формат, что и спецификация фильтра в сообщениях Resv (см. ниже).

Приняв сообщение Path, его получатель передает к маршрутизатору, от которого пришло это сообщение (т.е. по направлению к отправителю), запрос резервирования ресурсов - сообщение Resv. В дополнение к информации Tspec, сообщение Resv содержит спецификацию запроса (Rspec}, в которой указываются нужные получателю параметры качества обслуживания, и спецификацию фильтра (filter-spec), определяющую, к каким пакетам сессии относится данная процедура (по IP-адресу отправителя и, возможно, по номеру порта).

Когда получатель данных передает запрос резервирования, он может запросить передачу ему ответного сообщения, подтверждающего резервирование.

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

Если же запрос приемлем, данные о требуемом качестве обслуживания поступают для обработки в соответствующие функциональные блоки (способ обработки параметров QoS маршрутизатором в протоколе RSVP не определен), и маршрутизатор передает сообщение Resv следующему (находящемуся ближе к отправителю данных) маршрутизатору. Это сообщение несет в себе спецификацию flow/spec, содержащую два набора параметров:

• “Rspec”, который определяет желательное QoS,

• “Tspec”, который описывает информационный поток.

Вместе flowspec и filterspec представляют собой дескриптор потока, используемый маршрутизатором для идентификации каждой процедуры резервирования ресурсов.



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

После окончания вышеописанной процедуры ее инициатор начинает передавать данные и на их пути к получателю будет обеспечено заданное QoS.

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

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

Протокол RSVP поддерживает улучшенную версию однопроходного варианта алгоритма, известного под названием OPWA (One Path With Advertising) (OPWA95). С помощью OPWA управляющие пакеты RSVP, передаваемые вдоль маршрута, могут быть использованы для переноса данных, которые позволяют предсказывать QoS маршрута в целом.



Рис. 10.3 Резервирование ресурсов при помощи протокола RSVP

Сточки зрения узла сети работа протокола RSVP выглядит так:

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

2. Отправитель передает сообщение по адресу группы;

3. Получатель принимает сообщение Path, идентифицирующее отправителя;

4. Теперь получатель имеет информацию об обратном пути и может отправлять сообщение Resv с дескрипторами потока;

5. Сообщения Resv передаются по сети отправителю;



6. Отправитель начинает передачу данных;

7. Получатель начинает передачу данных.

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

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

Протокол RSVP работает с пакетами IP и не затрагивает схем сжатия, циклического контроля (CRCs) или работы с кадрами уровня звена данных (Frame Relay, PPP, HDLC).

Например, при использовании для IP-телефонии алгоритма кодирования речи G.729, обеспечивающего, с учетом сжатия заголовков RTP-пакетов, передачу речи со скоростью около 11 Кбит/с, в оборудовании Cisco по протоколу RSVP резервируется ресурс с пропускной способностью 24 Кбит/с. Другими словами, в канале с пропускной способностью 56 Кбит/с разрешено резервировать ресурс только для двух потоков со скоростью 24 Кбит/с каждый, даже если полоса пропускания располагает ресурсом для трех потоков со скоростью 11 Кбит/с каждый. Чтобы обойти это ограничение, можно применить следующий прием. Средствами эксплуатационного управления функциональному блоку RSVP маршрутизатора сообщается, например, что канал с фактической полосой пропускания 56 Кбит/с имеет, якобы, пропускную способность 100 Кбит/с и что допускается использовать для резервирования 75% его полосы пропускания. Такой “обман” разрешит протоколу RSVP резервировать полосу пропускания, которая необходима для трех речевых потоков, закодированных по алгоритму G.729. Очевидно, что при этом есть опасность перегрузки канала с реальной полосой 56 Кбит/с, если сжатие заголовков RTP-пакетов не применяется.

10.7 Технология MPLS

Технология многопротокольной коммутации по меткам (Multiprotocol Label Switching - MPLS), разработанная комитетом IETF, явилась результатам слияния нескольких разных механизмов, таких как IP Switching (Ipsilon), Tag Switching (Cisco Systems), Aris (IBM) и Cell Switch Router (Toshiba).


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

В обычных IP-сетях любой маршрутизатор, находящийся на пути следования пакетов, анализирует заголовок каждого пакета, чтобы определить, к какому потоку этот пакет относится, и выбрать направление для его пересылки к следующему маршрутизатору. При использовании технологии MPLS соответствие между пакетом и потоком устанавливается один раз, на входе в сеть MPLS. Более точно, соответствие устанавливается между пакетом и так называемым “классом эквивалентности пересылки” FEC (Forwarding Equivalence Class);

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

Использование меток значительно упрощает процедуру пересылки пакетов, так как маршрутизаторы обрабатывают не весь заголовок IP-пакета, а только метку, что занимает значительно меньше времени.

На рис. 10.4 показана, в качестве примера, простейшая MPLS-сеть, содержащая маршрутизаторы двух типов:

• пограничные маршрутизаторы MPLS (Label Edge Routers - LER),

• транзитные маршрутизаторы MPLS (Label Switching Routers - LSR).

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




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

Рис. 10.4 Сеть, построенная на базе технологии MPLS

Последовательность (LER^, LSR,,..., LSR„, LER^) маршрутизаторов, через которые проходят пакеты, принадлежащие одному FEC, образует виртуальный коммутируемый по меткам тракт LSP (Label Switched Path). Так как один и тот же LER для одних потоков является входным, а для других-выходным, в сети, содержащей N LER, в простейшем случае может существовать N(N-1) FEC и, соответственно, N(N-1)LSP.

Заметим, однако, что потоки пакетов из разных FEC, приходящие к одному выходному LER от разных входных LER, могут в каких-то LSR сливаться в более мощные потоки, каждый из которых образует новый FEC со своей системой меток. Возможно и обратное, то есть группа потоков может идти до некоторого LSR по общему маршруту и, следовательно, принадлежать одному и тому же FEC, а затем разветвиться, и тогда каждая ветвь будет иметь свой FEC (со своей системой меток). Кроме того, существует возможность образования внутри некоторого LSP одного или нескольких вложенных в него LSP (так называемых LSP-туннелей).

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

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



Итак, метка, помещаемая в некоторый пакет, представляет FEC, к которому этот пакет относится. Как правило, отнесение пакета к определенному классу производится на основе сетевого адреса получателя. Метка может быть помещена в пакет разными способами -вписываться в специальный заголовок, “вставляемый” либо между заголовками уровня звена данных и сетевого уровня, либо в свободное и доступное поле заголовка какого-то одного из этих двух уровней, если таковое имеется. В любом случае этот специальный заголовок содержит поле, куда записывается значение метки, и несколько служебных полей, среди которых имеется и то, которое представляет особый интерес с точки зрения данной главы - поле QoS (три бита, т.е. до восьми классов качества обслуживания).

Метки для каждого FEC всегда назначаются “снизу”, то есть либо выходным LER, либо тем LSR, который является для этого FEC “нижним” (расположенным ближе к адресату), и распределяются им по тем маршрутизаторам, которые расположены “выше” (ближе к отправителю).

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

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


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

Для распределения меток может использоваться либо специальный протокол LDP (Label Distribution Protocol), либо модифицированная версия одного из существующих протоколов сигнализации (например, протокола RSVP).

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

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

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

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




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

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

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

• организации очереди;

• обработки очередей.

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

Существует два основных алгоритма организации очереди:

Tail Drop и Random Early Detection.

10.8.1.1 Алгоритм Tail Drop

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

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

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

Алгоритм Tail Drop приводит к тому, что очереди оказываются заполненными (или почти заполненными) в течение длительного периода времени. Так происходит, поскольку алгоритм сигнализирует только о том, что очередь полна.


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

Имеются альтернативные алгоритмы отбрасывания пакетов: Random Drop (отбрасывание случайно выбранного) и Drop from Front (отбрасывание первого). Принцип работы алгоритма Random Drop понятен из его названия. При заполнении очереди отбрасывается не пакет, пришедший последним, а пакет, выбираемый из очереди случайно. Такой алгоритм предъявляет более высокие требования к вычислительным ресурсам маршрутизатора, поскольку он производит с очередью более сложные операции. Алгоритм Drop from Front отбрасывает пакет, стоящий в очереди первым. Помимо значительного снижения вероятности “локаута”, этот алгоритм выгодно отличается от алгоритма Tail Drop тем, что при использовании протокола TCP рабочая станция раньше узнает о перегрузке в сети и, соответственно, раньше снижает скорость передачи пакетов.

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

Суть алгоритма в том, что когда размер очереди превышает некоторое пороговое значение, прибывающий пакет отбрасывается с вероятностью, зависящей оттого, насколько превышен установленный порог. Обычно предусматривается два пороговых значения. Когда длина очереди переходит за первый порог, вероятность отбрасывания пакета линейно возрастает от 0 (у первого порога) до 1 (у второго порога). Положение второго порога выбирается с таким расчетом, чтобы в оставшемся после него “хвосте” очереди мог поместиться пакет, длина которого несколько превышает среднюю. По мере приближения длины очереди ко второму порогу, растет вероятность того, что прибывший пакет будет отброшен в связи с тем, что он не умещается в очереди (несмотря на наличие “хвоста”), при этом пакеты большего размера имеют больше шансов быть отброшенными, чем пакеты меньшего размера.



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

10.8.2 Алгоритмы обработки очередей

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

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

10.8.2.1 Стратегия FlFO

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

Рис. 10.5 Очередь FIFO

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

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

Очередь с приоритетами (Priority Queuing) - это алгоритм, при котором несколько очередей FIFO (могут использоваться алгоритмы Tail Drop, RED и т.д.) образуют одну систему очередей. В случае “ простейшего приоритетного обслуживания трафик определенных классов имеет безусловное преимущество перед графиком других классов. Например, если все IPX-пакеты имеют более высокий приоритет, чем IP-пакеты, то какова бы ни была ценность IP данных, IPX данные будут иметь первоочередной приоритет при разделе доступной полосы. Такой алгоритм гарантирует своевременную доставку лишь наиболее привилегированного трафика.



Рис. 10.6 Очереди с приоритетами

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


Пакет каждого потока помещается в очередь, имеющую соответствующий приоритет.

Хотя трафик более высокого приоритета получает лучшее обслуживание, чем он мог бы получить при использовании FIFO, некоторые фундаментальные проблемы остаются нерешенными. Например, если используются очереди Tail Drop, то остаются проблемы больших задержек, “локаута” и т.д. Некоторые прикладные программы пытаются использовать весь доступный ресурс. Если им предоставлена наиболее приоритетная очередь, то очереди с низким приоритетом будут блокированы в течение длительного времени, или же низкоприоритетный трафик встретит настолько большую задержку в результате следования по окружному пути, что станет бесполезным. Это может привести к прекращению менее приоритетных сеансов связи или, по крайней мере, сделает их практически непригодными.

10.8.2.3 Class-Based Queuing (CBQ)

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

Обработка очередей по алгоритму Class-Based Queuing, CBQ предполагает, что трафик делится на классы. Определение класса трафика в значительной степени произвольно. Класс может представлять весь трафик, проходящий через данный интерфейс, трафик определенных приложений, трафик, направленный к заданному подмножеству получателей, трафик с качеством услуг, гарантированным протоколом RSVP. Каждый класс имеет собственную очередь, и ему гарантируется, по крайней мере, некоторая доля пропускной способности канала. Драйвер интерфейса обходит все очереди по кругу и передает некоторое количество пакетов из каждой очереди. Если какой-либо класс не исчерпывает предоставленный ему лимит пропускной способности, то доля полосы пропускания, выделяемая каждому из остальных классов, пропорционально увеличивается.

Алгоритм CBQ использует иерархическую организацию классов.


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

Как и в предыдущем случае, используются очереди FIFO, следовательно, для потоков, разделяющих одну очередь, остаются проблемы, присущие FIFO, но гарантируется некоторая справедливость распределения ресурсов в сети между разными очередями. Кроме того, в отличие от приоритетного обслуживания, CBQ не допускает блокировки очереди и дает возможность учитывать использование сети разными классами.

Рис. 10.7 Иерархия классов при использовании алгоритма CDQ

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

Если необходимо обеспечить для всех потоков постоянное время задержки, и не требуется резервирование полосы пропускания, то можно воспользоваться алгоритмом Weighted Fair Queuing.

Рис. 10.8 Взвешенные очереди

Взвешенная справедливая очередь (Weighted Fair Queuing, WFQ) является частным случаем CBQ, когда каждому классу соответствуют свой поток (ТСР-сеанс и т.д.). Как и в случае CBQ, каждому классу WFQ отводится одна очередь FIFO и гарантируется некоторая часть пропускной способности канала, в соответствии с весовым коэффициентом потока. Если некоторые потоки не используют предоставленную им полосу пропускания полностью, то другие потоки соответственно увеличивают свою долю. Так как в данном случае каждый класс - это отдельный поток, то гарантия пропускной способности эквивалентна гарантии максимальной задержки. Зная параметры сообщения, можно по известным формулам вычислить его максимальную задержку при передаче по сети. Выделение дополнительной пропускной способности позволяет уменьшить максимальную задержку.

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




Определение веса потока производится по полю precedence заголовка IP-пакета. Значение данного поля лежит в пределах от 0 до 7. Чем выше значение, тем большая полоса выделяется потоку.

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

10.8.3 Алгоритмы сглаживания пульсации графика

10.8.3.1 Алгоритм Leaky Bucket

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

Представим себе ведро, в котором накапливаются данные, получаемые от отправителя. В днище ведра имеются отверстия, через которые данные “вытекают” из него для дальнейшей обработки (или передачи). Через определенные интервалы времени подсчитывается объем данных, которые накопились в ведре в течение интервала, предшествовавшего моменту подсчета. Если объем не превышает порога В, всплеск скорости передачи данных внутри этого интервала считается нормальным, и никаких действий не производится. Если объем накопившихся данных превысил порог В, все пакеты, оказавшиеся выше порога, но ниже краев ведра, снабжаются меткой DE (Discard Eligibility), а те, которые не поместились в ведре, отбрасываются. В следующем интервале данные продолжают поступать в ведро и вытекать из него в обычном порядке (независимо от наличия меток), но если ведро переполняется, то отбрасываются не вновь поступающие пакеты, а пакеты с меткой DE, которые еще не успели вытечь. Если при следующем подсчете окажется, что объем данных в ведре ниже порога В, то никаких действий не производится. Если порог превышен, и в числе пакетов, оказавшихся выше порога, имеются пакеты без метки DE, они получают такую метку.

Рис. 10.9 Алгоритм "Leaky Bucket"

Одна из версий этого алгоритма, называемая Generic Cell Rate Algorithm (GCRA), применяется в сетях ATM для контроля некоторых параметров.




10.8.3.2 Алгоритм “Token Bucket”

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

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

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

Рис. 10.10 Алгоритм "Token Bucket"

Классификация шлюзов

Рабочей группой MEGACO предложена следующая классификация транспортных шлюзов (Media Gateways):

• Trunking Gateway - шлюз между ТфОП и сетью с маршрутизацией пакетов IP, ориентированный на подключение к телефонной сети посредством большого количества цифровых трактов (от 10 до нескольких тысяч) с использованием системы сигнализации ОКС 7;

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

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

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

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

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

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

8.3 Модель организации связи

Для описания процесса обслуживания вызова с использованием протокола MGCP рабочей группой MEGACO разработана модель организации соединения - Connection model. Базой модели являются компоненты двух основных видов: порты (Endpoints) и подключения (Connections).

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

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

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

Подключения к N соединениям

а) цифровой порт

Подключения к М соединениям

б) аналоговый порт

Подключение к одному соединению

в) порт, передающий речевые извещения

Подключение к одному соединению

г) интерактивная речевая система

Подключения к L соединениям

д) порт, поддерживающий конференцсвязь

Подключения к 2 соединениям

е) межсетевой экран или транскодер - порт ретрансляции пакетов

Подключение к одному соединению

ж) порт записи/воспроизведения телефонных разговоров

Подключения к К соединениям

з) АТМ-интерфейс

Рис. 8.4 Примеры использования компонентов модели

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

Рис. 8.5 Соединение в сети, построенной на базе протокола MGCP

8.4 Команды протокола MGCP

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

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

Команда EndpointConfiguration содержит ряд параметров:

ReturnCode

<— EndpointConfiguration( Endpointid,



Bearer Information),

где Endpointid - идентификатор порта шлюза, к которому относится данная команда;

Bearerlnformation - параметр, определяющий закон (А или |i) декодирования принятой речевой информации.

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

Call Agent при помощи команды Notification Request может дать указание шлюзу выявлять определенные события или сигналы и информировать о них устройство управления. В число детектируемых событий (сигналов) входит изменение сопротивления абонентского шлейфа, происходящее, когда абонент поднимает или кладет трубку, а также получение сигналов факсимильных аппаратов и сигналов DTMF.

Команда NotificationRequest включает в себя следующие параметры (в квадратных скобках указаны те из них, которые не являются обязательными).

ReturnCode

<—NotificationRequest( Endpointid,

[NotifiedEntity,] [RequestedEvents,] Requestldentifier, [DigitMap,] [SignalRequests,] [QuarantineHandling,] [DetectEvents,] [encapsulated EndpointConfiguration])

Здесь NotifiedEntity - идентификатор устройства, которому должен быть передан ответ на команду. При отсутствии этого параметра ответ передается тому устройству, от которого получен запрос Notification Request.

Requested Events - список событий, о которых следует оповестить управляющее устройство. Кроме того, в этом параметре может быть указано, как шлюз должен реагировать на событие. Определены следующие действия шлюза: оповестить Call Agent о событии немедленно; ожидать дальнейших событий; если событие состоит в получении сигнала DTMF, то накапливать такие сигналы в соответствии с требованиями параметра DigitMap; в определенных ситуациях передавать в телефонный канал акустические или вызывные сигналы;

обработать инкапсулированную команду EndpointConfiguration; игнорировать событие и т.д.

Requestldentifier - идентификатор запроса, в ответ на который передается команда.



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

SignalRequests - сигналы, которые должны быть переданы в канал, например, сигнал посылки вызова.

QuarantineHandling - необязательный параметр, определяющий правила обработки событий, которые были обнаружены до момента получения данной команды в период так называемого карантина (quarantine period) и о которых Call Agent еще не был оповещен.

DetectEvents - необязательный параметр, определяющий события, которые нужно выявить в период карантина, но не оповещать о них Call Agent до получения следующей команды NotificationRequest с включенным в нее параметром QuarantineHandling.

Encapsulated EndpointConfiguration - команда EndpointConfiguration, инкапсулированная в команду NotificationRequest.

Остальные параметры команды тождественны описанным выше.

При помощи команды Notify шлюз информирует устройство управления о том, что произошло событие из числа указанных в команде NotificationRequest. Команда Notify содержит следующие параметры:

ReturnCode

<- Notify (Endpointid,

[NotifiedEntity,] Requestldentifier, ObservedEvents)

Здесь ObservedEvents - параметр, в котором описываются произошедшие события, например, передаются набранные цифры номера. Остальные параметры были описаны ранее.

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

Структура этой команды приведена ниже.

ReturnCode, Connectionid, [SpecificEndPolntId,1 [LocalConnectionDescriptor,] [SecondEndPointId,] [SecondConnectionId] <— CreateConnection(Callld,

Endpointid,

[NotifiedEntity,]

[LocalConnectionOptions,]

Mode,

[{RemoteConnectionDescriptor I

SecondEndpointId), ]

[Encapsulated NotificationRequest,] о [Encapsulated EndpointConfiguration])

Callld - уникальный параметр, идентифицирующий сессию, к которой относится данное соединение.



NotifiedEntity - необязательный параметр, идентифицирующий устройство, к которому должны быть переданы команды Notify или DeleteConnection.

LocalConnectionOptions - параметр, используемый Call Agent, чтобы дать шлюзу указания в отношении характеристик подключения порта к соединению. В параметр могут входить следующие поля:

метод кодирования, размер речевых пакетов, полоса пропускания, тип обслуживания, использование эхокомпенсатора, использование режима подавления пауз в разговоре, использование режима подавления шума, использование резервирования ресурсов и другие поля. Кодирование трех первых полей должно производиться в соответствии с протоколом описания сессий SDP (Session Description Protocol), причем Call Agent может у казать только полосу пропускания и оставить за шлюзом право выбора метода кодирования и размеров речевых пакетов.

Mode - параметр, определяющий режим работы для данного конца соединения. Определены следующие режимы: передача, прием, прием/передача, конференция, данные, отсутствие активности, петля, тестовый режим и другие.

RemoteConnectionDescriptor - описание подключения к соединению на другом его конце. Данный параметр содержит те же поля, что и параметр LocalConnectionOptions. Эти поля также должны кодироваться в соответствии с протоколом SDP. Стоит отметить, что при создании соединения между двумя шлюзами, при передаче первой команды CreateConnection параметр RemoteConnectionDescriptor отсутствует (ему присваивается нулевое значение), так как информация о подключении к соединению на другом его конце в этот момент отсутствует. Не имея такой информации, т.е. не получив команду ModifyConnection, шлюз может только принимать информацию (работать в режиме receive only).

SecondEndpointId - этот параметр может включаться в команду CreateConnection вместо параметра RemoteConnectionDescriptor при установлении соединения между двумя портами одного и того же шлюза.

Encapsulated NotificationRequest - инкапсулированная команда NotificationRequest.



В ответ на команду CreateConnection, кроме описанного выше параметра ReturnCode, шлюз возвращает следующие параметры:

Connectionid - уникальный идентификатор подключения данного порта к соединению.

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

LocalConnectionDescriptor - параметр, содержащий информацию об IP-адресе и номере порта RTP в соответствии с протоколом SDP.

SecondEndPointId - параметр, означающий, что команда CreateConnection создала два соединения.

SecondConnectionId - идентификатор подключения для второго соединения.

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

ReturnCode,

[LocalConnectionDescriptor]

<——— ModifyConnection (Call Id,

Endpointid, Connectionid, [NotifiedEntity,] [LocalConnectionOptions,] [Mode,]

[RemoteConnectionDescriptor,] [Encapsulated NotificationRequest,] [Encapsulated EndpointConfiguration])

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

Данная команда может использоваться для передачи информации о другом конце соединения в параметре RemoteConnection Descriptor, для активизации/деактивизации соединения при помощи параметра Mode, для изменения алгоритма кодирования, периода пакетизации передаваемой информации или для управления подавлением эха.

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

Если параметры соединения на ближнем конце были изменены, например, был изменен номер порта RTP, то в ответе на команду ModifyConnection может возвращаться параметр LocalConnection-Descriptor.



Устройство управления может разрушить существующее соединение при помощи команды DeleteConnection. Кроме того, при помощи этой команды шлюз может передать к Call Agent индикацию того, что существующее соединение больше поддерживаться не может.

Команда DeleteConnection, передаваемая устройством управления, имеет следующий вид:

ReturnCode,

Connection-parameters

<— DeleteConnection (Callld/

Endpointid,

Connectionid,

[Encapsulated NotificationRequest,]

[Encapsulated EndpointConfiguration])

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

В общем случае, команда DeleteConnection передается обоим шлюзам, подключенным к соединению. После завершения соединения в ответ на команду DeleteConnection шлюз возвращает статистические данные, собранные за время соединения - connection-parameters:

• количество переданных RTP-пакетов,

• количество переданных байтов информации, не считая служебной информации (заголовков IP/UDP/RTP),

• количество полученных RTP-пакетов,

• количество принятых байтов информации, не считая служебной информации (заголовков IP/UDP/RTP),

• количество потерянных RTP-пакетов,

• вариация времени между поступлениями RTP-пакетов,

• средняя задержка RTP-пакетов.

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

RetumCode,

<— DeleteConnection (Callld,

Endpointid, Connectionid, Reason-code, Connection-parametera)

В параметре Reason-code указывается причина, по которой шлюз передает данное сообщение. Остальные параметры были описаны ранее.

Чтобы получить информацию о статусе какого-либо порта шлюза, управляющее устройство может передать запрос Audit EndPoint, который имеет следующий вид:



RetumCode,

EndPointIdLietl{ [RequestedEvente,] [DigitMap,] [SignalRequests,] [Requestldentifier,1 [NotifiedEntity,] [Connectionldentifiers,] [DetectEvents,] [ObservedEvents,] [EventStates,] [Bearer Information,1 [RestartReason,] [RestartDelay,] [ReasonCode,] [Capabilities]}

<- AuditEndPoint(Endpointid, [Requestedlnfo])

Requestedlnfo - необязательный параметр, описывающий информацию, которую запрашивает устройство управления.

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

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

Observed Events - необязательный параметр, в котором приводится текущий список обнаруженных событий;

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

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

Capabilities - необязательный параметр, содержащий такую же информацию, как и параметр LocalConnectionOptions.

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

Команда имеет следующий вид:

ReturnCode, [Callld,]

[NotifiedEntity,] [LocalConnectionOptione,] [Mode,]

[RemoteConnectionDescriptor,] [LocalConnectionDescriptor,] [ConnectionParameters]

<— AuditConnection (Endpointid,

Connectionid,

Requestedlnfo)

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

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


Данная команда имеет следующий вид:

ReturnCode, [NotifiedEntity] <—— RestartinProgress (EndPointId,

RestartMethod, [RestartDelay,] [Reason-code])

Параметр RestartMethod специфицирует вид рестарта. Определено несколько видов рестарта:

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

• Forced restart - принудительный рестарт, при котором разрушаются установленные соединения.

• Restart - рестарт, при котором порт оборудования возвращается в обслуживание после определенной задержки. При этом порт в момент рестарта не участвует ни в каких соединениях.

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

• Cancel-graceful - данное значение присваивается параметру Re-startMethod, когда шлюз отменяет предшествовавшую команду Restart с параметром RestartMethod, которому было присвоено значение Graceful.

Параметр RestartDelay определяет задержку рестарта в секундах.

По аналогии с предыдущими главами в таблицу 8.1 сведены все команды протокола MGCP.

Таблица 8.1 Команды протокола MGCP

Команда	Направление передачи	Назначение
EndpointConfiguration (Конфигурация порта)	СА -> MG	Call Agent инструктирует шлюз, каким образом ему нужно обрабатывать получаемые речевые сигналы
CreateConnection (Создать соединение)	СА -> MG	Call Agent дает указание шлюзу создать соединение
ModifyConnection (Модифицировать соединение)	СА -> MG	Call Agent дает указание шлюзу изменить параметры существующего соединения
DeleteConnection (Завершить соединение)	СА -> MG, MG -> СА	Call Agent и шлюзы завершают соединение
NotificationRequest (Запрос уведомления)	СА -> MG	Call Agent инструктирует шлюз, какие события необходимо обнаруживать.
Notify (Уведомить)	MG -> СА	Шлюз информирует Call Agent о том, что произошло событие из числа тех, которые были специфицированы в команде NotificationRequest
AuditEndpoint (Проверить порт)	СА -> MG	Call Agent запрашивает информацию о каком-либо порте шлюза
AuditConnection (Проверить соединение)	MGC -> MG	Call Agent запрашивает параметры соединения
ReStartlnProgress (Идёт рестарт)	MG -> MGC	Шлюз информирует Call Agent о том, что один или несколько портов выводятся из рабочего состояния или возвращаются в рабочее состояние

8.5 Структура команд

Команда протокола MGCP обязательно содержит заголовок, за которым может следовать описание сеанса связи (session description). Заголовок команды и описание сеанса связи представляют собой набор текстовых строк. Описание сеанса отделено от заголовка команды пустой строкой.

Заголовок содержит список параметров и командную строку вида CRCX 1204 ts/1@protei.loniis.net MGCP 0.1. Командная строка, в свою очередь, состоит из нескольких информационных полей:

1. Название команды представлено в виде кода из четырех букв (табл.8.2)

Таблица 8.2 Кодировка команд протокола MGCP

Команда	Код
EndpointConfiguration	EPCF
CreateConnection	CRCX
ModifyConnection	MDCX
DeleteConnection	DLCX
NotificationRequest	RQNT
Notify	NTFY
AuditEndpoint	AUEP
AuditConnection	AUCX
ReStartlnProgress	RSIP

2. Идентификатор транзакции. Протокол MGCP предусматривает корреляцию команд и ответов. Команда и ответ на нее образуют транзакцию, имеющую уникальный идентификатор (Transaction-Identifier). Идентификатор транзакции включается в заголовок и команды, и ответа. Значения идентификаторов выбираются из диапазона чисел 1 -999999999, причем значение идентификатора текущей транзакции на единицу больше идентификатора предыдущей транзакции.

3. Идентификатор порта определяет тот порт шлюза, которому надлежит выполнить команду, за исключением команд Notify и ReStartlnProgress, в которых идентификатор определяет порт, передавший команду. Идентификаторы портов кодируются также, как кодируются адреса электронной почты в соответствии с документом RFC 821 комитета IETF. Например, возможен идентификатор ts/1@protei.loniis.net, который идентифицирует первый порт (временной канал) шлюза “protei”, расположенного в домене loniis.

4. Версия протокола кодируется следующим образом: MGCP 1.0.

Выше указывалось, что заголовок команды, кроме командной строки, содержит список параметров. Параметры команд протокола MGCP сведены в таблицу 8.3.

Таблица 8.3 Параметры команд протокола MGCP

Название параметра	Код	Описание и значение параметра
ResponseAck (Подтверждение транзакции)	К	Подтверждает завершение одной или нескольких транзакций. Например, параметр К: 6234-6255, 6257, 19030-19044 подтверждает завершение транзакций, имеющих идентификаторы с 6234 по 6255, 6257 и с 19030 по 19044.
Bearerlnformation (Сведения о виде информации)	В	Служит для доставки информации о законе кодирования речевой информации А или m
ReasonCode (Код причины)		Определены следующие коды причины; 000 - номинальное состояние порта, передается только в ответе на запрос о состоянии порта 900 - неисправность порта 901 - порт выведен из обслуживания 902 - отказ на физическом уровне (например, потеря синхронизации)
CalllD (Идентификатор сеанса связи)	С	Идентифицирует сеанс связи, в котором может использоваться одно или несколько соединений. Идентификатор кодируется шестнадцатеричной последовательностью символов длиной не более 32 символом.
ConnectionID (Идентификатор подключения)	1	Идентифицирует подключение данного порта к одному соединению, так как один порт может быть одновременно подключен к нескольким соединениям
Notified Entity (Уведомляемый объект)	N	Идентификатор объекта, к которому следует передавать уведомления об обнаруженных событиях. Если данный параметр опущен, порт передает эту информацию к объекту, от которого была получена команда. Идентификатор объекта кодируется так же, как кодируются адреса электронной почты согласно RFC 821, например, MGC@ca.anynet.com:5625 или Joe@[128.23.0.4]. При использовании IP-адреса, он должен быть заключен в квадратные скобки.
Requestldentifier (Идентификатор запроса)	Х	Согласует требование уведомить о событии, полученное от Call Agent, с уведомлением, передаваемым шлюзом в команде Notify.
LocalConnection Options (Параметры подключения порта к соединению)	L	Данные об алгоритме кодирования информации, размере речевых пакетов в мс, используемой полосе пропускания в Кбит/с, типе обслуживания, использовании эхокомпенсации и другие сведения. Передается от Call Agent к шлюзу, обычно в команде CRCX.
ConnectionMode (Режим соединения)	М	Определены следующие режимы соединения: передача, прием, прием/передача, конференция, передача данных, отсутствие активности, петля, тест и другие режимы. Значение параметру присваивает Call Agent.
RequestedEvents (Запрашиваемые события)	R	Список событий, о которых следует оповестить Call Agent, и действия шлюза при обнаружении события. Определены следующие действия: оповестить Call Agent о событии немедленно; ожидать дальнейших событий; если событием является прием сигнала DTMF, то накапливать цифры в соответствии с требованиями параметра DigitMap; в определенных ситуациях передавать в канал акустические или вызывные сигналы; обработать инкапсулированную команду Endpoint Configuration, игнорировать событие и др.
SignalRequests (Требование передать сигнал)	S	Специфицируется сигнал, который должен быть передан абоненту, например, акустический сигнал "Ответ станции".
DigitMap (План нумерации)	D	Специфицирует правила обработки сигналов DTMF. При накоплении количества цифр, указанного в данном параметре, шлюз должен передать их устройству управления.
ObservedEvents (Обнаруженные события)	0	Список обнаруженных событий.
ConnectionParameters (Параметры соединения)	Р	Статистические данные о соединении, передаваемые шлюзом после его завершения.
SpecifiedEndPointID (Идентификатор порта)	Z	Идентификатор порта в формате RFC821, например, EndPoint@hub1 .anynet.com:5625,
Requestedlnfo (Запрашиваемая информация)	F	Описывает информацию, которую Call Agent запрашивает у шлюза, например, цифры номера вызываемого абонента, набранные вызывающим абонентом.
QuarantineHandling (Карантинная обработка)	Q	Определяет правила обработки событий, которые были обнаружены до получения данной команды в период так называемого карантина (quarantine period), и о которых Call Agent еще не был оповещен.
DetectEvents (Выявляемые события)	Т	Перечень событий, которые порт должен отслеживать, а при их обнаружении - извещать об этом Call Agent.
EventStates (Состояния, обусловленные событиями)	ES	Перечень состояний порта, обусловленных, например, тем, что абонент снял или положил трубку; информация об этих состояниях должна передаваться к Call Agent в ответ на команду AuditEndpoint.
RestartMethod (Метод рестарта)	RM	Способ индикации шлюзом вывода порта из обслуживания или ввода его в обслуживание. Поддерживаются несколько вариантов рестарта: "graceful", "forced", "restart", "disconnected" or "cancel-graceful".
RestartDelay (Задержка рестарта)	RD	Определяет время в секундах, после которого производится производится порта. Если этот параметр отсутствует, задержка рестарта равна нулю. При получении от Call Agent требования о принудительном рестарте порта команда выполняется незамедлительно.
Capabilities (Функциональные возможности порта)	А	Информацию о функциональных возможностях порта запрашивает Call Agent при помощи команды AuditEndpoint. Эти возможности порта включают в себя: поддерживаемые алгоритмы кодирования, период пакетизации, полосу пропускания, эхокомпенсацию, подавление пауз речи, режимы соединения, тип обслуживания, совокупность событий и др.

Не все параметры, приведенные в таблице 8.3, должны обязательно присутствовать во всех командах протокола MGCR В таблице 8.4 представлены возможные комбинации параметров в командах протокола MGCR Буква “М” означает обязательное присутствие параметра в команде, буква “О” - не обязательное присутствие, буква “F” запрещает присутствие параметра.

Таблица 8.4 Комбинации параметров в командах протокола MGCP

Имя параметра	EP CF	CR CX	MD CX	DL CX	RQ NT	NT FY	AU EP	AU CX	RS IP
ResponseAck	0	0	0	0	0	0	0	0	0
Bearerlnformation	M	0	0	0	0	F	F	F	F
Callld	F	M	M	0	F	F	F	F	F
Connectionid	F	F	M	0	F	F	F	M	F
Requestldentifier	F	0**	o**	о**	M	M	F	F	F
LocalConnection	F	0	0	F	F	F	F	F	F
Options
Connection Mode	F	M	M	F	F	F	F	F	F
Requested Events	F	0	0	0	O*	F	F	F	F
SignalRequests	F	0	0	0	O*	F	F	F	F
NotifiedEntity	F	0	0	0	0	0	F	F	F
ReasonCode	F	F	F	0	F	F	F	F	0
Observed Events	F	F	F	F	F	M	F	F	F
DigitMap	F	0	0	0	0	F	F	F	F
Connection	F	F	F	0	F	F	F	F	F
Parameters
Specific Endpoint ID	F	F	F	F	F	F	F	F	F
Second Endpoint ID	F	0	F	F	F	F	F	F	F
Requestedlnfo	F	F	F	F	F	F	M	M	F
QuarantineHandling	F	0	0	0	0	F	F	F	F
DetectEvents	F	0	0	0	0	F	F	F	F
EventStates	F	F	F	F	F	F	F	F	F
RestartMethod	F	F	F	F	F	F	F	F	M
RestartDelay	F	F	F	F	F	F	F	F	0
SecondConnectionID	F	F	F	F	F	F	F	F	F
Capabilities	F	F	F	F	F	F	F	F	F
RemoteConnection	F	0	0	F	F	F	F	F	F
Descriptor
LocalConnection	F	F	F	F	F	F	F	F	F
Descriptor

** - параметр Requestldentifier не обязателен для команд Create-Connection, ModifyConnection и DeleteConnection, но если эти команды содержат инкапсулированную команду NotificationRequest, присутствие в них параметра Requestldentifier становится обязательным;

* - параметры Requested Events и SignalRequests не обязательны для команды NotificationRequest.




8.6 Структура ответов на команды

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

В этом параграфе речь пойдет, главным образом, о заголовке ответа. Заголовок состоит из ответной строки, например, 2001203 OK, и списка параметров. Ответная строка, в свою очередь, состоит из нескольких информационных полей: кода ответа, идентификатора транзакции и необязательного комментария.

В таблице 8.5 приведены возможные варианты кода ответа на команды протокола MGCP.

Таблица 8.5 Коды ответов на команды протокола MGCP

Код	Значение кода
100	Полученная команда в данный момент обрабатывается, сообщение о выполнении команды будет передано позже
200	Полученная команда выполнена
250	Соединение разрушено
400	Транзакция не может быть выполнена из-за временной ошибки
401	Трубка телефона уже снята
402	Трубка телефона уже повешена
403	Команда не может быть выполнена из-за отсутствия в данный момент необходимых ресурсов
404	В настоящий момент отсутствует необходимая полоса пропускания
500	Команда не может быть выполнена, потому что порт неизвестен
501	Команда не может быть выполнена, потому что порт не готов к ее выполнению
502	Команда не может быть выполнена, потому что порт не имеет необходимой полосы пропускания
510	Команда не может быть выполнена из-за ошибки в протоколе
511	Команда не может быть выполнена, так как в ней содержится нераспознанное расширение
512	Команда не может быть выполнена, потому что шлюз не имеет средств детектирования одного из запрашиваемых сигналов
513	Команда не может быть выполнена, потому что шлюз не имеет средств генерирования одного из запрашиваемых сигналов
514	Команда не может быть выполнена, потому что шлюз не может передать необходимое речевое уведомление или подсказку
515	Команда имеет некорректный идентификатор соединения, например, идентификатор уже завершенного соединения
516	Команда имеет некорректный идентификатор сеанса связи
517	Неподдерживаемый или некорректный режим
518	Неподдерживаемая или неизвестная совокупность сигналов или событий
519	Порт не имеет сведений о плане нумерации
520	Команда не может быть выполнена, потому что идет рестарт порта
521	Порт передан другому Call Agent
522	Нет такого события или сигнала
523	Неизвестное действие или неразрешённая комбинация действий
524	Внутреннее несоответствие в параметре LocalConnectionOptions
525	Неизвестное расширение параметра LocalConnectionOptions
526	Недостаточная полоса пропускания
527	Отсутствует параметр LocalConnectionOptions
528	Несовместимая версия протокола
529	Отказ в аппаратном обеспечении
530	Ошибка в сигнальном протоколе CAS
531	Отказ группы каналов или трактов

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


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

В заключение рассмотрения структуры ответов на команды протокола MGCP приведем возможные комбинации параметров в ответах (таблица 8.6).

Таблица 8.6 Возможные комбинации параметров в ответах протокола MGCP

Имя параметра	EP CF	CR CX	MD CX	DL CX	RQ NT	NT FY	AU EP	AU CX	RS IP
ResponseAck	F	F	F	F	F	F	F	F	F
Bearerlnformation	F	F	F	F	F	F	0	F	F
Callld	F	F	F	F	F	F	F	0	F
Connectionid	F	0	F	F	F	F	F	F	F
Requestldentifier	F	F	F	F	F	F	0	F	F
LocalConnection	F	F	F	F	F	F	0	0	F
Options
Connection Mode	F	F	F	F	F	F	F	0	F
RequestedEvents	F	F	F	F	F	F	0	F	F
SignalRequests	F	F	F	F	F	F	0	F	F
Notified Entity	F	F	F	F	F	F	F	F	0
ReasonCode	F	F	F	F	F	F	0	F	F
Observed Events	F	F	F	F	F	F	0	F	F
DigitMap	F	F	F	F	F	F	0	F	F
Connection	F	F	F	0	F	F	F	0	F
Parameters
Specific Endpoint ID	F	0	F	F	F	F	F	F	F
Requested Info	F	F	F	F	F	F	F	F	F
QuarantineHandling	F	F	F	F	F	F	0	F	F
DetectEvents	F	F	F	F	F	F	0	F	F
EventStates	F	F	F	F	F	F	0	F	F
RestartMethod	F	F	F	F	F	F	0	F	F
RestartDelay	F	F	F	F	F	F	0	F	F
Capabilities	F	F	F	F	F	F	0	F	F
SecondConnectionId	F	0	F	F	F	F	F	F	F
SecondEndpointID	F	0	F	F	F	F	F	F	F
LocalConnection	F	м	0	F	F	F	F	0	F
Descriptor
RemoteConnection	F	F	F	F	F	F	F	0	F
Descriptor

8.7 Описания сеансов связи

При установлении соединений Call Agent предоставляет портам шлюзов, участвующим в этих соединениях, необходимую информацию друг о друге - описание сеансов связи.


Описание сеанса связи вводится в состав некоторых команд и ответов протокола MGCP и включает в себя IP-адрес, UDP/ RTP порт, вид информации, алгоритм кодирования информации, размер речевых пакетов и т.д. Синтаксис описания сеанса связи в протоколе MGCP соответствует синтаксису протокола описания сеансов связи - session description protocol (SDP), предложенному для использования в вышеуказанных целях комитетом IETF в документе RFC 2327 [53].

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

Так как книга посвящена анализу технологии передачи речевой информации по сетям с маршрутизацией пакетов IP, в данном параграфе мы рассмотрим синтаксис протокола SDP только в части описания сеанса речевой связи. Для описания такого сеанса в протоколе SDP предусмотрено несколько информационных полей:

• Версия протокола SDP. Текущая версия протокола - нулевая. Поле кодируется следующим образом: v=0.

• IP-адрес шлюза. Это поле содержит IP-адрес, который будет использоваться для обмена пакетами RTP. Если это поле включено в команды протокола MGCP, то оно означает адрес удаленного шлюза, если поле включено в ответы, то - адрес шлюза, передающего ответ.

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

• Режим соединения. Режимы соединений представлены в таблице 8.7.

)

Таблица 8.7 Режимы соединения

Кодировка режима	Функционирование шлюза
sendonly	Шлюзу надлежит только передавать информацию
recvonly	Шлюзу надлежит только принимать информацию
sendrecv	Шлюзу надлежит передавать и принимать информацию
inactive	Шлюз не должен ни передавать, ни принимать информацию
loopback	Шлюз должен передавать принимаемую информацию в обратном направлении
contest	Шлюзу надлежит перевести порт в режим тестирования

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

v = О

с = IN IP4 128.96.41.1

m = audio 3456 rtp/avp 0

Данный пример заслуживает краткого комментария. Для описания сеанса связи используется протокол SDP, версия 0, в сети используется протокол IP, версия 4, IP адрес шлюза- 128.96.41.1, передается или принимается речевая информация, упакованная в пакеты RTP, номер порта RTP - 3456, алгоритм кодирования речи G.711, закон [I.

8.8 Установление, изменение и разрушение соединений

В данном параграфе будет показано, каким образом при помощи протокола MGCP устанавливаются, изменяются и завершаются речевые соединения в сетях с маршрутизацией пакетов IP. Пример охватывает взаимодействие протокола MGCP с протоколом ОКС7 (рис. 8.6).

От телефонной станции АТС1 к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения - сообщение IAM. Шлюз SG1 передает сообщение IAM устройству управления шлюзами Call Agent, которое обрабатывает запрос и определяет, что вызов должен быть направлен к телефонной станции АТС2 посредством шлюза TGW2.

Далее Call Agent резервирует порт шлюза TGW1 (разговорный канал). С этой целью Call Agent передает шлюзу команду CreateConnec-tion. Отметим, что порт шлюза TGW1 может только принимать информацию (режим “recvonly”), так как он еще не осведомлен о том, на какой адрес и каким образом ему следует передавать информацию.

CRCX 1204 trunk-group-l/17@tgwl.whatever.net MGCP 0.1

С: A3C47F21456789FO

L: p:10, a:G.711

M: recvonly

В ответе на принятую команду шлюз TGW1 возвращает описание сеанса связи.

200 1204 OK

I:FDE234C8

v=0

C=IN IP4 128.96.41.1

m=audio 3456 RTP/AVP 0

Рис. 8.6 Установление и разрушение соединения с использованием протокола MGCP



После приема от шлюза TGW1 подтверждения Call Agent передает команду CRCX второму шлюзу TGW2 с целью зарезервировать в нем порт:

CRCX 1205 trunk-group-2/$@tgw2.whatever.net MGCP 0.1

С: A3C47F21456789FO

M: sendrecv

v0

C=IN IP4 128.96.41.1

m=audio 3456 RTP/AVP 0

Шлюз TGW 2 выбирает порт, который будет участвовать в связи, и подтверждает прием команды CRCX.

200 1205 OK

I:abc0

v=0

C-IN IP4 128.96.63.25

m=audio 1296 RTP/AVP 0

При помощи двух команд CRCX создается однонаправленный разговорный канал для передачи вызываемому абоненту акустических сигналов или речевых подсказок и извещений. В то же время, порт шлюза TGW 2 уже может не только принимать, но и передавать информацию, так как он получил описание сеанса связи от встречного шлюза. Далее Call Agent передает сообщение 1АМ к телефонной станции АТС2. На сообщение 1АМ станция АТС2 отвечает сообщением АСМ, которое немедленно пересылается к станции АТС1.

После того как вызываемый абонент примет вызов, телефонная станция АТС2 передает к Call Agent сообщение ANM. Далее Call Agent меняет режим соединения “recvonly” в шлюзе TGW1 на полнодуплексный режим:

MDCX 1206 trunk-group-I/17@tgwl.whatever.net MGCP 0.1

С: A3C47F21456789FO

I: FDE234C8

M: sendrecv

v=0

C=IN IP4 128.96.63.25

m=audio 1296 RTP/AVP 0

Шлюз TGW1 выполняет и подтверждает изменение режима соединения:

200 1206 OK

Call Agent передает сообщение ANM к телефонной станции АТС1, после чего наступает разговорная фаза соединения.

Завершение разговорной фазы происходит следующим образом. В нашем случае вызвавший абонент дает отбой первым, телефонная станция АТС1 через шлюз сигнализации передает к Call Agent сообщение REL. На основании этого сообщения Call Agent завершает соединение с вызвавшим абонентом:

DLCX 1207 trunk-group-I/17&tgwl.whatever.net MOCP 0.1

С: A3C47F21456789FO I:FDE234C8

Шлюз подтверждает завершение соединения и передает к Call Agent собранные за время соединения статистические данные:

250 1217 OK

Р: PS-1245, OS-62345, PR-780, OR'45123, PL-10, JI-27,LA=48




Далее Call Agent передает к АТС1 сообщение RLC с целью подтвердить разрушение соединения.

Параллельно Call Agent завершает соединение с вызванной стороной:

DLCX 1208 trunk-group-2/13@tgw2.whatever.net MGCP 0.1

С: A3C47F21456789FO

I:abc0

Шлюз TGW2 подтверждает завершение соединения и передает к Call Agent собранные за время соединения статистические данные

250 1218 OK

Р: PS=790, 08=45700, PR=1230, OR=61875, PL=15, JI=27,IA=48

После приема ответа на команду DLCX Call Agent может начинать процедуру завершения соединения с АТС2, которая должна подтвердить разъединение, после чего соединение считается разрушенным.

8.9 Реализация оборудования с поддержкой протокола MGCP

Рассмотрим реализацию протокола MGCP на примере оборудования IPConnect производства компании Nortel Networks. IPConnect -это набор совместимых аппаратно-программных средств, объединенных единой идеологией и технологической базой. Он охватывает системы управления соединениями и обработки вызовов, серверы приложений, шлюзы, а также аппаратуру, устанавливаемую непосредственно у пользователей. Масштабы сетей, создаваемых на базе этого решения, практически не ограничены.

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

Как известно, до недавнего времени единственным протоколом, регулирующим процесс управления соединениями в сетях IP-телефонии, был протокол Н.323. Этот протокол достаточно широко распространен и хорошо зарекоменовал себя в решениях IP-телефонии. Но, к сожалению, Н.323 не может гарантировать прозрачность соединений с ТфОП, использующими сигнализацию ОКС7. Это обстоятельство предопределило выбор протокола MGCP в качество основного протокола в оборудовании IPConnect (что, впрочем, не отвергает полностью протокол Н.323). Протокол MGCP специально оптимизирован для нужд телефонии, и компания Nortel Networks принимает активное участие в его разработке и внедрении.



С точки зрения функционального построения в IPConnect можно выделить четыре основных элемента (рис. 8.7):

• шлюз между ТфОП и IP-сетью (CVX 1800);

• система обработки вызовов (IPConnect Call Engine - ICE);

• шлюз сигнализации (USP);

• различные приложения - например, IVR.

Рис. 8.7 Инфраструктура IPConnect

Результатом эволюции ОКС7 в направлении пакетной передачи информации стало появление семейства протоколов IPS7 (более 20), описывающих конкретные процедуры упаковки/распаковки сигналов ОКС7. В их числе - аналоги протоколов ISUP, INAP и других, используемых в системе сигнализации ОКС7. Эти протоколы имеют различные модификации, учитывающие особенности, присущие национальным системам сигнализации. В частности, имеются специальные разновидности и для России (например, аналог протокола ISUP-R).

8.10 Возможности и перспективы протокола MGCP

Для построения хорошо функционирующих и совместимых с ТфОП сетей IP-телефонии сегодня подходят протоколы Н.323 и MGCP. Подход с использованием MGCP обладает весьма важным преимуществом перед подходом, предложенным ITU в рекомендации Н.323: Call Agent поддерживает сигнализацию ОКС7 и другие виды телефонной сигнализации; поддерживается также прозрачная трансляция сигнальной информации по сети IP-телефонии. В сети, построенной на базе рекомендации Н.323, сигнализация ОКС7, как и любая другая сигнализация, должна конвертироваться шлюзом в сигнальные сообщения Н.225.0 (Q.931).

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

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

всех цифровых кодеков речевых сигналов,

Кодек G.711 - “дедушка” всех цифровых кодеков речевых сигналов, был одобрен ITU-T в 1965 году. Применяемый в нем способ преобразования аналогового сигнала в цифровой с использованием полулогарифмической шкалы был достаточно подробно описан выше. Типичная оценка MOS составляет 4.2. В первую очередь .отметим, что, как и для ТфОП, минимально необходимым для оборудования VolP является ИКМ-кодирование G.711. Это означает, что любое устройство VolP должно поддерживать этот тип кодирования.

3.3.2 Кодек G.723.1

Рекомендация G.723.1 утверждена ITU-T в ноябре 1995 года. Форум IMTC выбрал кодек G.723.1 как базовый для приложений IP-телефонии.

Кодек G.723.1 производит кадры длительностью 30 мс с продолжительностью предварительного анализа 7.5 мс. Предусмотрено два режима работы: 6.3 Кбит/с (кадр имеет размер 189 битов, дополненных до 24 байтов) и 5.3 Кбит/с (кадр имеет размер 158 битов, дополненных до 20 байтов). Режим работы может меняться динамически от кадра к кадру. Оба режима обязательны для реализации.

Оценка MOS составляет 3.9 в режиме 6.3 Кбит/с и 3.7 в режиме 5.3 Кбит/с.

Кодек специфицирован на основе операций как с плавающей точкой, так и с фиксированной точкой в виде кода на языке С. Реализация кодека на процессоре с фиксированной точкой требует производительности около 16 MIPS.

Кодек G.723.1 имеет детектор речевой активности и обеспечивает генерацию комфортного шума на удаленном конце в период молчания. Эти функции специфицированы в приложении A (Annex А) к рекомендации G.723.1. Параметры фонового шума кодируются очень маленькими кадрами размером 4 байта. Если параметры шума не меняются существенно, передача полностью прекращается.

3.3.3 Кодек G.726

Алгоритм кодирования АДИКМ (рекомендация ITU-TG.726, принятая в 1990 г.) описан выше. Он обеспечивает кодирование цифрового потока G.711 со скоростью 40, 32, 24 или 16 Кбит/с, гарантируя оценки MOS на уровне 4.3 (32 Кбит/с), что часто принимается за эталон уровня качества телефонной связи (toll quality). В приложениях IP-телефонии этот кодек практически не используется, так как он не обеспечивает достаточной устойчивости к потерям информации (см.
выше).

3.3.4 Кодек G.728

Кодек G.728 использует оригинальную технологию с малой задержкой LD-CELP ( low delay code excited linear prediction) и гарантирует оценки MOS, аналогичные АДИКМ G.726 при скорости передачи 16 Кбит/с. Данный кодек специально разрабатывался как более совершенная замена АДИКМ для оборудования уплотнения телефонных каналов, при этом было необходимо обеспечить очень малую величину задержки (менее 5 мс), чтобы исключить необходимость применения эхокомпенсаторов Это требование было успешно выполнено учеными Bell JLabs в 1992 году: кодер имеет длительность кадра только 0.625 мс. Реально задержка может достигать 2.5 мс, так как декодер должен поддерживать синхронизацию в рамках структуры из четырех кадров.

Недостатком алгоритма является высокая сложность - около 20 MIPS для кодера и 13 MIPS для декодера - и относительно высокая чувствительность к потерям кадров.

3.3.5 Кодек G.729

Кодек G.729 очень популярен в приложениях передачи речи по сетям Frame Relay. Он использует технологию CS-ACELP (Conjugate Structure, Algebraic Code Excited Linear Prediction). Кодек использует кадр длительностью 10 мс и обеспечивает скорость передачи 8 Кбит/с. Для кодера необходим предварительный анализ сигнала продолжительностью 5 мс.

Существуют два варианта кодека:

• G.729 (одобрен ITU-T в декабре 1996), требующий около 20 MIPS для кодера и 3 MIPS для декодера.

• Упрощенный вариант G.729A (одобрен ITU-T в ноябре 1995), требующий около 10.5 MIPS для реализации кодера и около 2 MIPS для декодера.

В спецификациях G.729 определены алгоритмы VAD, CNG и DTX. В периоды молчания кодер передает 15-битовые кадры с информацией о фоновом шуме, если только шумовая обстановка изменяется.

3.4 Кодеки, стандартизованные ETSI

В рамках деятельности европейского института ETSI стандартизованы узкополосные кодеки для применения в системах мобильной связи (GSM).

Спецификации кодека GSM Full Rate, известного также как GSM 06.10, утверждены в 1987г. Это первый и, скорее всего, наиболее известный из узкополосных кодеков, применяемый в миллионах мобильных телефонов по всему миру.


Обеспечивает хорошее качество и устойчивую работу в условиях фонового шума (оценка MOS порядка 3.7 в условиях без шума). Кодируются кадры длительностью 20 мс, образуя цифровой поток со скоростью 13 Кбит/с. Кодек не требует высокой производительности процессора - необходимо только 4.5 MIPS для дуплексной реализации. Кодек очень важен для некоммерческих проектов в области IP-телефонии, особенно -для проектов, связанных с открытым распространением исходных текстов ПО (open source), благодаря возможности бесплатного лицензирования. Такие проекты сегодня могут использовать только кодеки GSM FR и G.711, а также АДИКМ.

Существуют также спецификации кодеков GSM Half Rate, принятые в 1994 году, и GSM Enhanced Full Rate, принятые в 1995 году. Характеристики этих кодеков превосходят характеристики исходного варианта, описанного выше, однако алгоритмы требуют большей производительности процессора (до 30 MIPS). В приложениях IP-телефонии они, по разным причинам, распространения пока не получили.

Рассмотрение кодеков было бы неполным, если бы, наряду со специфицированными ITU-T и ETSI, не были упомянуты и т.н. нестандартные кодеки.

Сегодня в приложениях VolP, кроме кодеков, прошедших процедуры международной стандартизации в ITU-T и ETSI, в продуктах ряда фирм-производителей применяются также нестандартные внутрифирменные алгоритмы. Такие алгоритмы часто лицензируются для использования в продуктах других компаний. В качестве примеров можно назвать такие кодеки, как Lucent/Elemedia SX7003P, имеющий очень хорошие характеристики при умеренной вычислительной сложности, и Voxware RT24, который предусматривает сверхнизкую (2.4 Кбит/с) скорость передачи информации при сохранении достаточно хорошего качества речи (оценка MOS около 3.2).

3.5 Передача сигналов DTMF

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



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

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

Существуют два основных метода передачи сигналов DTMF по сетям IP-телефонии.

• Обязательный метод. Специальное сообщение протокола Н.245 (Userlnputlndication) может содержать символы цифр и “*”, “#”. В данном случае используется надежное TCP-соединение, так что информация не может быть потеряна. Однако из-за особенностей TCP могут иметь место значительные задержки;

• Нестандартный метод, предложенный Форумом VolP. Он может быть применен в терминалах H.323v2 при использовании процедуры fastStart и отсутствии канала Н.245. Для передачи сигналов DTMF открывается специальная RTP-сессия, в которой передаются кодированные значения принятых цифр, а также данные об амплитуде и длительности сигналов. Может быть использована та же сессия, что и для речи, но со специальным типом полезной нагрузки. Использование RTP позволяет привязать DTMF- сигналы к реальному времени, что является важным преимуществом данного метода.

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



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

3.6 Передача факсимильной информации

В становлении IP-телефонии, наряду с телефоном, значительную роль сыграл телефакс. Идею нынешнего телефакса (от греческого “теле” - далеко и латинского “facsimale” - делай подобное) предложил англичанин Александр Байн в 1843 году, то есть за 33 года до появления телефона. В такой же последовательности (начиная с факсов) стали практически использоваться преимущества IP-телефонии с ее весьма низкими тарифами для передачи информации на дальние расстояния. Значительный экономический эффект от такого применения обусловлен чрезвычайно высокой распространенностью факс-машин; в мире их насчитывается много миллионов.

Говоря о распространенности факс-машин, отметим, что имеются в виду аппараты группы 3, специфицированные в рекомендации ITU-TT.30. Именно появление этой технологии и открыло дорогу широкому внедрению услуг факсимильной связи. Оказалось, что функции, реализованные в факсах группы 3, вполне устраивают пользователей, а стандарт практически не требует развития. Об этом свидетельствует тот факт, что более современная технология, т.н. факс группы 4, не получила никакого распространения и практически забыта. На наш взгляд, неуспех этой технологии можно объяснить тем, что, во-первых, все ее потенциальные преимущества (передача цветных изображений, высокая скорость обмена и т.д.) проще и дешевле реализуются на базе компьютерных технологий (обмен файлами по электронной почте, например), а во-вторых, сеть ISDN, на которую были ориентированы факсы группы 4, не получила глобального распространения.

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


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

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

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


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

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

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


Когда в качестве транспорта применяется протокол TCP, существует два возможных варианта: передавать сообщения IFP, используя их Туннелирование в канале H.225.0/Q.931, или использовать для этого выделенное соединение.

Несмотря на то, что согласно ITU-T реализация на основе протокола TCP является обязательной, в шлюзах большинства крупных производителей реализован транспорт IFP поверх протокола UDP. Отчасти это можно объяснить тем, что при таком решении механизм открытия логических каналов выглядит совершенно аналогично механизму, используемому для передачи речевой информации. Кроме того, протокол Т.38 обычно реализуется на основе либо тех же DSP, что и речевые кодеки, либо специализированного процессора, обеспечивающего пересылку речевой информации, а для таких процессоров реализация протокола TCP слишком тяжеловесна, и ее стараются избежать. Как бы то ни было, реализации Т.38 на базе протокола UDP широко эксплуатируются и доказали работоспособность такого решения. Шлюз IP-телефонии семейства оборудования Протей-IP использует транспорт UDP, а вариант с TCP может быть реализован, если на рынке появится в достаточном количестве оборудование, использующее этот подход.

3.7 О реализации “стандартных” алгоритмов

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

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

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


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

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

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

Литература

Литература

1. Бакланов И.Г. ISDN и IP-телефония / Вестник связи, 1999, №4.

2. Брау Д. Грядет год стандарта Н.323? / Сети и системы связи,

1999. №14.

3. Будников В.Ю., Пономарев Б.А. Технологии обеспечения качества обслуживания в мультисервисных сетях / Вестник связи,

2000. №9.

4. Варакин Л. Телекоммуникационный феномен России / Вестник связи International, 1999, №4.

5. Варламова Е. IP-телефония в России / Connect! Мир связи, 1999, №9.

6. Гольдштейн Б.С. Сигнализация в сетях связи. Том 1. М.: Радио

и связь, 1998.

7. Гольдштейн Б.С. Протоколы сети доступа. Том 2. М.: Радио и связь, 1999.

8. Гольдштейн Б.С., Ехриель И.М., Рерле Р.Д. Интеллектуальные сети. М.: Радио и связь, 2000.

9. Кузнецов А.Е., Пинчук А. В., Суховицкий А.Л. Построение сетей IP-телефонии / Компьютерная телефония, 2000, №6.

10. Кульгин М. Технологии корпоративных сетей. Изд. “Питер”, 1999.

11. Ломакин Д. Технические решения IP-телефонии / Мобильные системы, 1999 №8.

12. Мюнх Б., Скворцова С. Сигнализация в сетях IP-телефонии. -Часть I, II/Сети и системы связи, 1999. - №13(47), 14(48).

13. Уиллис Д. Интеграция речи и данных. В начале долгого пути./Сети и системы связи, 1999.-№16.

14. Шнепс-Шнеппе М.А. Интеллектуальные услуги - это ДВО / Информ - курьер-связь, 2000 - №9.

15. Armitage Grenville. Quality of Service in IP Networks. - Macmillan Technical Publishing, 2000.

16. Anquetil L-P., Bouwen J., Conte A., Van Doorselaer. B. Media Gateway Control Protocol and Voice over IP Gateway. - Alcatel Telecommunications Review, 2nd Quarter 1999.

17. Black Uyless. Voice Over IP. - Prentice Hall, 08 / 99. 0130224634

18. Caputo R. Cisco Packetized Voice and Data Integration. - McGraw-Hill Cisco Technical Expert, 2000

19. Curtin P., Whyte B. Tigris - A gateway between circuit-switched and IP networks / Ericson Rewiew, 1999, №2.

20. DavidsonJ., Peters J. Voice Over IP Fundamentals. - Cisco Press, 2000.

21. DeMartino К. ISDN and the Internet. - Computer Networks, 1999.

22. Douskalis B. IP Telephony.
The Integration of Robust VolP Services. -Prentice Hall, 1999.

23. Durham D., Yavatkar R.. Inside the Internet's Resource Reservation Protocol: Foundations for Quality of Service, 2000

24. Faynberg I., Gabuzda L, Lu Hui-Lan. Converged Networks and Services: Internetworking IP and the PSTN. - John Wiley & Sons, 2000.

25. Goncalves M. Voice Over IP Networks. - McGraw Hill Publishing, 1998.

26. GoralskiW., Kolon M. IP Telephony. - McGraw Hill Publishing, 1999.

27. Harte . Voice Over Data Network Internet, Frame Relay, and ATM.-APDG Inc. 2000

28. Hersent 0, Gurle D., Petit Jean-Pierre. IP Telephony: Packet-Based Multimedia Communications Systems.- Addison-Wesley Pub Co, 2000.

29. Horak R. Communications systems & networks / Second Edition, M Et Т Books and IDG Books Worldwide, Inc., 2000

30. Houghton Т. F, E. C. Schloemer, E. S. Szurkowski, W. P. Weber. A packet telephony gateway for public network operators. - Bell Laboratories, Lucent Technologies - U.S.A., XVI World Telecom Congress Proceeding, 1997.

31. ITU-T Recommendation E.164. Numbering Plan for the ISDN Era. -1991.

32. ITU-T Recommendation G.711. Pulse Code Modulation of 3kHz Audio Channel.-1988.

33. ITU-T Recommendation G.723.1. Dual Rate speech coder for multimedia communication transmitting at 5.3 and 6.3 kit / sec. - 1996.

34. ITU-T Recommendation G.728. Coding of Speech at 16 kbit / s Using Low-delay Code Excited Linear Prediction (LD-CELP). -1992.

35. ITU-T Recommendation G.729. Speech codec for multimedia telecommunications transmitting at 8 / 13 kbit / s. - 1996.

36. ITU-T Recommendation H.225.0. Call signaling protocols and media stream packetization for packet-based multimedia communication systems. -Geneva, 1998.

37. ITU-T Recommendation H.245. Control protocol for multimedia communication. -Geneva, 1998

38. ITU-T Recommendation H.248. Gateway control protocol. - Geneva, 2000.

39. ITU-T Recommendation H.320. Narrow-band Visual Telephone Systems and Terminal Equipment. - 1996.



40. ITU-T Recommendation H.321. Adaptation of H. 320 Visual Telephone Terminals to B-ISDN Environments. - 1996.

41. ITU-T Recommendation H.322. Visual Telephone Systems and Terminal Equipment for Local Area Networks which Provide a Guaranteed Quality of Service. - 1996.

42. ITU-T Recommendation H.323. Packet based multimedia communication systems. - Geneva, 1998.

43. ITU-T Recommendation H.324. Terminal for Low Bit Rate Multimedia Communications. -1996.

44. ITU-T Recommendation Q.931. ISDN User-Network Interface Layer 3 Specification for Basic Call Control. - 1993.

45. Lee J. Implementing Voice Over IP. McGraw Hill Text, 2000.

46. Luczywek M. Cisco Voice over IP Handbook. IDG Books Worldwide, 2000.

47. McDysan D. Phd.Qos & Traffic Management in Ip & Atm Networks

48. Miller M. Voice over IP: Strategies for the Converged Network. IDG Books Worldwide, 2000.

49. Minoli D., Minoli E. Delivering Voice over IP Networks / John Willey & Sons, Inc., 1998.

50. Regis В., Donald G.. Voice & Data Communications Handbook Third Edition. - McGraw Hill Publishing, 2000.

51. Reid M. Multimedia conferencing over ISDN and IP networks using ITU-T H-series recommendations: architecture, control and coordination / Computer Networks, 1999 - №31.

52. RFC 2205. Resource Reservation Protocol (RSVP). Ver.1. Functional Specification. - September 1997.

53. RFC 2327. Session Description Protocol. M. Handley, V. Jacobson. April, 1998.

54. RFC 2543. SIP: Session Initiation Protocol. M. Handley, H. Schuizrinne, E. Schooler, J. Rosenberg. March 1999.

55. RFC 2616. Hypertext Transfer Protocol — HTTP / 1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999.

56. RFC 2705. Media Gateway Control Protocol (MGCP) Version 1.0. M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett. October 1999.

57. RFC 2865. Remote Authentication Dial In User Service (RADIUS). C.Rigney, S. Willens, A. Rubens, W. Simpson. June 2000.

58. RFC 2885.Megaco Protocol 0.8. F Cuervo, N. Greene, C. Huitema, A.Rayhan, B. Rosen, J. Segers. August 2000.

59. Toga J., Ott J. ITU-T standardization activities for interactive multimedia communications on packet-based networks: H.323 and related recommendations / Computer Networks, 1999.

60. Uyless Black. Voice over IP, Prentice Hall PTR, 2000.

61. Walter J. Goralski, Matthew C. Kolon. IP telephony / The McGraw-Hill Co..Inc.,2000.

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

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

Использование полосы пропускания канала

Скорость передачи, которую предусматривают имеющиеся сегодня узкополосные кодеки, лежит в пределах 1.2 - 64 Кбит/с. Естественно, что от этого параметра прямо зависит качество воспроизводимой речи. Существует множество подходов к проблеме определения качества. Наиболее широко используемый подход оперирует оценкой MOS (Mean Opinion Score), которая определяется для конкретного кодека как средняя оценка качества большой группой слушателей по пятибалльной шкале. Для прослушивания экспертам предъявляются разные звуковые фрагменты - речь, музыка, речь на фоне различного шума и т.д. Оценки интерпретируют следующим образом:

• 4-5 - высокое качество; аналогично качеству передачи речи в ISDN, или еще выше;

• 3.5-4- качество ТфОП (toll quality); аналогично качеству речи, передаваемой с помощью кодека АДИКМ при скорости 32 Кбит/с. Такое качество обычно обеспечивается в большинстве телефонных разговоров. Мобильные сети обеспечивают качество чуть ниже toll quality;

• 3-3.5- качество речи, по-прежнему, удовлетворительно, однако его ухудшение явно заметно на слух;

• 2.5-3 - речь разборчива, однако требует концентрации внимания для понимания. Такое качество обычно обеспечивается в системах связи специального применения (например, в вооруженных силах).

В рамках существующих технологий качество ТфОП (toll quality) невозможно обеспечить при скоростях менее 5 Кбит/с.

Подавление периодов молчания (VAD, CNG, DTX)

При диалоге один его участник говорит, в среднем, только 35 процентов времени. Таким образом, если применить алгоритмы, которые позволяют уменьшить объем информации, передаваемой в периоды молчания, то можно значительно сузить необходимую полосу пропускания. В двустороннем разговоре такие меры позволяют достичь сокращения объема передаваемой информации до 50%, а в децентрализованных многоадресных конференциях (за счет большего количества говорящих) - и более.
Нет никакого смысла организовывать многоадресные конференции с числом участников больше 5-6, не подавляя периоды молчания. Технология подавления таких периодов имеет три важные составляющие.

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

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

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

Поддержка прерывистой передачи (Discontinuous Transmission -DTX) позволяет кодеку прекратить передачу пакетов в тот момент, когда VAD обнаружил период молчания. Некоторые наиболее совершенные кодеры не прекращают передачу полностью, а переходят в режим передачи гораздо меньшего объема информации (интенсивность, спектральные характеристики), нужной для того, чтобы декодер на удаленном конце мог восстановить фоновый шум.

Генератор комфортного шума (Comfort Noise Generator - CNG) служит для генерации фонового шума.


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

Генератор CNG позволяет избежать таких неприятных эффектов. Простейшие кодеки просто прекращают передачу в период молчания, и декодер генерирует какой-либо шум с уровнем, равным минимальному уровню, отмеченному в период речевой активности. Более совершенные кодеки (G.723.1 Annex A, G. 729 Annex В) имеют возможность предоставлять удаленному декодеру информацию для восстановления шума с параметрами, близкими к фактически наблюдавшимся.

Размер кадра

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

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

Можно, казалось бы, заключить, что кодеки с меньшим размером кадра лучше в смысле такого важного критерия как минимизация задержки. Если, однако, учесть, что происходит при передаче информации по сети, то мы увидим, что к кадру, сформированному кодеком, добавляется множество дополнительной информации - заголовки IP (20 байтов), UDP (8 байтов), RTP (12 байтов). Для кодека с длительностью кадра 30 мс посылка таких кадров по сети привела бы к передаче избыточной информации со скоростью 10.6 кбит/с, что превышает скорость передачи речевой информации у большинства узкополосных кодеков.



Поэтому обычно используется пересылка нескольких кадров в пакете, при этом их количество ограничено максимально допустимой задержкой. В большинстве случаев в одном пакете передается до 60 мс речевой информации. Чем меньше длительность кадра, тем больше кадров приходится упаковывать в один пакет, т.е. задержка определяется вовсе не длиной кадра, а практически приемлемым объемом полезной нагрузки в пакете.

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

Чувствительность к потерям кадров

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

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

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

Влияние потерь кадров на качество воспроизводимой речи зависит от используемого кодека. Если потерян кадр, состоящий из N речевых отсчетов кодека G.711, то на приемном конце будет отмечен пропуск звукового фрагмента длительностью М*125 мкс. Если используется более совершенный узкополосный кодек, то потеря одного кадра может сказаться на воспроизведении нескольких следующих, так как декодеру потребуется время для того, чтобы достичь синхронизации с кодером - потеря кадра длительностью 20 мс может приводить к слышимому эффекту в течение 150 мс и более.

Кодеры типа G.723.1 разработаны так, что они функционируют без существенного ухудшения качества в условиях некоррелированных потерь до 3% кадров, однако при превышении этого порога качество ухудшается катастрофически.

Особенности передачи речевой информации по IP - сетям

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

телефонии на стандартизованной основе предложен

Первый в истории подход к построению сетей IP- телефонии на стандартизованной основе предложен Международным союзом электросвязи (ITU) в рекомендации Н.323 [42]. Сети на базе протоколов Н.323 ориентированы на интеграцию с телефонными сетями и могут рассматриваться как сети ISDN, наложенные на сети передачи данных. В частности, процедура установления соединения в таких сетях IP-телефонии базируется на рекомендации Q.931 [44] и аналогична процедуре, используемой в сетях ISDN.

Рекомендация Н.323 предусматривает довольно сложный набор протоколов, который предназначен не просто для передачи речевой информации по IP-сетям с коммутацией пакетов. Его цель - обеспечить работу мультимедийных приложений в сетях с негарантированным качеством обслуживания. Речевой трафик - это только одно из приложений Н.323, наряду с видеоинформацией и данными. Атак как ничего в технике (как и в жизни) не достается даром, обеспечение совместимости с Н.323 различных мультимедийных приложений требует весьма значительных усилий. Например, для реализации функции переключения связи (call transfer) требуется отдельная спецификация Н.450.2.

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

На рис 1.5. представлена архитектура сети на базе рекомендации Н.323. Основными устройствами сети являются: терминал (Terminal), шлюз (Gateway), привратник (Gatekeeper) и устройство управления конференциями (Multipoint Control Unit- MCU).

Рис. 1.5 Архитектура сети Н.323

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



Шлюз IP- телефонии реализует передачу речевого трафика по сетям с маршрутизацией пакетов IP по протоколу Н.323. Основное назначение шлюза - преобразование речевой информации, поступающей со стороны ТФОП, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP. Кроме того, шлюз преобразует сигнальные сообщения систем сигнализации DSS1 и ОКС7 в сигнальные сообщения Н.323 и производит обратное преобразование в соответствии с рекомендацией ITU H.246.

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

Рис. 1.6 Зона сети Н.323

Наиболее важными функциями привратника являются:

• регистрация оконечных и других устройств;

• контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS;

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

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

• ретрансляция сигнальных сообщений Н.323 между терминалами.

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

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

Устройство управления конференциями обеспечивает возможность организации связи между тремя или более участниками. Рекомендация Н.323 предусматривает три вида конференции (рис. 1.7):



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

Рис. 1.7 Виды конференции в сетях Н.323

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

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

Устройство управления конференциями состоит из одного обязательного элемента-контроллера конференций (Multipoint Controller - МС), и, кроме того, может включать в себя один или более про

цессоров для обработки пользовательской информации (Multipoint Processor - МР). Контроллер может быть физически совмещен с привратником, шлюзом или устройством управления конференциями, а последнее, в свою очередь, может быть совмещено со шлюзом или привратником.

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

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

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


Для децентрализованной конференции процессор не нужен.

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

• подключение через средства коммутируемого доступа или локальные сети терминалов, не поддерживающих протокол резервирования ресурсов (RSVP). Два таких прокси-сервера могут образовать в IP-сети туннельное соединение с заданным качеством обслуживания;

• маршрутизацию трафика Н.323 отдельно от обычного трафика данных;

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

• защиту доступа - доступность только для трафика Н.323.

Более подробно архитектура сети Н.323 будет рассмотрена в главе 5, а сейчас целесообразно сказать несколько слов о протоколах сигнализации, входящих в семейство Н.323.

Протокол RAS (Registration, Admission, Status) обеспечивает взаимодействие оконечных и других устройств с привратником. Основными функциями протокола являются: регистрация устройства в системе, контроль его доступа к сетевым ресурсам, изменение полосы пропускания в процессе связи, опрос и индикация текущего состояния устройства. В качестве транспортного протокола используется протокол с негарантированной доставкой информации UDP.

Протокол Н.225.0 (Q.931) поддерживает процедуры установления, поддержания и разрушения соединения. В качестве транспортного протокола используется протокол с установлением соединения и гарантированной доставкой информации TCP.

По протоколу Н.245 происходит обмен между участниками соединения информацией, которая необходима для создания логических каналов. По этим каналам передается речевая информация, упакованная в пакеты RTP/UDP/IP, которые рассматриваются в главе 4.



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

Сложность протокола Н.323 демонстрирует рис. 1.8, на котором представлен упрощенный сценарий установления соединения между двумя пользователями. В данном сценарии предполагается, что конечные пользователи уже знают IP-адреса друг друга. В обычном случае этапов бывает больше, поскольку в установлении соединения участвуют привратники и шлюзы; это будет рассмотрено в главе 6.

Рассмотрим шаг за шагом этот упрощенный сценарий.

1. Оконечное устройство пользователя А посылает запрос соединения - сообщение SETUP - к оконечному устройству пользователя ВнаТСР-порт1720.

2. Оконечное устройство вызываемого пользователя В отвечает на сообщение SETUP сообщением ALERTING, означающим, что устройство свободно, а вызываемому пользователю подается сигнал о входящем вызове.

3. После того, как пользователь В принимает вызов, к вызывающей стороне А передается сообщение CONNECT с номером ТСР-порта управляющего канала Н.245.

4. Оконечные устройства обмениваются по каналу Н.245 информацией о типах используемых речевых кодеков(G.729, G.723.1 и т.д.), а также о других функциональных возможностях оборудования, и оповещают друг друга о номерах портов RTP, на которые следует передавать информацию.

5. Открываются логические каналы для передачи речевой информации.

6. Речевая информация передаётся в обе стороны в сообщениях протокола RTP; кроме того, ведется контроль передачи информации при помощи протокола RTCP.

Рис. 1.8 Упрощённый сценарий установления соединения в сети Н.323

Приведенная процедура обслуживания вызова базируется на протоколе Н.323 версии 1.


Версия 2 протокола Н. 323 позволяет передавать информацию, необходимую для создания логических каналов, непосредственно в сообщении SETUP протокола Н.225.0 без использования протокола Н.245. Такая процедура называется “быстрый старт” (Fast Start) и позволяет сократить количество циклов обмена информацией при установлении соединения. Кроме организации базового соединения, в сетях Н.323 предусмотрено предоставление дополнительных услуг в соответствии с рекомендациями ITU H.450.X. Более детальный обзор сигнализации Н.323 приводится в главе 6.

Следует отметить еще одну важную проблему - качество обслуживания в сетях Н.323. Оконечное устройство, запрашивающее у привратника разрешение на доступ, может, используя поле transportQoS в сообщении ARQ протокола RAS, сообщить о своей способности резервировать сетевые ресурсы. Рекомендация Н.323 определяет протокол резервирования ресурсов (RSVP) как средство обеспечения гарантированного качества обслуживания, что предъявляет к терминалам требование поддержки протокола RSVP. К сожалению, протокол RSVP используется отнюдь не повсеместно, что оставляет сети Н.323 без основного механизма обеспечения гарантированного качества обслуживания. Это - общая проблема сетей IP-телефонии, характерная не только для сетей Н.323.

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

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

Второй подход к построению сетей IP-телефонии, предложенный рабочей группой MMUSIC комитета IETF в документе RFC 2543 [54], основан на использовании протокола SIP - Session Initiation Protocol. SIP представляет собой текст - ориентированный протокол, который является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF). Эта архитектура также включает в себя протокол резервирования ресурсов (Resource Reservation Protocol, RSVP, RFC 2205), транспортный протокол реального времени (Real-Time Transport Protocol, RTP, RFC 1889), протокол передачи потоков в реальном времени (Real-Time Streaming Protocol, RTSP, RFC 2326), протокол описания параметров связи (Session Description Protocol, SDP, RFC 2327), протокол уведомления о связи (Session Announcement Protocol, SAP).


Однако функции протокола SIP не зависят от любого из этих протоколов.

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

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

Тем не менее, протокол SIP поддерживает услуги интеллектуальной сети (IN), такие как преобразование (мэппинг) имён, переадресация и маршрутизация [8], что существенно для использования SIP в качестве протокола сигнализации в сети общего пользования, где приоритетной задачей оператора является предоставление широкого спектра телефонных услуг. Другой важной особенностью протокола SIP является поддержка мобильности пользователя, т.е. его способности получать доступ к заказанным услугам в любом месте и с любого терминала, а также способности сети идентифицировать и аутентифицировать пользователя при его перемещении из одного места в другое. Это свойство SIP не уникально, и, например, протокол Н.323 тоже в значительной степени поддерживает такую возможность. Сейчас настал момент, когда эта возможность станет главной привлекательной чертой сетей IP-телефонии нового поколения. Данный режим работы потребует дистанционной регистрации пользователей на сервере идентификации и аутентификации.



Перейдем непосредственно к архитектуре сетей, базирующихся на протоколе SIP (рис. 1.9).

Рис. 1.9 Пример сети на базе протокола SIP

Сеть SIP содержит основные элементы трех видов: агенты пользователя, прокси-серверы и серверы переадресации.

Агенты пользователя (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). Этот сервер интерпретирует и может перезаписывать заголовки запросов перед отправкой их к другим серверам (рис. 1.10). Ответные сообщения следуют по тому же пути обратно к прокси-серверу, а не к клиенту.

Рис. 1.10 Сеть SIP с прокси-сервером

Ниже представлен алгоритм установления соединения с помощью протокола SIP при участии прокси-сервера:

1. Прокси-сервер принимает запрос соединения INVITE от оборудования вызывающего пользователя.

2. Прокси-сервер устанавливает местонахождение клиента с помощью сервера определения местоположения (location server).

3. Прокси-сервер передает запрос INVITE вызываемому пользователю.

4. Оборудование вызываемого пользователя уведомляет последнего о входящем вызове и возвращает прокси-серверу сообщение о том, что запрос INVITE обрабатывается (код 100).


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

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

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

Сервер переадресации (Redirect server) определяет текущее местоположение вызываемого абонента и сообщает его вызывающему пользователю (рис. 1.11). Для определения текущего местоположения вызываемого абонента сервер переадресации обращается к серверу определения местоположения, принципы работы которого в документе RFC 2543 не специфицированы.

Рис. 1.11 Сеть SIP с сервером переадресации

Алгоритм установления соединения с использованием протокола SIP при участии сервера переадресации выглядит следующим образом:

1. Сервер переадресации принимает от вызывающей стороны запрос соединения INVITE и связывается с сервером определения местонахождения, который выдает текущий адрес вызываемого клиента.

2. Сервер переадресации передает этот адрес вызывающей стороне. В отличие от прокси-сервера, запрос INVITE к оборудованию вызываемого пользователя сервер переадресации не передает.

3. Оборудование вызывающего пользователя подтверждает завершение транзакции с сервером переадресации запросом АСК.

4. Далее оборудование вызывающего пользователя передает запрос INVITE на адрес, полученный от сервера переадресации.

5. Оборудование вызываемого пользователя уведомляет последнего о входящем вызове и возвращает вызывающему оборудованию сообщение о том, что запрос INVITE обрабатывается (код 100).

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



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

Дадим краткую характеристику самого протокола SIP. Следует заметить, что сообщения SIP могут переноситься как протоколом TCP, так и протоколом UDP.

Протокол SIP предусматривает 6 запросов и ответов на них. Сигнализация SIP дает возможность пользовательским агентам и сетевым серверам определять местоположение, выдавать запросы и управлять соединениями.

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

АСК - запрос подтверждает прием от вызываемой стороны ответа на команду INVITE и завершает транзакцию.

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

BYE - запрос используется вызывающей и вызываемой сторонами для разрушения соединения. Перед тем как разрушить соединение, пользовательские агенты отправляют этот запрос к серверу, сообщая о намерении прекратить сеанс связи.

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

3. Оборудование вызывающего пользователя подтверждает завершение транзакции с сервером переадресации запросом АСК.

4. Далее оборудование вызывающего пользователя передает запрос INVITE на адрес, полученный от сервера переадресации.

5. Оборудование вызываемого пользователя уведомляет последнего о входящем вызове и возвращает вызывающему оборудованию сообщение о том, что запрос INVITE обрабатывается (код 100).

6. Когда вызываемый абонент принимает вызов, об этом извещается оборудование вызывающего пользователя (код 200).


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

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

Дадим краткую характеристику самого протокола SIP. Следует заметить, что сообщения SIP могут переноситься как протоколом TCP, так и протоколом UDP.

Протокол SIP предусматривает 6 запросов и ответов на них. Сигнализация SIP дает возможность пользовательским агентам и сетевым серверам определять местоположение, выдавать запросы и управлять соединениями.

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

АСК - запрос подтверждает прием от вызываемой стороны ответа на команду INVITE и завершает транзакцию.

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

BYE - запрос используется вызывающей и вызываемой сторонами для разрушения соединения. Перед тем как разрушить соединение, пользовательские агенты отправляют этот запрос к серверу, сообщая о намерении прекратить сеанс связи.

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

REGISTER - запрос применяется клиентами для регистрации информации о местоположении с использованием серверов SIP.

Более подробная информация о протоколе SIP приведена в главе 7.

1.5.3 Сеть на базе MGCP и MEGACO

Третий подход к построению сетей IP-телефонии, основанный на использовании протокола MGCP [56], также предложен комитетом IETF, рабочей группой MEGACO.

При разработке этого протокола рабочая группа MEGACO опиралась на сетевую архитектуру, содержащую основные функциональные блоки трех видов (рис. 1.12):



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

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

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

Рис. 1.12 Архитектура сети на базе протокола MGCP

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

Шлюз сигнализации выполняет функции STP - транзитного пункта сети сигнализации ОКС7. Сами шлюзы выполняют только функции преобразования речевой информации. Один контроллер управляет одновременно несколькими шлюзами. В сети могут присутствовать несколько контроллеров. Предполагается, что они синхронизованы между собой и согласованно управляют шлюзами, участвующими в соединении. Вместе с тем, MEGACO не определяет протокола для синхронизации работы контроллеров. В ряде работ, посвященных исследованию возможностей протокола MGCP, для этой цели предлагается использовать протоколы Н.323, SIP или ISUP/IP.

Сообщения протокола MGCP переносятся протоколом без гарантированной доставки сообщений UDP. Рабочая группа SIGTRAN комитета IETF в настоящее время разрабатывает механизм взаимодействия контроллера шлюзов и шлюза сигнализации.

Шлюз сигнализации должен принимать поступающие из ТфОП пакеты трех нижних уровней системы сигнализации ОКС7 (уровней подсистемы переноса сообщений МТР) и передавать сигнальные сообщения верхнего, пользовательского, уровня к контроллеру шлюзов. Шлюз сигнализации также должен уметь передавать по IP-сети приходящие из ТфОП сигнальные сообщения Q.931 .



Основное внимание рабочей группы SIGTRAN уделяется вопросам разработки наиболее эффективного механизма передачи сигнальной информации по IP-сетям. Следует отметить, что существует несколько причин, по которым пришлось отказаться от использования для этой цели протокола TCP. Рабочая группа SIGTRAN предлагает использовать для передачи сигнальной информации протокол Stream Control Transport Protocol (SCTP), имеющий ряд преимуществ перед протоколом ТСР, основным из которых является значительное снижение времени доставки сигнальной информации и, следовательно, времени установления соединения - одного из важнейших параметров качества обслуживания.

Если в ТфОП используется сигнализация по выделенным сигнальным каналам (ВСК), то сигналы сначала поступают вместе с пользовательской информацией в транспортный шлюз, а затем передаются в контроллер шлюзов без посредничества шлюза сигнализации.

Отметим, что протокол MGCP является внутренним протоколом для обмена информацией между функциональными блоками распределенного шлюза, который извне представляется одним шлюзом. Протокол MGCP является master/slave протоколом. Это означает, что контроллер шлюзов является ведущим, а сам шлюз - ведомым устройством, которое должно выполнять все команды, поступающие от контроллера Call Agent.

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

Третий подход, предлагаемый организацией IETF (рабочая группа MEGACO), хорошо подходит для развертывания глобальных сетей IP-телефонии, приходящих на смену традиционным телефонным сетям. Более подробная информация о протоколе MGCP приведена в главе 8.

Рассмотрим алгоритмы установления и разрушения соединения с использованием протокола MGCP.


Первый пример охватывает взаимодействие протокола MGCP с протоколом ОКС7 (рис. 1.13).

Рис. 1.13 Установление и разрушение соединения с использованием протокола MGCP (Пример 1)

1. От телефонной станции АТС-А к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения в виде сообщения IAM протокола ISUP [6]. На рис. 1.13 шлюз сигнализации SG1 и SG2 совмещены с транспортными шлюзами TGW1 и TGW2 соответственно. Шлюз SG1 передает сообщение IAM к контроллеру шлюзов, который обрабатывает запрос и определяет, что вызов должен быть направлен к АТС-Б посредством шлюза TGW2.

2. Контроллер резервирует порт шлюза TGW1 (разговорный канал). С этой целью он передает к шлюзу команду CreateConnection. Отметим, что порт шлюза TGW1 может только принимать информацию (режим “recvonly”), так как он еще не осведомлен о том, по какому адресу и каким образом ему следует передавать информацию.

3. В ответе на эту команду шлюз TGW1 возвращает описание параметров сеанса связи.

4. Приняв ответ шлюза TGW1, контроллер передает команду CRCX второму шлюзу TGW2 с целью зарезервировать порт в этом шлюзе.

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

6. Далее контроллер шлюзов передает сообщение IAM к АТС-Б.

7. На сообщение IAM станция АТС-Б отвечает подтверждением АСМ, которое немедленно пересылается к станции АТС-А.

8. После того как вызываемый абонент примет вызов, АТС-Б передает к контроллеру шлюзов сообщение ANM.

9. Далее контроллер заменяет в шлюзе TGW1 режим “recvonly” на полнодуплексный режим при помощи команды MDCX.

10. Шлюз TGW1 выполняет и подтверждает изменение режима.

11. Контроллер передает сообщение ANM к АТС-А, после чего начинается разговорная фаза соединения.



12. Завершение разговорной фазы происходит следующим образом. В нашем случае вызвавший абонент Б дает отбой первым. АТС-Б передает через шлюз сигнализации сообщение REL к контроллеру шлюзов.

13. Приняв сообщение REL, контроллер шлюзов завершает соединение с вызванным абонентом.

14. Шлюз подтверждает завершение соединения и передает к контроллеру собранные за время соединения статистические данные.

15. Контроллер шлюзов передает сообщение RLC к АТС-Б с целью подтвердить разъединение.

16. Параллельно контроллер завершает соединение с вызвавшей стороной

17. ШлюзТGW1 подтверждает завершение соединения и передает к контроллеру собранные за время соединения статистические данные.

18. АТС-А подтверждает завершение соединения передачей сообщения RLC, после чего соединение считается разрушенным.

Второй пример иллюстрирует взаимодействие протокола MGCP с протоколами ОКС7 и Н.323 (рис. 1.14).

Рис. 1.14 Установление и разрушение соединения с использованием протокола MGCP (Пример 2)

1. С телефонной станции АТС-А к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения (сообщение IAM). На рис. 1.14 шлюз сигнализации SG1 также совмещен с транспортным шлюзом TGW1. Шлюз SG1 передает сообщение IAM контроллеру шлюзов, который обрабатывает запрос и определяет, что вызов должен быть направлен к оконечному устройству вызываемого пользователя - терминалу Н.323.

2. Контроллер шлюзов резервирует порт шлюза TGW1 (разговорный канал). С этой целью он передает к шлюзу команду CreateConnec-tion. И в этом примере порт шлюза TGW1 может только принимать информацию (режим “recvonly”).

3. В ответе на принятую команду шлюз TGW1 возвращает описание параметров связи.

4. Приняв ответ от шлюза TGW1, контроллер передает к привратнику сети Н.323 сообщение ARQ с alias адресом вызываемого абонента.

5. В ответ на сообщение ARQ привратник передает сообщение ACF с указанием транспортного адреса своего сигнального канала.

6. Контроллер передает запрос соединения SETUP на транспортный адрес сигнального канала привратника, при этом используется процедура Fast Start.


Привратник пересылает сообщение SETUP к вызываемому терминалу.

7. Вызываемый терминал передает запрос допуска к ресурсам сети ARQ.

8. В ответ на запрос ARQ привратник передает подтверждение запроса ACF.

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

10. Контроллер преобразует сообщение ALERTING в сообщение АСМ, которое немедленно пересылается к АТС-А.

11. После того как вызываемый пользователь примет входящий вызов, контроллер получит сообщение CONNECT.

12. Контроллер шлюзов меняет в шлюзе TGW1 режим “recvonly” на полнодуплексный режим.

13. Шлюз TGW1 выполняет и подтверждает изменение режима соединения.

14. Контроллер передает сообщение ANM к АТС-А, после чего начинается разговорная фаза соединения, в ходе которой оборудование вызвавшего пользователя передает речевую информацию, упакованную в пакеты RTP/UDP/IP, на транспортный адрес RTP-канала терминала вызванного абонента, а тот передает пакетированную речевую информацию на транспортный адрес RTP-канала терминала вызвавшего абонента. При помощи канала RTCP ведется контроль передачи информации по RTP каналу.

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

16. Контроллер шлюзов передает сообщение RELEASE к АТС-А с целью завершения соединения.

17. Кроме того, контроллер передает к шлюзу команду DLCX.

18. Шлюз подтверждает завершение соединения и передает к контроллеру собранные за время соединения статистические данные.

19. После вышеописанных действий контроллер и оконечное оборудование извещают привратник об освобождении занимавшейся полосы пропускания.


С этой целью каждый из участников соединения посылает привратнику по каналу RAS запрос выхода из соединения DRQ, на который привратник должен передать подтверждение DCF.

20. От АТС-А приходит подтверждение разъединения RLC, после чего соединение считается разрушенным.

Следует заметить, что алгоритм взаимодействия протоколов SIP и MGCP не сильно отличается от вышеописанного алгоритма.

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

Международный союз электросвязи в проекте версии 4 рекомендации Н.323 ввел принцип декомпозиции шлюзов. Управление функциональными блоками распределенного шлюза будет осуществляться контроллером шлюза - Media Gateway Controller - при помощи адаптированного к Н.323 протокола MEGACO, который в рекомендации Н.248 назван Gateway Control Protocol.

Сообщения протокола MEGACO отличаются от сообщений протокола MGCP, но процедуры установления и разрушения соединений с использованием обоих протоколов идентичны, поэтому описание процедуры установления соединения на базе протокола MEGACO здесь не приводится. Эти процедуры, вместе с детальным анализом протокола MEGACO, рассматриваются в главе 9.

1.5.4 Сравнение подходов к построению сети IP-телефонии

В настоящее время для построения хорошо функционирующих и совместимых с ТфОП сетей IP-телефонии подходят протоколы Н.323 и MGCP. Как уже отмечалось, протокол SIP несколько хуже взаимодействует с системами сигнализации, используемыми в ТфОП (сравнительный анализ протоколов Н.323 и SIP приведен в главе 7).

Подход, основанный на использовании протокола MGCP, обладает весьма важным преимуществом перед подходом, предложенным ITU в рекомендации Н.323: поддержка контроллером шлюзов сигнализации ОКС7 и других видов сигнализации, а также прозрачная трансляция сигнальной информации по сети IP-телефонии. В сети, построенной на базе рекомендации Н.323, сигнализация ОКС7, как и любая другая сигнализация, конвертируется шлюзом в сигнальные сообщения Н.225.0 (Q.931).



Основным недостатком третьего из приведенных в данном параграфе подходов является незаконченность стандартов. Функциональные составляющие распределенных шлюзов, разработанные разными фирмами-производителями телекоммуникационного оборудования, практически несовместимы. Функции контроллера шлюзов точно не определены. Не стандартизированы механизмы переноса сигнальной информации от шлюза сигнализации к контроллеру и в обратном направлении. К недостаткам можно отнести также отсутствие стандартизированного протокола взаимодействия между контроллерами. Кроме того, протокол MGCP является протоколом управления шлюзами, но не предназначен для управления соединениями с участием терминального оборудования пользователей (IP-телефонов). Это означает, что в сети, построенной на базе протокола MGCP, для управления терминальным оборудованием должен присутствовать привратник или сервер SIP.

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

В последнем из упомянутых подходов (в проекте версии 4 рекомендации Н.323) ITU-Т ввел принцип декомпозиции шлюзов, использованный в третьем подходе. Управление функциональными блоками распределенного шлюза будет осуществляться контроллером шлюза - MGC (Media Gateway Controller) при помощи протокола MEGACO/H.248. В проекте версии 4 рекомендации Н.323 предусмотрена также возможность прозрачной передачи сигнализации ОКС7 и других видов сигнализации по сетям IP-телефонии и обработка сигнализации всех видов привратником без преобразования в сигнальные сообщения Н.225.0.

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

Йорка Мартин ван Бюрен отправил

В 1829 году губернатор Нью- Йорка Мартин ван Бюрен отправил президенту США Эндрю Джексону письмо следующего содержания:
Уважаемый господин Президент!
Системе каналов в нашей стране угрожает распространение новой формы транспорта, называемой “железные дороги”. Правительство должно сохранить каналы по следующим причинам.
1) Если суда будут вытеснены железными дорогами, это приведёт к большой безработице.
2) Производители судов сильно пострадают, а поставщики буксирных канатов, кнутов и конной упряжи останутся без средств к существованию.
3) Суда абсолютно необходимы для обеспечения обороны страны.
Эти слова настолько похожи на рекомендации относительно IP-телефонии, услышанные авторами всего лишь два года назад на одном научно-техническом совете, что заставляют удивиться такому совпадению уровней и мотивов в разные времена и в разных странах. Однако технический прогресс определяется не этим, и сегодняшняя IP-телефония обслуживает около двадцати миллионов абонентов во всем мире, а операторские компании постепенно превращают IP-телефонию в индустрию, не зависящую от административно-командных решений. Примером для отечественных операторов может служить компания AT&T, уже применяющая передачу речи по IP-сетям и объявившая о долгосрочном плане перевода всего своего речевого графика дальней связи на платформу IP. В составе совместного глобального проекта AT&T и British Telecom в течение четырех лет создают новую глобальную IP-сеть стоимостью 10 миллиардов долларов, которая будет предоставлять услуги интегрированной передачи речи и данных многонациональным бизнес - абонентам.
А начиналось все отнюдь не так безоблачно. Первая попытка реализовать IP-телефонию была предпринята в 1983 году в Кембридже, Массачусетс. В состав оборудования рабочих станций, закрепленных за отдельными проектами Интернет, была включена так называемая “речевая воронка”, выполнявшая функции цифровизации речи, пакетирования и передачи пакетов через Интернет между офисами Bolt Beranekand Newman (BBN) на Восточном и Западном побережьях США.
С позиций приписываемого А. Эйнштейну высказывания - “открытия делаются тогда, когда все знают, что этого сделать нельзя, а потом появляется кто-то, кто этого не знает и совершает открытие” - те эксперименты 80-х годов относились к первой части данной формулировки. Немногочисленные студенты и энтузиасты IP-телефонии первого поколения были должны использовать на каждом конце одно и то же клиентское программное обеспечение, находиться в режиме подключения к системе в момент вызова, проводить значительную часть времени, терзая регулировки громкости и компрессии в попытках устранить эхо, чтобы получше слышать друг друга. Качество речи портили длинные паузы, вызванные переменной задержкой пакетов, обрезанная речь, получавшаяся в результате выбрасывания пакетов, эхо обратной связи из-за близкого расположения громкоговорителя компьютера и микрофона.
Открытие IP-телефонии как профессиональной технологии совершила израильская компания VocalTec, сумевшая к 1995 году собрать воедино достижения в областях цифровой обработки сигналов (DSP), кодеков, компьютеров и протоколов маршрутизации, чтобы сделать реальными разговоры через Интернет без оглядки на расстояние между абонентами и длительность разговора. О системных аспектах, основных сценариях и алгоритмах IP-телефонии говорится в главах 1 и 2.
Начиная с 1995 года, для IP-телефонии стали использоваться два метода звуковой компрессии - GSM, с близкой к 5:1 степенью компрессии исходного звукового сигнала, и TrueSpeech компании DSP Group, Inc., обеспечивающей коэффициент компрессии 18:1 с малозаметной потерей качества звука при декомпрессии. Это обсуждается в главе 3 данной книги. Там же рассматриваются аудио-стандарты G.7xx, включенные в рекомендованный Международным союзом электросвязи (ITU-T) “зонтичный” стандарт Н.323, которому целиком посвящены главы 5 и 6. Другие концептуальные подходы и стандартные протоколы IP-телефонии SIP, MGCP и MEGACO рассмотрены в главах 7, 8 и 9, соответственно.
В дополнение к алгоритмам компрессии/декомпрессии выборок речи и стандартным протоколам, IP-телефония занимается техникой борьбы с задержками в Интернет.


Пакеты могут следовать к месту назначения по разным путям и могут не все поступить к месту сборки вовремя и в надлежащем порядке. Если бы это были обычные данные, то запоздавшие или поврежденные пакеты можно было бы просто отбросить, а протокол контроля ошибок в рабочей станции запросил бы повторную передачу этих пакетов. Но такая концепция не может быть принята для пакетов, содержащих компрессированную речь, без опасности значительного ухудшения качества разговоров, которые, разумеется, должны происходить в реальном времени. Только если отбрасывается небольшой процент пакетов, скажем, 15%, пользователи на каждом конце могут не заметить пробелов в разговоре. Когда потеря пакетов достигает 20%, качество разговора ощутимо ухудшается. Общему анализу протоколов Интернет для IP-телефонии посвящена глава 4, а проблемы качества обслуживания (QoS) для IP-телефонии рассматриваются в главе 10.
Изделия для современной IP-телефонии предоставляют множество функциональных возможностей и позволяют решить проблемы качества передачи речи, что и обеспечивает рост коммерчески привлекательных и высококачественных услуг IP-телефонии. Выигрыш от использования компьютера для телефонной связи - по отношению к обычному телефону - заключается в том, что пользователь получает преимущества услуг интегрированной передачи речи и данных. Наиболее общие функциональные возможности, встречающиеся в широком спектре изделий IP-телефонии, рассматриваются в заключительной, 11 главе книги. В этой главе излагаются некоторые принципы и идеи отечественной платформы Протей, реализующей самые современные услуги IP-телефонии применительно к условиям Взаимоувязанной сети связи России.
Впрочем, относительно современности обольщаться не следует ни авторам, ни читателям. Мы имеем дело с новой, бурно развивающейся областью, идеи и изделия появляются с ошеломляющей частотой, и самым трудным для авторов при подготовке книги было поставить точку.
В том, что это, в конце концов, удалось, заслуга тех, кто поддерживал авторов и помогал им советами, информацией и просто созданием стимулирующей атмосферы, в первую очередь - В.А.Соколова, Ю.В. Аксенова, А.Е. Кузнецова, В.Д. Кадыкова, а также студентов Санкт-Петербургского университета телекоммуникаций им. проф. М.А.Бонч-Бруевича - А.Б.Гольдштейна, В.В. Саморезова, С.Б. Шурыгиной. Результат всех этих усилий перед читателем.
Замечания и предложения по материалам книги просьба направлять по адресу nio1@loniis.spb.ru, а информацию о других книгах и разработках можно найти нa Web-сайте www.loniis.ru.

---

---