Глава 4

Протоколы сети Интернет

 

4.1    Интернет ab 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, RANDhNPL. Последняя из них, Национальная физическая лаборатория (National Physical Laboratory - NPL), постро­ившая экспериментальную сеть пакетной коммутации на скорости 768 Кбит/с, более известна тем, что руководитель разработки До­нальд Дэвис является автором термина «пакет».

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

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

В 1971 году уже имеется 15 узлов (23 рабочие станции), и Рей Момлинсон изобретает программу электронной почты для переда­чи сообщений по распределенной сети. Оригинальная программа была создана на базе двух программ: программы внутримашинной электронной почты (SENDMSG) и экспериментальной программы пе­ресылки файлов (CPYNET). Из клавиш пунктуации на телетайпе Mod­el 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 Com­munications» статью «A Protocol for Packet Network Intercommunica­tion» со спецификацией протокола TCP, ставшей вскоре основой Ин­тернет. Об истории этой публикации рассказывается в колонке ре­дактора журнала «Сети и системы связи» (№11, 1999). Серф и Кан решали, чье имя поставить первым в спецификации протокола TCP, и бросили монетку. Первым оказался Винсент Серф, и именно он, со временем, стал известен широкой публике, занял должность вице-президента MCI и получил признание как один из основателей сети Интернет.

Тогда же появляется первый список адресов электронной поч­ты - MsgGroup. Самым популярным неофициальным списком ста­новится список любителей научной фантастики - SF-Lovers. Спустя полтора года разрабатывается спецификация электронной почты (RFC 733). В 1976 году в лаборатории Александра Белла (Bell Labo­ratories) корпорации 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 году Уильям Гибсон, в романе «Neuromancer», вво­дит термин «гиперпространство». Количество рабочих станций, под­ключенных к сети, достигает 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.aov  и электронная почта Dresident@whitehouse.QOv  Б. Клинтона. Понадобилось менее 2 лет, чтобы в Интернет появились адреса правительств большинства дру­гих стран, включая, например, адрес Ватикана - www.vatican.va. В том же 1995 году коллектив программистов Sun Microsystems под руководством Джеймса Гозлинга (James Gosling) создали язык про­граммирования Java, радикально изменивший сам смысл програм­мирования Интернет-приложений.

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

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

4.2   Стандарты в сфере Интернет

 

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

Существует ряд организаций, которые участвуют в различных мероприятиях по администрированию и поддержке Интернет. В кон­тексте данной книги среди этих организаций следует упомянуть CERT, IAB, IETF, IESG, IRTF, ICANN и The Internet Society (Общество Интер­нет, известное также как ISOC).

Группа реагирования на нарушения компьютерной защиты (CERT) -группа экспертов Университета Карнеги-Меллона, которая отвечает за вопросы, связанные с нарушением компьютерной защи­ты в сети Интернет. CERT была образована ARPA в ноябре 1998 года как реакция на ряд инцидентов, связанных с появлением вирусных программ самотиражирования.

Совет по архитектуре Интернет (1АВ)> первоначально - Коорди­национный совет сети Интернет - добровольный орган, имеющий в своем составе 12 экспертов, которые используют ресурсы своих компаний-спонсоров для того, чтобы способствовать интересам Ин­тернет. IAB контролирует и координирует деятельность двух проблем­ных (рабочих) групп: IETF и IRTF. В совокупности, эти организации вырабатывают техническую политику и направления работы.

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

Корпорация Интернет по присвоению имен и номеров (ICANN) -некоммерческая организация, образованная в 1999 году. ICANN была создана для того, чтобы взять на себя полномочия федерального органа IANA по распределению общеизвестных номеров портов, управлению IP-адресами и присвоению имён доменов. Номера пор­тов представляют собой 16-битовые величины в диапазоне от 0 до 65 536. Общеизвестные порты нумеруются числами из диапазона от 0 до 1 023 и используются системными процессами или прикладны­ми программами. Примерами общеизвестных портов являются: порт 25 для протокола SMTP (Простого протокола пересылки почты), порт 80 для протокола HTTP (Гипертекстового транспортного протокола) и порт 107 для Дистанционной службы Telnet. В среде клиент/сервер Интернет на базе протокола TCP/IP, сервер назначает порты с учё­том протокола прикладного уровня, который выполняется на клиент­ском уровне. ICANN также присваивает IP-адреса организациям, желающим поместить компьютеры в Интернет; количество адресов зависит от размера организации.

Общество Интернет(ISOC)- добровольная организация, которая представляет собой некоторую формальную структуру для админи­стрирования Интернет. Общество Интернет предоставило официаль­ные полномочия IESG принимать решения по стандартам.

 

4.3   Адресация

 

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

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

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

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

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

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

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

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

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

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

Как отмечалось выше, корпорация Интернет по присвоению имен и номеров (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 положение о бесклассовой междоменной маршрутизации(СЮЙ). Технология CIDR построена на концепции суперсети (supernetting), состоящей из группы подсетей, каждой из которых при­сваивается адрес подсети. Но в целом совокупность подсетей вы­глядит, как единая сеть с одним префиксом (например, для Европы выделены префиксы 194 и 195). Благодаря технологии CIDR, сокра­щается число маршрутов и, следовательно, размер и сложность таб­лиц маршрутизации, которые должны поддерживать коммутаторы и маршрутизаторы. Несмотря на то, что CIDR привносит известную гибкость в схему IP-адресации, она, тем не менее, не решает глав­ной проблемы - недостатка IP-адресов в обозримом будущем.

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

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

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

Сам же ICANN получил от IANA полномочия по администрирова­нию Интернет-адресов. При администрировании со стороны IANA, ответственность за присвоение TLD возлагалась на центр сетевой информации Интернет(InterNlC) компании Network Solutions Inc. В те­чение первых десятков лет существования Интернет, присвоение доменов было бесплатным. Позже, InterNIC начал брать плату за до­мены .com в размере $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), упаковывает данные в пакеты. Пакет -это протокольная единица, которая содержит информацию верхних уровней, и служебные поля (аппаратные адреса, порядковые но­мера, подтверждения и т.д.), необходимые для функционирования протоколов этого уровня.

 

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

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

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

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

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

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

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

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

 

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

 

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

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

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

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

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

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

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

Рис. 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 Ad­dressing Architecture»).

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

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

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

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

FEDC:0A96:0:0:0:0:7733:567A.

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

0:0:0:0:0:FFFR194.135.75.104.

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

•   unicast;

•   multicast;

•   anycast.

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

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

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

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

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

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

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

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

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

 

Рис. 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, в ядре сети могут не обеспечивать фрагментации, а только пе­редавать сообщение протокола ICMP - «слишком длинный пакет» к конечному узлу, который должен соответственно уменьшить раз­мер пакета.

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

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

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

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

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

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

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

 

