Лекция 14

Вид материала

Подобный материал:

Лекция 14.

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

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

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

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

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

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

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

Internet Protocol (IP) не гарантирует надежную доставку пакетов. Пакеты могут искажаться, задерживаться, передаваться по различным маршрутам (а значит иметь различное время передачи) и т. д.

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

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

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

Искажения потока пакетов связаны с загруженностью сети. При отсутствии перегрузок искажения минимальны, а часто отсутствуют.

Поток речевых пакетов может значительно загружать сеть, особенно, в случае многоканальных систем. Это происходит из-за высокой интенсивности потока (речевые пакеты в 20 байт передаются через промежутки времени в 30 мс) и большого объема передаваемой служебной информации (Общий объем заголовка речевого пакета - 40 байт (IP - 20 байт, UDP - 8 байт, RTP - 12 байт) в 2 раза превышает размер самого пакета – 20 байт.). Передача такого объема служебной информации неприемлема, особенно, при построении многоканальных систем. Таким образом, необходимо искать способы уменьшения количества служебной информации, передаваемой по сети. Существует два возможных варианта решения этой проблемы.

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

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

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

Основой построения первых глобальных систем IP-телефонии стала рекомендация ITU-T H.323.

H.323 скорее дает общее представление об архитектуре систем IP-телефонии, нежели описывает некий конкретный протокол. Основу архитектуры представляет VoIP шлюз (Gateway) соединяющий Интернет с телефонной сетью. Он поддерживает протокол H.323 со стороны Интернета и протоколы коммутируемой телефонной сети общего пользования с “телефонной” стороны. Зона Н.323 может включать ПК-терминалы (Т), шлюзы (GW), устройства многоточечного управления (MCU) и машину-привратник – гейткипер (GK). Машина-привратник (Gatekeeper), согласно H.323, обеспечивает перевод адреса и регулирует доступ к локальной сети для конечных узлов, находящихся в её зоне. В зоне может находиться только один гейткипер. Зона может содержать один или несколько сегментов LAN, связанных маршрутизаторами или другими устройствами.

Речь	Управление
G.7xx	RTCP	H.225 (RAS)	Q.931 (Сигналы при вызове)	H.245 (Управление вызовами)
RTP
UDP		TCP
Протокол уровня передачи данных
Протокол физического уровня

Стек протоколов H.323

Работу телефонной сети обеспечивает множество протоколов. Во-первых, необходим протокол кодирования и декодирования речи. С помощью системы PCM (ИКМ) (рекомендация ITU G.711) один голосовой канал кодируется 8-ми битными отсчетами с частотой 8000 раз в секунду. В результате получается 64-килобитный несжатый поток речевых данных. Все системы H.323 обязаны поддерживать G.711. Тем не менее, разрешена (но не является обязательной) поддержка и других протоколов кодирования речи. Они используют иные алгоритмы сжатия и приводят к несколько отличающемуся компромиссу между качеством и использованием пропускной способности. Например, в G.723.1 берутся блоки по 240 отсчетов (30 мс речи) и используется кодирование с предсказанием, снижающее размер блока до 24 или 20 байт. На выходе этого алгоритма получается поток со скоростью 6,4 или 5,3 Кбит/c (сжатие в 10 или 12 раз соответственно). Разумеется, качество звучание при этом гораздо ниже. Могут быть реализованы и другие алгоритмы кодирования.

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

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

Терминалам нужен протокол для ведения переговоров с машиной-привратником (если такая присутствует в локальной сети). Для этого в системе работает протокол H.225. Канал между ПК и привратником, которым этот протокол управляет, называется каналом RAS (Registration/Admission/Status – Регистрация/Доступ/Статус). Он позволяет терминалам, кроме всего прочего, входить в зону и покидать её, запрашивать и освобождать пропускную способность, обновлять данные о состоянии.

Наконец, нужен протокол для непосредственной передачи данных. Для этого используется протокол реального времени Real Time Protocol (RTP). В заголовке данного протокола передаются, в частности, временная метка и номер пакета. Эти параметры позволяют определить не только порядок пакетов в потоке, но и момент декодирования каждого пакета, т. е. позволяют восстановить поток.

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

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

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