4.7        Протокол TCP

 

Протокол управления передачей информации -Transmission Con­trol 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.

 

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

 

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

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

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

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

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

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

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

 

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

 

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

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

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

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

 

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

 

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

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

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

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

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

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

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

 

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

 

Протокол TCP предоставляет получателю пакетов возможность регулировать передаваемый к нему отправителем поток данных. Этот механизм основан на том, что при передаче флага подтверждения получения пакета (АСК) в TCP-сегменте передается указатель объе­ма данных (так называемое «окно» TCP-соединения), которые могут 120

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

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

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

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

 

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

 

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

Рис. 4.5  Заголовок пакета TCP

 

Порт отправителя (Source Port, 16 битов).

Порт получателя (Destination Port, 16 битов).

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

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

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

Резерв (Reserved, 6 битов) - зарезервированное поле.

Флаги управления (слева направо):

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

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

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

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

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

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

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

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

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

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

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

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

 

4.8   Протокол UDP

 

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

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

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


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

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

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

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

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

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

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

 

4.9   Требования к современным IP-сетям

 

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

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

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

Требования к скорости передачи информации для разных услуг варьируются очень широко. Например, передача данных телеметрии в реальном времени может требовать скорости несколько бит/с, для речевой информации удовлетворительного качества потребуется от 4 до 32 Кбит/с, для обеспечения качества на уровне ТфОП необходимо до 64 Кбит/с, передача видео требует от десятков Кбит/с до де­сятков Мбит/с (HDTV), в зависимости от характеристик системы (раз­мер изображения, частота кадров, способ кодирования и т.д.). Тре­бования ко времени доставки тоже могут быть различны. Например, при организации речевой связи допускается сквозная задержка от 12 мс при отсутствии эхокомпенсации (G.164), и до 400 мс при ее наличии. При этом, как отмечалось в главе 3, при стремлении вели­чины задержки к верхнему пределу субъективная оценка качества связи падает, взаимодействие становится полудуплексным. Для не интерактивных приложений (например, предоставление видеоин­формации по запросу) могут допускаться задержки более 500 мс, ко­торые ограничиваются только возможностью пользователя нормаль­но управлять процессом воспроизведения и возможностями буфе­ризации данных в приемнике.

Процесс передачи данных по сетям с коммутацией пакетов под­вержен влиянию статистически изменяющейся задержки (джиттера), возникающей при обработке очередей в узлах сети. Джиттер ком­пенсируется приемником путем использования буфера воспроизве­дения. Приемник должен обладать информацией о статистических характеристиках задержки, чтобы предусмотреть необходимое ме­сто в буферном накопителе. Например, если допустимы потери 0,1% пакетов, величина буфера должна поддерживаться на уровне, пре­вышающем переменную составляющую задержки поступающих па­кетов в 99,9% случаев. Таким образом, высокий уровень джиттера заставляет мириться либо с большим количеством мест в буферном накопителе и, как следствие, с большими задержками, либо с высо­ким уровнем потерь информации.

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

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

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

Скажем несколько слов о надежности. Стремление обеспечить в рамках IP-сетей предоставление услуг телефонии, аналогичных ус­лугам ТфОП, сталкивается с проблемой физической надежности сети. Пользователи ТфОП привыкли, что услуги доступны 24 часа в сутки/ дней в неделю, т.е. всегда. Эта привычка вполне обоснована, так как АТС и другое оборудование, составляющее основу ТфОП, разработано с учетом коэффициента готовности 99.999%, что эквивалентно 3 часам простоя за 40 лет (!) эксплуатации. Так исторически сложи­лось, что в мире сетей передачи данных действуют совершенно дру­гие стандарты. Большинство людей не смогут ответить, когда послед­ний раз не работал их телефон, однако они без труда припомнят, ко­гда отказала локальная сеть, или не было доступа к Интернет. Созда­ние универсальной сетевой инфраструктуры на базе протокола IP по­требует пересмотреть требования к надежности IP-сетей.

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

 

4.10                        Протоколы RTP и RTCP

 

Приложения, обеспечивающие передачу речевой и видеоинфор­мации, используют сервис транспортного уровня без установления соединений {например, UDP). При этом каждое приложение может обеспечивать формирование полезной нагрузки пакетов специфи­ческим образом, включая необходимые для функционирования поля ч и данные. Однако, как показал приведенный в предыдущем парагра­фе анализ, данные разной природы (речь, видео) имеют общие осо­бенности, которые требуют обеспечения вполне определенной функ­циональности при их передаче по сети. Это позволяет сформиро­вать некий общий транспортный уровень, объединяющий функции, общие для потоковых данных разной природы, и используемый все­ми соответствующими приложениями, придав протоколу этого уров­ня статус стандарта. Комитетом IETF был разработан протокол транс­портировки информации в реальном времени - Realtime Transport Protocol (RTP), который стал базисом практически для всех прило­жений, связанных с интерактивной передачей речевой и видеоинфор­мации по сети с маршрутизацией пакетов.

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

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

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

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

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

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

На рис. 4.7 представлен основной заголовок RTP-пакета, содер­жащий ряд полей, которые идентифицируют такие элементы, как формат пакета, порядковый номер, источник информации, границы и тип полезной нагрузки.

Рис. 4.7  Основной заголовок RTP-пакета

 

V (2 бита) - поле версии протокола. Текущая версия протокола -вторая.

Р (1 бит) - поле заполнения. Сигнализирует о наличии заполне­ния в конце поля полезной нагрузки. Заполнение применяется, ко­гда приложение требует, чтобы размер полезной нагрузки был кра­тен, например, 32 битам.

X (1 бит) - поле расширения заголовка. Служит для индикации того, что за основным заголовком следует дополнительный заголовок, ис­пользуемый в экспериментальных расширениях протокола RTP.

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

М (1 бит) - поле маркера. Обычно используется для указания гра­ниц потока данных. Смысл бита маркера зависит от типа полезной нагрузки. В случае передачи видеоинформации он определяет ко­нец кадра. При передаче речевой информации маркер указывает начало периода активности после периода молчания.

РТ (7 битов) - поле типа полезной нагрузки. Идентифицирует тип полезной нагрузки и формат данных, включая сжатие и шифрование, В стационарном состоянии отправитель использует только один тип полезной нагрузки в течение сеанса, но он может его изменить в от­вет на изменение условий, если об этом сигнализирует протокол управления транспортировкой информации в реальном времени (Real-Time Transport Control Protocol).

Порядковый номер пакета (Sequence Number, 16 битов). Каждый источник начинает нумеровать пакеты с произвольного номера, уве­личиваемого затем на единицу с каждым переданным пакетом RTR. Это позволяет обнаруживать потери пакетов и определять порядок пакетов с одинаковым временным штампом. Несколько последова­тельных пакетов могут иметь один и тот же штамп, если логически они порождены в один и тот же момент, как, например, пакеты, при­надлежащие одному и тому же видеокадру.

Временной штамп (Timestamp, 32 бита). Момент времени, в кото­рый был создан первый октет данных полезной нагрузки. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя.

Идентификатор SSRC {Synchronization Source Identifier, 32 бита) -поле идентификатора источника синхронизации. Псевдослучайное число, которое уникальным образом идентифицирует источник в те­чение сеанса и не зависит от сетевого адреса. Это число играет важ­ную роль при обработке порции данных, поступившей от одного ис­точника.

Идентификатор CSRC (Contributing Source Identifier, 32 бита) - спи­сок полей идентификаторов источников, участвующих в создании RTP-пакета. Устройство смешивания информации (миксер) вставля­ет целый список SSRC идентификаторов источников, которые уча­ствовали в построении данного RTP-пакета. Количество элементов в списке: от 0 до 15. Если число участников более 15, выбираются первые 15. Примером может служить речевая конференция, в кото­рой передаются RTP-пакеты с речью всех участников - каждый со своим идентификатором SSRC. Они-то и образуют список иденти­фикаторов CSRC. Вся конференция имеет общий идентификатор SSRC.

Доставка RTP-пакетов контролируется специальным протоколом RTCP (Real Time Control Protocol).

Основной функцией протокола RTCP является организация обрат­ной связи приемника с отправителем информации для отчета о ка­честве получаемых данных. Протокол RTCP передает сведения (как от приемника, так и от отправителя) о числе переданных и потерян­ных пакетов, значении джиггера, задержке и т.д. Эта информация может быть использована отправителем для изменения параметров передачи, например для уменьшения коэффициента сжатия инфор­мации с целью улучшения качества ее передачи. Более подробное описание протоколов RTP и RTCP можно найти в RFC-1889.

 

4.11                        Многоадресная рассылка

 

Основной целью группового вещания является создание эффек­тивного механизма передачи данных по схеме «один-ко-многим» и «многие-ко-многим».

Традиционные механизмы доставки пакетов стека TCP/IP мало пригодны для поддержки группового вещания. Например, исполь­зование уникальных адресов (unicast) приводит к необходимости ус­тановления многочисленных двухточечных соединений между отпра­вителем и каждым из получателей.

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

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

Основными протоколами, на базе которых реализуется многоад­ресная рассылка в IP-сетях, являются протоколы IGMP (Internet Group Management Protocol), DVMRP - (Distance Vector Multicast Routing Protocol), PIM (Protocol Independent Multicast).

Основной целью группового вещания является создание эффек­тивного механизма передачи данных по схеме «один-ко-многим» и «многие-ко-многим».

 

Глава 5

Архитектура

Н.323

 

5.1    Стандарты мультимедийной связи

 

Работа над рекомендациями ITU-T серии Н, уже упоминавшими­ся в первых четырех главах, началась отнюдь не для IР-телефонии. Более 10 лет тому назад Международный союз электросвязи начал разработку рекомендаций для будораживших умы связистов того по­коления систем видеотелефонной и мультимедийной связи. Термин «мультимедийная связь» обозначает связь двух или более пользова­телей, обменивающихся одновременно речью, видеоинформацией и данными.

Первая рекомендация из этой серии, Н.320, была выпущена в 1990 году и относилась к системам видеотелефонии, ориентиро­ванным на работу в узкополосной ISDN. Следующие рекомендации ITU-T разрабатывались для систем мультимедийной связи, рабо­тающих в разном сетевом окружении.

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

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

Таблица 5.1. Рекомендации ITU-T по видеотелефонии и мультимедийной связи

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

Представляется полезным кратко рассмотреть особенности каж­дой из систем мультимедийной связи, предложенных ITU-T.

Рекомендация Н.320 специфицирует системы видеотелефонной связи по В-каналам узкополосной ISDN со скоростью 64 Кбит/с и со скоростями до 1.920 Мбит/с, кратными 64 Кбит/с. Видеоинформация кодируется по алгоритму, предложенному ITU-T в рекомендации Н.261. Алгоритм поддерживает два формата изображений: необя­зательный формат CIF с разрешением 352 х 288 пикселей и обяза­тельный формат QCIF с разрешением 176 х 144 пикселей- Частота кадров - 30 кадров/с или ниже. Для кодирования аудиоинформации используются алгоритм G.711 - импульсно-кодовая модуляция со скоростью передачи 64 Кбит/с, алгоритм G.722 - адаптивно-дифференциальная импульсно-кодовая модуляция, использующая полосу частот 7кГц и скорости передачи 48, 56, 64 Кбит/с, и G.728 - алго­ритм кодирования LD-CELP со скоростью передачи 16 Кбит/с (об этих алгоритмах уже упоминалось в главе 3). Процедуры установления и разрушения соединений, формирования кадра данных и мультип­лексирования, а также ряд эксплуатационных и административных функций описываются в рекомендациях Н.221, Н.230 и Н.242.

Рекомендация Н.321 определяет механизм адаптации узкополос­ных терминалов видеотелефонной связи Н.320 к работе е широко­полосной ISDN. Следует отметить, что широкополосные ISDN бази­руются на транспортной технологии ATM, которая обеспечивает га­рантированное качество обслуживания. В терминалах Н.321 реали­зована часть требований, предъявляемых к широкополосным терми­налам видеотелефонной связи Н.310. При этом обязательным тре­бованием Международного союза электросвязи является совмести­мость терминалов Н.310, Н.321 и Н.320.

В рекомендации Н.322 представлены технические требования к узкополосным системам видеотелефонии, работающий в локаль­ных вычислительных сетях с гарантированным качеством обслужи­вания, эквивалентным качеству обслуживания ISDN. Применение данной спецификации ограничено ЛВС IsoEthernet.

Рекомендация Н.323 специфицирует системы мультимедийной связи, которые ориентированы на работу в сетях с коммутацией паке­тов, не обеспечивающих гарантированное качество обслуживания. К таким сетям относятся локальные вычислительные сети Ethernet и Token Ring, глобальная сеть Интернет и другие сети, поддерживающие технологию маршрутизации пакетов IP или IPX.

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

В рекомендации Н. 324 Международный союз электросвязи предста­вил технические требования к системам низкоскоростной мультимедий­ной связи, ориентированным на работу по аналоговым линиям ТфОП с использованием модемов. С учетом того, что скорость модемной пе­редачи ограничена, в системах реализуются алгоритмы кодирования речи, видеоинформации и данных с высокой степенью сжатия.

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

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

 