Теперь, когда терминалу уже выделена пропускная способность, он может послать по TCP-соединению сообщение SETUP (стандарт Q.931). В нем указывается номер вызываемого абонента (или IP-адрес и порт, если вызывается удаленный компьютер). Привратник отвечает Q.931-сообщением CALL PROCEDING, подтверждая тем самым факт корректного приема запроса. Затем привратник пересылает сообщение SETUP на шлюз.

Схема взаимодействия компонентов системы IP-телефонии по рекомендации H.323 для установления соединения между терминалом локальной сети и телефонным аппаратом КТСОП.

Шлюз, который является с одной стороны компьютером, а с другой – телефонным коммутатором, осуществляет обычный звонок на обычный телефон. Оконечная телефонная станция вызываемого абонента выполняет свою обычную работу (у абонента звенит звонок), а кроме этого отсылает обратно Q.931-сообщение ALERT, извещая ПК о том, что началась серия звонков. Когда абонент поднимает трубку, оконечная телефонная станция отправляет сообщение CONNECT, сообщая компьютеру о том, что соединение установлено.

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

Для переговоров о предпочитаемых параметрах соединения используется протокол H.245. При этом используется специальный управляющий канал H.245, который всегда открыт. Каждая из сторон начинает с объявления своих возможностей. Например, может сообщаться о поддержке видео (H.323 может поддерживать видео), конференц-связи, используемых кодеках и т.п. После того как каждая из сторон узнает возможности противоположной стороны, организуется два однонаправленных канала, с которыми связываются определенные кодеки и которым присваиваются определенные параметры. Поскольку на каждой из сторон может быть установлено разное оборудование, вполне возможна ситуация, когда каждый из однонаправленных каналов использует свой кодек. По достижении договоренности по всем вопросам можно начинать передачу данных (по протоколу RTP). Управление производится RTCP, контролирующим перегрузку. Если передаются видеоданные, RTCP занимается синхронизацией звукового и видеоряда.

Во время разговора между звонящим и вызываемым абонентами в IP-телефонии сохраняются следующие логические каналы:

После того, как на одной из сторон вешают трубку, по каналу Q.931 передается сигнал окончания связи.

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

Сложность реализации иерархической многопротокольной структуры H.323 побудила некоторых производителей поддерживать и развивать одновременно с Н.323 альтернативные протоколы взаимодействия IP-шлюзов. Это, к примеру, Nuera, Komode, Mediatrix и Ericsson с протоколом SIP (Session Initial Protocol), CISCO Systems с протоколами MGCP (Media Gateway Control Protocol) и SGCP (Simple Gateway Control Protocol), а так же некоторые другие. Несмотря на определённые преимущества альтернативных протоколов, набор рекомендаций Н.323 продолжает оставаться стандартом де-факто, потому претерпевает модернизации и дополнения, выражающиеся в различных версиях и фазах разработки.

Основные фазы межшлюзового взаимодействия под управлением гейткипера Н.323 для телефонного вызова, поступившего из телефонной сети на вход шлюза "А", с вызовом, направленным на абонента, подключенного к шлюзу "Б:

Стандарт H.323 был разработан ITU. В Интернет-сообществе многим он показался типичным продуктом телефонной компании: громоздким, сложным и недостаточно гибким. Было решено организовать специальный комитет IETF для создания более простой и гибкой системы передачи речи поверх IP. Основным результатом деятельности этого комитета стал протокол SIP (Session Initiation Protocol – протокол запуска соединения), описанный в RFC 3261. Протокол оговаривает способ установки телефонных соединений через Интернет, технологию организации систем для видеоконференций и способы создания других мультимедийных приложений. В отличие от H.323, представляющего собой целый набор протоколов, SIP – это единый модуль, способный взаимодействовать с разнообразными Интернет-приложениями. Например, номера телефонов определяются в виде URL, то есть на веб-страницах можно размещать гиперссылки, щелкнув на которых, пользователь сможет установить телефонное соединение (примерно так же схема mailto позволяет написать электронное письмо и отправить его по указанному в ссылке адресу).

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

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