5.2   Архитектура систем видеотелефонии в узкополосных ISDN

 

В 1990 году Международный союз электросвязи разработал ре­комендацию Н.320, принятую впоследствии всеми ведущими произ­водителями оборудования в качестве стандарта для реализации сис­тем видеоконференций в узкополосных ISDN.

Система видеоконференций Н.320 включает в себя две основные группы компонентов - терминалы и устройства управления конфе­ренциями (Multipoint Control Units - MCU). Терминал представляет собой оборудование конечного пользователя, в то время как устрой­ство управления конференциями является сетевым оборудованием, позволяющим организовывать видеоконференции с участием мно­жества пользователей. Разрешается каскадное подключение друг к другу нескольких устройств MCU в рамках одной конференции. На рис. 5.1 показана архитектура системы видеоконференций, функцио­нирующей в узкополосной ISDN.

Рис. 5.1   Система видеоконференций в узкополосной ISDN

 

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

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

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

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

Для установления, поддержания и разрушения соединений сис­темы Н.320 используют протокол сигнализации Q.931 [7]. Обмен сиг­нальными сообщениями между терминалом и опорной АТС произ­водится по D-каналу. Следует отметить также, что сигнальные сооб­щения не мультиплексируются с пользовательской и управляющей информацией.

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

Аудиокодеки кодируют и декодируют речевую информацию. Ре­комендация Н.320 определила в качестве основного алгоритма ко­дирования речевой информации алгоритм G.711, рассмотренный в главе 3, но на практике, чаще всего, при скорости передачи инфор­мации 128 Кбит/с в конференциях используется алгоритм кодиро­вания G.728, а при скорости 384 Кбит/с - алгоритм G.722.

Видеокодеки сжимают видеоинформацию и выполняют обратное преобразование. Рекомендация Н.320 определяет видеокодек Н.261 как обязательный; может также использоваться кодек Н.263.

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

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

Сетевой интерфейс выполняет функции адаптации терминала, необходимые для его подключения к сети в соответствии с требова­ниями рекомендации I.400, рассмотренными в главе 3 [7].

Следующим элементом систем видеотелефонии Н.320 является устройство управления конференциями (MCU).

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

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

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

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

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

Кроме обработки речи и видеоинформации MCU может выпол­нять обработку данных в соответствии с рекомендацией Т. 120.

 

5.3        Мультимедийная связь в IP-сетях

 

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

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

Сети, построенные на базе протоколов Н.323, ориентированы на интеграцию с телефонными сетями и могут рассматриваться как сети ISDN, наложенные на сети передачи данных. В частности, процедура установления соединения в таких сетях IP-телефонии базируется на рекомендации ITU-T Q.931 и практически идентична той же процеду­ре в сетях ISDN.

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

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

На рис. 5.2 изображена архитектура сети, построенной на базе рекомендации Н.323.

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

 

5.4        Терминал Н.323

 

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

Рис. 5.3  Терминал Н.323

 

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

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

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

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

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

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

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

Аудиокодеки кодируют аудиоинформацию, поступающую от мик­рофона (или других источников аудиоинформации), для ее переда­чи по сети с маршрутизацией пакетов IP и декодируют сигналы, по­ступающие из сети, для последующего воспроизведения. Любое тер­минальное оборудование Н.323 должно иметь аудиокодеки. Обяза­тельным для реализации является кодек, выполняющий преобразо­вание речевой информации в соответствии с рекомендацией G.711. Реализация остальных алгоритмов кодирования, показанных на рис. 5.3, не обязательна. В том случае, когда в терминалах реализо­вано несколько алгоритмов кодирования речевой информации, же­лательно, чтобы терминалы могли работать в асимметричном режи­ме, например, принимать речь, закодированную по алгоритму G.711, и передавать речь, закодированную по алгоритму G.728.

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

 

5.5   Шлюз Н.323

 

Основной функцией шлюза является преобразование речевой (мультимедийной) информации, поступающей со стороны ТФОП с постоянной скоростью, в вид, пригодный для передачи по IP-се­тям, т.е. кодирование информации, подавление пауз в разговоре, упаковка информации в пакеты RTP/UDP/1P, а также обратное пре­образование.

Кроме того, шлюз должен уметь поддерживать обмен сигнальны­ми сообщениями как с коммутационным или терминальным обору­дованием ТфОП, так и с привратником или оконечным устройством сети Н.323. Таким образом, шлюз должен преобразовывать анало­говую абонентскую сигнализацию, сигнализацию по 2ВСК, сигналь­ные сообщения систем сигнализации DSS1 и ОКС7 [6,7] в сигналь­ные сообщения Н.323. Спецификации преобразования сигнализации Q.931 <DSS1, QSIG) и ОКС7 в сигнализацию Н.225.0, основанную на Q.931, приведены в рекомендации ITU-T H.246. Для поддержки до­полнительных услуг в шлюзе может быть обеспечена прозрачная пе­редача сигнальных сообщений Q.932 и Н.450.

Желательно, чтобы шлюз мог генерировать и распознавать сигна­лы DTMF на стороне ТфОП и передавать сигналы DTMF в сообщениях Н.245 userlnputlndication no сети с маршрутизацией пакетов IP.

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

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

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

В случае, когда терминал Н.323 связывается с другим термина­лом Н.323, расположенным в той же самой IP-сети, шлюз в этом со­единении не участвует.

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

 

5.6   Привратник

 

В привратнике сосредоточен весь интеллект сетей IР-телефонии, базирующихся на рекомендации ITU H.323. Сеть Н.323 имеет зон­ную архитектуру (рис. 5.6). Привратник выполняет функции управле­ния зоной сети IP-телефонии, в которую входят терминалы, шлюзы и устройства управления конференциями, зарегистрированные у этого привратника. Разные участки зоны сети Н .323 могут быть тер­риториально разнесены и соединяться друг с другом через маршру­тизаторы. Следует обратить внимание на то, что коммутаторы кад­ров Ethernet и маршрутизаторы пакетов IP не являются сетевыми эле­ментами Н.323, так как они работают на звеньевом или сетевом уров­нях соответственно, в то время как оборудование Н.323 работает на прикладном уровне стека протоколов TCP/IP.

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

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

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

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

•   маршрутизация сигнальных сообщений между терминалами, рас­положенными в одной зоне; привратник может организовывать сигнальный канал непосредственно между терминалами или ретранслировать сигнальные сообщения от одного терминала к другому. В последнем случае привратник в любое время знает состояние конечных пользователей и может предоставлять допол­нительные услуги, такие как переадресация, переключение свя­зи, установка вызова на ожидание, перехват вызова и т.д. Хотя, справедливости ради, надо отметить, что эти услуги могут быть реализованы (согласно рекомендациям ITU H.450.x) в термина­лах пользователей и предоставляться без участия привратника.

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

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

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

 

 5.7 Устройство управления конференциями

 

Рекомендация Н.323 предусматривает три вида конференций (рис. 5.7).

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

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

Рис. 5.7  Разные виды конференции в сети Н.323

 

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

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

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

Устройство управления конференциями MCU содержит один обя­зательный элемент- контроллер многоточечных соединений - Mul­tipoint controller (MC). Кроме того, MCU может содержать один или более процессоров для обработки информации пользователей при многоточечных соединениях - Multipoint processor (MP). Следует от­метить, что контроллер МС и процессор МР являются самостоятель­ными логическими устройствами Н.323 и что контроллер может су­ществовать независимо от процессора (обратное неверно). Контрол­лер может быть физически совмещен с привратником, со шлюзом или с MCU, a MCU, в свою очередь, может быть совмещено со шлю­зом или с привратником (рис. 5.8).

Контроллер конференций должен использоваться для организа­ции конференции любого вида. Он организует обмен между участ­никами конференции данными о функциональных возможностях (ca­pabilities) их терминалов, указывает, в каком режиме (с использованием каких кодеков) участники конференции могут передавать ин­формацию, причем этот режим может изменяться в ходе конферен­ции, например, при подключении к ней нового участника. Таким об­разом, контроллер МС определяет режим конференции (selected communication mode - SCM), который может быть общим для всех участников конференции или отдельным для каждого из них.

Рис. 5.8  Возможная реализация МС и МР в оборудовании Н.323

 

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

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

 

5.8   Реализация оборудования Н.323

 

В 2000 г. успешно прошел сертификацию комплекс оборудования IP-телефонии компании Lucent Technologies типа Packet-Star IP 1000. В состав этого комплекса входят шлюз, привратник и устройство управления сетью (Manager). Шлюз Packet-Star IP Gateway 1000 под­держивает до 3360 одновременных соединений и может, совместно с привратником, обслуживать до нескольких миллионов телефонных соединений и факсимильных сессий в день. Основные особенности оборудования состоят в том, что со стороны опорной АТС принима­ется множество потоков речевой информации со скоростью 2 048 Кбит/с (Е1), речь кодируется при помощи алгоритмов G.729a и G.723.1, поддерживаются все распространенные системы сигна­лизации, внутренняя шина системы функционирует на базе техноло­гии ATM со скоростью 5 Гбит/с, вносимая шлюзом задержка при ис­пользовании алгоритма кодирования речи G.729a составляет до 80 мс. Помимо поддержки второй версии протокола Н.323, обеспе­чена совместимость с оборудованием других фирм-производителей по профилю iNOW! В минимальной комплектации стоимость комплек­са составляет несколько сотен тысяч долларов. Близкий по функци­ям комплекс оборудования IP-телефонии, рассчитанный на поддерж­ку до 2000 одновременных разговорных соединений, разработала фирма Nokia. Масштабы и стоимость этой аппаратуры ориентиро­ванны на крупных операторов связи.

Lucent Technologies выпускает также платы IP-телефонии для учрежденческих АТС Definity. Они позволяют направлять телефонные вызовы по сети Интернет или Intranet с помощью функции маршру­тизации в IP-сетях – DEFINITY World Class Routing. Модуль IP-Trunk представляет собой встроенный шлюз IP-телефонии, принимающий речевой сигнал из ТфОП и преобразующий его в пакетную форму. Одна плата IP-Trunk может обработать 30 речевых каналов, то есть полный цифровой поток Е1. Отдельный системный вход в модуль IP-р Trunk позволяет администратору АТС устанавливать соответствие между номерами телефонной сети и IP-адресами, задавать правила маршрутизации и параметры обслуживания. Аналогичный по функ­циям модуль IP-card поддерживает подключение 24 IP-телефонов (серия 6600), работающих по протоколу Н.323.