Телефонные номера в SIP представляются в виде URL со схемой sip. Например, sip:dmitry@iu5.bmstu.ru свяжет вас с пользователем по имени dmitry, хост которого определяется DNS-именем iu5.bmstu.ru. SIP URL могут содержать так же адреса формата IPv4, IPv6 или реальные адреса телефонов.

Протокол SIP является текстовым, он построен по модели HTTP. Одна из сторон посылает ASCII-сообщение, в котором первая строка содержит имя метода, а ниже следуют дополнительные строки, содержащие заголовки для передачи параметров. Многие заголовки взяты из стандарта MIME, что позволяет SIP взаимодействовать с существующими Интернет-приложениями. Шесть методов, определяемых базовой спецификацией, перечислены в табл.1.

Метод	Описание
INVITE	Запрос запуска сеанса связи
ACK	Подтверждение запуска сеанса
BYE	Запрос окончания сеанса
OPTIONS	Опрос возможностей хоста
CANCEL	Отмена запроса
REGISTER	Информирование сервера переадресации текущем местоположении пользователя

Для установки сеанса связи звонящий должен либо создать TCP-соединение с вызываемым абонентом и послать по нему сообщение INVITE, либо послать это же сообщение в UDP-пакете. В обоих случаях заголовки, содержащиеся во второй и всех последующих строках, описывают структуру тела сообщения, содержащего информацию о возможностях звонящего, типах мультимедиа и форматах. Если вызываемый абонент принимает звонок, он посылает в качестве ответа трехразрядный код результата типа HTTP. Следом за строкой с кодом результата вызываемый абонент может также сообщить данные о своих возможностях, типах мультимедиа и форматах.

Звонящий высылает ACK как для окончания работы протокола, так и для подтверждения приема кода 200.

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

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

Метод REGISTER относится к возможности протокола SIP разыскивать пользователя и соединяться с ним, даже если его нет дома. Сообщение, содержащие данный метод, отправляется на поисковый сервер SIP, хранящий данные о том, кто где находится в данный момент. Впоследствии с помощью этого сервера можно попробовать найти абонента. Операция переадресации, используемая при этом, показана на рис.4. На этом рисунке мы видим, что звонящий отправляет сообщение INVITE на прокси-сервер. Это делает возможную переадресацию незаметной. Прокси пытается разыскать абонента и посылает INVITE по найденному адресу. Дальнейшее общение представляет собой коммутацию последовательности сообщений при тройном рукопожатии. Сообщение LOOKUP и REPLY не входят в протокол SIP; на этой стадии может использоваться любой подходящий протокол в зависимости от типа поискового сервера.

Использование прокси и серверов переадресации в протоколе SIP

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

Сравнение H.323 и SIP

Аспект	H.323	SIP
Разработчик	ITU	IETF
Совместимость с телефонной системой	Полная	В большей мере
Совместимость с Интернетом	Отсутствует	Присутствует
Архитектура	Монолитная	Модульная
Завершенность	Полный стек протоколов	SIP обеспечивает лишь установку соединения
Переговоры относительно параметров	Ведутся обеими сторонами	Ведутся обеими сторонами
Сигналы при вызове	Q.931 поверх TCP	SIP поверх TCP или UDP
Формат сообщений	Двоичный	ASCII
Передача мультимедийных данных	RTP/RTCP	RTP/RTCP
Многосторонняя связь	Есть	Есть
Мультимедийные конференции	Возможны	Невозможны
Адресация	Номер телефона или хоста	URL
Разрыв связи	Явный или разрыв TCP-соединения	Явный или по тайм-ауту
Постоянный обмен сообщениями	Нет	Есть
Шифрование данных	Есть	Есть
Объем описания стандарта	1400 страниц	250 страниц
Реализация	Громоздкая и сложная	Умеренная по объему
Статус	Широко распространен	Перспективен

Blog

Лекция 14