Lucent Technologies выпускает также программный продукт Defin­ity Soft Phone, который работает совместно с широко распростра­ненным приложением Microsoft NetMeeting и позволяет, подсоеди­нившись к АТС Definity через Интернет как к серверу, стать ее внут­ренним абонентом. Качество связи при этом будет, разумеется, за­висеть от скорости передачи пакетов по сети Интернет. Кроме того, компания Lucent Technologies предлагает отдельное решение в об­ласти IP-УАТС под названием IP ExchangeComm, по структуре и ком­понентам сходное с решением CCN компании Cisco. Отдельно по­ставляется инструментарий разработчика программ (Software Devel­oper's Kit) для TAPI 2.1 -3.0, позволяющий создавать новые приложе­ния для IP-сети и добавлять новые функции к уже существующим продуктам. Компания Lucent начала выпуск и IP-телефонов - IP Ex­change. Аппаратное и программное обеспечение телефонов IP Ex­change совместимо с версией 2 стандарта Н.323 и поддерживает алгоритмы компрессии речи G.711, G.723 и G.729.

Интерес представляет решение компании Cisco - использовать сервера доступа и маршрутизаторы, например, Cisco 5300 и 3600, в которые добавлены речевые модули. Маршрутизаторы играют роль шлюзов, упаковывая речевую информацию в IP-пакеты. В этом направлении, кроме Cisco, активно работают фирмы Nortel и Ericsson (аппаратура IPTC). Фирмой OKI Network Technologies раз­работана аппаратура BS 1200 Internet Voice Gateway, предназначен­ная для установки непосредственно на АТС (УАТС). Помимо сокра­щения объема оборудования такое решение упрощает синхрони­зацию и сигнализацию. Программное обеспечение Cisco CallManager, работающее под операционной системой Windows NT, пред­назначено для управления соединениями между IP-телефонами Cisco и телефонными аппаратами ТфОП. Внешне IP-телефоны фир­мы Cisco выглядят как цифровые телефонные аппараты с жидкок­ристаллическим экраном и встроенным 2-х портовым Ethernet-кон­центратором, позволяющим не занимать для телефона отдельную розетку RJ-45. Поддерживается компрессия речи G.711 или G.723.1, в зависимости от выбора ПО CallManager. IP-адрес может присваи­ваться телефону статически или динамически, в последнем случае используется протокол DHCP.

Продукт IP-телефонии компании Ericsson состоит из следующих компонентов: шлюза, преобразующего формат речевой информа­ции и сигнализацию, Sitekeeper - системы управления, выполняю­щей все функции управления, такие как маршрутизация, сбор инфор­мации о вызовах и т.д. В систему входит база данных, которая хранит информацию о вызовах, а также биллинговую информацию и, при необходимости, информацию об абонентах сети (пароль, тип услу­ги, текущее состояние). Сервер управления выполняет функции гло­бального управления всей сетью IP-телефонии, хранит информацию о топологии и конфигурации этой сети, а также таблицы маршрути­зации. Следуя общим принципам технологии IP-телефонии, продукт Ericsson имеет, в то же время, некоторые особенности. Применено дополнительное технологическое решение - Phone Doubler, позво­ляющее создавать в Интернет вторую виртуальную телефонную ли­нию. Точнее, оператор получает возможность предоставить клиен­там новую услугу: работать в Интернет и разговаривать по телефону одновременно, занимая всего лишь одну аналоговую линию. Обыч­но для этого нужна либо вторая аналоговая линия, либо линия ISDN. В данном случае вызывающий абонент набирает номер вызываемо­го абонента, и если этот номер занят, то вызов переадресуется теле­фонной станцией к шлюзу. В свою очередь, шлюз передает запрос установления соединения вызываемому абоненту через IP-сеть. У этого абонента на экране появляется сообщение о входящем вы­зове. Далее устанавливается телефонное соединение. Кроме того, воспользовавшись продуктом Phone Doubler, пользователь Интернет может, например, произвести телефонный вызов, не прерывая сво­ей Интернет-сессии, используя клиентское ПО. Более подробное описание реализации данной услуги в рамках другой платформы -комплекса Протей-IP - приведено в главе 11.

Nortel Networks анонсировала целую серию новых продуктов IP-те­лефонии под общим названием Inca. Семейство Inca предоставляет потребителям портфель открытых решений на базе стандарта Н.323 для объединения сетей IP и телефонных сетей общего пользования. I2004 Internet Telephone - первый из этой серии Интернет-телефо­нов - совместим со стандартом Н.323 и использует алгоритмы сжа­тия речи G.711, G.723.1 и G.729A перед ее упаковкой в IP-пакеты. Еще в 1999 года корпорация Nortel Networks создала платы IP-телефонии для своей базовой модели АТС Meridian. Плата, называемая Meridian Integrated IP Telephony Gateway, способна обрабатывать и упаковы­вать в IP-пакеты 8 речевых каналов. Она устанавливается в перифе­рийный модуль АТС, поддерживающий интерфейс 10Base-T с кор­поративной сетью. Поддерживаются стандарты сжатия речи G.711 (64 Кбит/с), G.723 (до 5.3 Кбит/с) и G.729 (8 Кбит/с). Архитектура In­tegrated IP Telephony Gateway близка к рассмотренному в параграфе 11.8 модулю IPU, поэтому подробное рассмотрение этих решений отложим до главы 11.

IP-АТС RC3000 и IP-телефон LP 5100 IP, выпускаемые фирмой Sie­mens с начала 1999 года, относятся к сетевому оборудованию HiNet. Система рассчитана максимум на 50 абонентов. HiNet LP 5100 IP под­держивает стандарт Н.323, алгоритмы сжатия речи G.711 (64 Кбит/с) и G.723.1 (6.3 или 5.3 Кбит/с), а также функцию подавления эха.

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

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

 

 

Глава 6

Сигнализация Н.323

6.1    Семейство протоколов Н.323

 

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

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

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

6.2   Протокол RAS

 

Международный союз электросвязи в рекомендации Н.225.0 оп­ределил протокол взаимодействия рассмотренных в предыдущей главе компонентов сети Н.323: оконечного оборудования {термина­лов, шлюзов, устройств управления конференциями) с привратни­ком. Этот протокол получил название RAS (Registration, Ad mission 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 - Gate­keeper 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, вообще не должны от­вечать на запрос.

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

Кроме того, оконечное оборудование или привратник могут пе­редавать в поле destination Info запроса LRQ номер абонента ТфОП в формате Е.164 с целью определить местонахождение шлюза, по­средством которого может быть установлено соединение.

 

6.2.5 Изменение полосы пропускания

 

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

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

Оконечное оборудование, которому нужно превысить указанный предел, должно передать привратнику запрос Bandwidth Change Re­quest (BRQ), но до получения ответа средняя суммарная скорость должна быть не выше этого предела. Если привратник может выде­лить требуемую полосу пропускания, он отвечает сообщением Band­width 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. Наличие поля willRespondToIRR в сообщениях RCF или ACF, получаемых от привратни­ка, означает его согласие удовлетворить данное требование. При­вратник может подтверждать получение сообщения IRR сообщени­ем IACK или сообщать о потере или задержке сообщения IRR с по­мощью сообщения INAK. Оба сообщения 1АСКи 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, причем имеются два основных вари­анта ее использования.

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

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

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

 

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 Com­plete - с указанием причины 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.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.4   Управляющий канал Н.245

 

Ранее в книге уже упоминалось, что в рекомендации ITU-T H.245 определен ряд независимых процедур, которые должны выполнять­ся для управления информационными каналами. К ним относятся процедуры:

•   определения ведущего и ведомого устройств (Master/slave deter­mination);

•   обмена данными о функциональных возможностях (Capability Ex­change);

•   открытия и закрытия однонаправленных логических каналов (Logi­cal Channel Signalling);

•   открытия и закрытия двунаправленных логических каналов (Bidi­rectional Logical Channel Signalling);

•   закрытия логических каналов (Close Logical Channel Signalling);

•   определения задержки, возникающей при передаче информации от источника к приемнику и в обратном направлении (Round Trip Delay Determination);

•   выбора режима обработки информации (Mode Request);

•   сигнализации по петле, создаваемой для целей технического об­служивания оборудования (Maintenance Loop Signalling).

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

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

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

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

 

6.4.1   Определение ведущего и ведомого

 

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

Рис. 6.13   Первый вариант определения ведущего и ведомого оборудований

 

В ответ на полученные сообщения masterSlaveDetermination оба устройства передают сообщения masterSlaveDeterminationAck, в которыхуказывается, какое оборудование является для данного со­единения ведущим, а какое - ведомым. При этом любое оборудова­ние стандарта Н.323 должно быть способно работать и в качестве ведущего, и в качестве ведомого.

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

Существует вариант процедуры Master-Slave Determination, пре­дусматривающий сокращение числа передаваемых сообщений (рис.6.14).

В этом варианте оборудование, передавшее сообщение master-Slave Determination и получившее в ответ сообщение masterSlave-DeterminationAck, передает сообщение masterSlaveDetermina-tionAck.

 

6.4.2 Обмен данными о функциональных возможностях

 

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

Рис. 6.15  Обмен данными о функциональных возможностях оборудования

Терминалы обмениваются сообщениями

 

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

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

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

В сообщение TerminalCapabilitySet включается поле capabilityTable - таблица функциональных возможностей, где каждому ал­горитму кодирования/декодирования присвоен порядковый номер. Например, возможности приема речевой информации, закодирован­ной по алгоритму G.723.1, соответствует номер 1, возможности прие­ма речевой информации, закодированной по алгоритму G.728, - но­мер 2, возможности приема видеосигналов, закодированных по ал­горитму Н.263, - номер 3 и т. д.

Указанные порядковые номера объединяются в список альтерна­тивных режимов alternativeCapabilitySet. Оборудование может использовать любой (но только один) из режимов, указанных в списке. Например, список альтернативных режимов {G.711, G.723.1, G.728) означает, что оборудование может функционировать в любом из ука­занных режимов обработки речи, но только в одном.

В свою очередь, альтернативные режимы объединяются в набо­ры одновременно возможных режимов функционирования simultaneousCapabilities. Например, набор одновременно возможных ре­жимов, содержащий список альтернативных режимов обработки ви­деоинформации {Н.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).

Функциональные возможности терминала описываются набором дескрипторов (capabilityDescriptor), каждый из которых состоит из одного набора одновременно возможных режимов функционирова­ния оборудования и номера дескриптора (capability Descriptor Num­ber). Если при обмене данными о функциональных возможностях оборудование указывает более чем один дескриптор, то это означа­ет, что оборудование поддерживает несколько режимов функциони­рования. Например, наличие в сообщении TerminalCapabilitySet двух дескрипторов: первого - как и в предыдущем примере, т.е. {Н.261, Н.263} и {G.711, G.723.1, G.728}, а второго - {Н.262} и {G.711}, означает, что оборудование, кроме описанного выше режима, под­держивает обработку видеоинформации, закодированной по алго­ритму Н.262, совместно с обработкой речи, закодированной по ме­нее сложному, по сравнению с остальными, алгоритму кодирования G.711.

Заметим, что функциональные возможности оборудования, не определенные рекомендацией ITU H.245, могутбытьуказанывполе поп Standard Para mete г.

Оборудование может в любое время передать сообщение Termi­nalCapabilitySet с дескриптором, добавляющим новые функцио­нальные возможности, или с дескриптором, обеспечивающим исклю­чение некоторых из ранее указанных возможностей. Любое обору­дование стандарта Н.323 должно включать в сообщение TerminalCapabilitySet, по крайней мере, один дескриптор. Исключение со­ставляет сообщение EmptyCapabilitySet (пустой набор функцио­нальных возможностей), которое используется для реализации до­полнительных возможностей системы.

Оборудование, которое получило от другого оборудования сооб­щение TerminalCapabilitySet, может подтвердить его получение пе­редачей сообщения TerminalCapabilitySetAck.

При получении сообщения с некорректным набором возможно­стей оборудование отвечает сообщением TerminalCapabilitySetReject. При срабатывании таймера, запущенного после отправки со­общения 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. Получе­ние корректного сообщения openLogicalChannel оборудование должно подтвердить сообщением openLogicalChannelAck.

Если логический канал открывается для переноса речи или видео­информации, то принимающая сторона указывает в параметре mеdiaTransportChannel сообщения openLogicalChannelAck транс­портный адрес, на который передающая сторона должна передавать RTP пакеты, а в параметре mediaControlChannel, - транспортный адрес канала RTCP.

При открытии каналов для передачи данных, например для при­ложений Т. 120 параметр mediaControlChannel в сообщениях open­LogicalChannel и openLogicalChannelAck отсутствует.

Когда оборудование открывает однонаправленный логический канал, то, чтобы организовать дуплексную связь, встречное обору­дование также должно открыть однонаправленный канал в обратном направлении, используя для этого вышеописанную процедуру Uni­directional Logical Signalling.

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

Если приемная сторона способна работать только в симметрич­ном режиме, она может указать на это ограничение при выполнении процедуры Capabilities exchange.

Следует отметить, что прямой и обратный каналы не должны иметь один и тот же номер, так как номера логических каналов присваива­ются независимо для каждого направления передачи. Кроме того, для прямого и обратного логических каналов, относящихся к одной RTP-сессии и имеющих один и тот же идентификатор сессии (sessionID), открывается только один канал RTCP.

В некоторых случаях, например, для обмена данными по прото­колу Т. 120, оборудование, инициирующее такой обмен, должно от­крывать сразу и прямой, и обратный каналы. Делается это с помо­щью процедуры Bi-directional Logical Signalling, которая практически идентична вышеописанной процедуре Uni-directional Logical Signal­ling и также предусматривает обмен сообщениями openLogicalChannel и openLogicalChannelAck. Добавляется сообщение - openLogicalChannelConfirm, - которое передается в ответ на сообщение openLogicalChannelAck и подтверждает, что двунаправленный ло­гический канал открыт (см. сценарий на рис.6.17). Заметим, что если процедура Uni-directional Logical Signalling для организации дуплекс­ной связи должна выполняться два раза, то процедура Bi-directional Logical Signalling выполняется только один раз.

Закрытие логических каналов может производиться с помощью процедуры CloseLogicalChannel, но она используется, в основном, для поддержки предоставления дополнительных услуг, в первую оче­редь, - перевода в режим удержания. Для нормального разрушения соединения стороны обмениваются сообщениями endSessionCommand. После обмена этими сообщениями закрываются не только логические каналы, но и управляющий канал Н.245.

 

6.4.4 Выбор режима обработки информации

 

Оконечное оборудование в ходе процедуры Capabilities exchange может объявить поддерживаемые им режимы передачи информа­ции. Встречное оборудование, получив список возможных режимов передачи информации, может, передав сообщение requestMode, запросить передачу в одном из этих режимов. Устройство, получив­шее сообщение requestMode, должно, если это возможно, выпол­нить содержащееся в нем требование (рис.6.18). Оборудование, не желающее находиться под контролем другого оборудования в части выбора режима передачи информации, может просто не указывать, каким способом оно будет ее передавать.

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

В таблице 6.4 приведены сообщения Н.245, которые оборудова­ние стандарта Н.323 обязано принимать и передавать, а также не­обязательные и запрещенные сообщения Н.245. Приняв нераспозна­ваемое сообщение, оборудование Н.323 должно передать в ответ сообщение functionNotSupported. Следует отметить, что описание наиболее часто используемых сообщений было приведено в данном параграфе.

Таблица 6.4 Управляющие сообщения Н.245

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 Proceed­ing. Если оборудование имеет возможность принять вызов, оно пе­редает запрос допуска к ресурсам сети ARQ, на который привратник может ответить подтверждением ACF или отказом в допуске к ресур­сам сети ARJ. В первом случае вызываемое-оборудование передает сообщение Alerting, и привратник маршрутизирует его к вызываю­щему оборудованию. Вызываемому пользователю подается визуаль­ный или акустический сигнал о входящем вызове, а вызывающему дается индикация того, что вызываемый пользователь не занят и ему подается вызывной сигнал. При отказе в допуске к ресурсам сети вызываемое оборудование закрывает сигнальный канал путем пе­редачи привратнику сообщения Release Complete.

После того как вызываемый пользователь примет входящий вы­зов, привратнику передается сообщение Connect с транспортным адресом управляющего канала Н.245 вызываемого оборудования. Привратник заменяет этот адрес транспортным адресом своего управляющего канала Н.245 и пересылает Connect вызывающему оборудованию, после чего открывается управляющий канал Н.245.

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

После открытия управляющего канала Н.245 начинается обмен дан­ными о функциональных возможностях оборудования. В рассматри­ваемом нами случае все управляющие сообщения, передаваемые от одного оконечного оборудования к другому, маршрутизируются при­вратником. Терминалы обмениваются сообщениями TerminalCapa-bilitySet, в которых указываются возможные алгоритмы декодирова­ния принимаемой информации. Следует отметить, что сообщение Terminal Capability Set должно быть первым сообщением, передавае­мым по управляющему каналу. Оборудование, принявшее сообщение TerminalCapabilitySet от другого оборудования, подтверждает его получение передачей сообщения TerminalCapabilitySetAck.

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

 

В ответ на полученные сообщения masterSlaveDetermination оба устройства передают сообщения masterSlaveDeterminationAck, в которых указывается, какое из этих устройств является для данно­го соединения ведущим, а какое - ведомым.

Напомним, что возможен сценарий процедуры Master-Slave De­termination, предусматривающий сокращение'количества передавае­мых сообщений: оборудование, передавшее сообщение master­SlaveDetermination и получившее в ответ сообщение masterSlave­DeterminationAck, передает сообщение masterSlaveDetermina­tionAck.

После обмена данными о функциональных возможностях и опре­деления ведущего и ведомого оборудования может выполняться процедура открытия однонаправленных логических каналов. В тре­бовании открыть логический канал (в нашем случае - прямой логи­ческий канал) open LogicalChannel оборудование указывает вид ин­формации, который будет передаваться по этому каналу, и алгоритм кодирования. В нашем случае логический канал предназначается для переноса речи, поэтому в сообщение 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, на который привратник должен ответить подтверждением DCR после чего об­служивание вызова считается завершенным.

 

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 Com­plete, и сигнальный канал закрывается.

Пользователь, получивший команду 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 и же­лающее использовать инкапсуляцию управляющих сообщений, так­же должно присвоить значение TRU Е элементу h245Tunnelling в сообщении, передаваемом в ответ на сообщение Setup, и в последую­щих сообщениях Q.931.

Вызываемое оборудование, не поддерживающее туннелирование управляющих сообщений, присваивает элементу h245Tunnelling, передаваемому в ответе на сообщение Setup, значение FALSE. В этом случае для передачи управляющих сообщений открывается отдель­ный канал Н.245.

 

6.5.4  Процедура быстрого установления соединения

 

Самый быстрый способ установления соединения в сети, бази­рующейся на рекомендации Н.323, - это использование процедуры Fast Connect. Чтобы инициировать процедуру Fast Connect, вызываю­щее оборудование передает сообщение Setup с элементом f astStart. Этот элемент может включать в себя одну или несколько структур OpenLogicalChannel. Одна из структур OpenLogicalChannel обяза­тельно должна содержать элемент forward Logical Channel Pa ra me­ters и может содержать элемент reverse Log icalChannel Parameters, но, в то же время, структура OpenLogicalChannel описывает точно один однонаправленный логический канал. Это означает, что когда описывается прямой логический канал, то в структуре присутствует только элементforwardLogicalChannelParameters. Элемент содержит информацию об алгоритме, который используется вызывающим оборудованием для кодирования передаваемой информации, и ад­рес канала RTCR При описании канала обратного направления в эле­менте forwardLogicalChannelParameters не содержится никакой информации, хотя сам он обязательно присутствует, а в элементе reverse LogicalChannel Parameters содержатся сведения об алго­ритме декодирования принимаемой информации, транспортный адрес RTR на который следует передавать информацию, и адрес ка­нала RTCR

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

Вызываемое оборудование может отклонить процедуру Fast Con­nect, либо если оно ее не поддерживает, либо если существует по­требность в использовании процедур Н.245 с открытием отдельного канала Н.245 или с туннелированием управляющих сообщений. В этом случае элемент fastStart не включается ни в одно из сообще­ний, передаваемых после приема Setup, до сообщения Connect вклю­чительно. Открытие логических каналов для передачи речевой ин­формации производится с использованием процедур Н.245.

Вызываемое оборудование, получившее сообщение Setup с эле­ментом fastStart и могущее поддержать процедуру Fast Connect, должно включить элемент fastStart в любое из сообщений Q.931, передаваемых после приема Setup, до сообщения Connect включи­тельно. Элемент fastStart содержит структуры OpenLogicalChannel, которые выбраны вызываемым оборудованием из структур, предложенных вызывающим оборудованием. И снова одна из струк­тур OpenLogicalChannel содержит элемент forwardLogicalChannel-Раrаmeters со сведениями об алгоритме кодирования информации, с транспортными адресами каналов RTP и RTCP вызываемого обо­рудования. Вторая структура OpenLogicalChannel включает в себя элемент forwardLogicaiChannelParameters, не содержащий ника­кой информации, и элемент reverseLogicaIChannel Parameters со сведениями об алгоритме кодирования информации и с транспорт­ным адресом канала RTCP вызываемого оборудования.

Вызываемое оборудование может начинать передачу информа­ции сразу вслед за любым сообщением Q.931 с элементом fastStart. Это означает, что вызывающее оборудование должно быть готовым к приему информации, закодированной любым из указанных в сооб­щении Setup способов. Сообщение Q.931 с элементом fastStart, переданное вызываемым оборудованием после получения сообще­ния Setup, может прийти после начала передачи пользовательской информации. Если вызывающее оборудование не желает принимать речевую информацию до прихода сообщения Connect, оно присваи­вает значение TRUE элементу mediaWaitForConnect, передаваемо­му в сообщении Setup.

Вызывающее оборудование, инициировавшее процедуру Fast Connect, может начать передачу речевой информации сразу после приема любого из разрешенных сообщений Q.931, содержащего элемент fastStart.

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

Следует отметить, что при использовании процедуры Fast Con­nect или при туннелировании управляющих сообщений как одна, так и другая сторона может открыть управляющий канал Н.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 секунд после приема сообщения Set­up он не передал сообщения Alerting, Connect или Release Complete. Чтобы указать, что вызов выходит за пределы IP-сети, в сообщения Alerting, Call Proceeding, Progress и Connect должен включаться ин­формационный элемент Progress Indicator.

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