Стандарты и аппаратные средства IP-телефонии
Многоточечная аудиоконференц-связь
Сосуществование различных типов трафика
В настоящее время все более широкое распространение приобретает передача мультимедийного трафика — речи, видеоизображений, графики — по компьютерным сетям передачи данных с помощью дополнительных аппаратных и программных средств. Другой важнейшей тенденцией в эволюции современных телекоммуникаций является все более активное взаимодействие сети Internet и телефонных сетей общего пользования (ТфОП), позволяющее организовать телефонную связь между абонентами ТфОП и Internet, а также между абонентами ТфОП через Internet. Подобный вид связи называют Internet-телефонией. Более широкое понятие — IP-телефония — подразумевает множество новых технологий, обеспечивающих передачу мультимедийных сообщений (речи, данных, видео) через информационно-вычислительные сети (ИВС), построенные на базе протокола IP (локальные, корпоративные и глобальные вычислительные сети, в том числе сеть Internet).
В IP-телефонии используются открытые стандарты Сектора стандартизации электросвязи Международного союза электросвязи (МСЭ-Т) и оперативной инженерной группы Internet IETF (Internet Engineering Task Force). При этом обеспечивается гибкая (по отношению как к физической среде передачи, так и к местоположению) передача мультимедийного трафика через любую сеть, построенную на базе протокола IP. В результате те же самые ИВС, которые поддерживают Web, электронную почту и передачу данных, могут использоваться для телефонной связи с частными лицами, организациями и учреждениями во всем мире.
IP-телефония представляет интерес прежде всего для конечных пользователей: они получают услуги телефонной связи при довольно низкой поминутной оплате. Почему IP-телефония дешевле традиционной? У этого факта есть объективная причина. В обычной телефонии используется метод коммутации каналов, при котором канал связи выделяется и монопольно используется абонентом в течение всего сеанса связи, независимо от того, передается им в данный момент времени информация или нет. Телефонный разговор — это, как правило, диалог, и, когда говорит один человек, другой обычно молчит, и наоборот. Также бывают моменты времени, когда молчат оба собеседника. Кроме того, в речи человека имеются паузы и краткие перерывы. Таким образом, только на протяжении 1/3 продолжительности сеанса связи коммутируемый телефонный канал занят передачей информации. В случае коммутации пакетов, положенной в основу протокола IP, пакеты от множества различных абонентов одновременно передаются по одной и той же линии связи, обеспечивая более эффективное ее использование. Кроме того, человеческая речь несет огромный объем избыточной информации, что позволяет сжимать записи речи в цифровом виде в десять и более раз, обусловливая дополнительное снижение расходов при ее передаче.
Другое достоинство IP-телефонии особенно важно для корпоративных пользователей. Компаниям, имеющим удаленные филиалы, IP-технология дает возможность обеспечения голосовой связи при помощи уже существующих корпоративных IP-сетей. Вместо нескольких сетей связи может использоваться одна. По одним и тем же линиям связи передаются речь, видеосигналы и данные за счет использования единого протокола передачи IP для любого типа трафика (рис. 1). В результате увеличивается управляемость системы связи, снижаются расценки на услуги, появляется новый набор инструментальных средств и увеличивается продуктивность.
Безусловным преимуществом IP-телефонии перед обычным телефоном является возможность предоставления дополнительных услуг за счет тесной интеграции с мультимедийным компьютером и Internet-приложениями. Например, с помощью IP-телефонии можно осуществлять звонки с Web-браузера на телефон: просматривая какой-нибудь корпоративный Web-узел, пользователь щелкает мышью на кнопке Call и получает возможность задать дополнительные вопросы, уточнить что-либо. Снижая издержки существующих услуг связи, таких как передача речи и видеоизображений, организации и частные лица в то же самое время благодаря IP-телефонии расширяют свои коммутационные возможности, включая в них современную видеоконференц-связь, совместное использование приложений, средств типа электронной чертежной доски (whiteboard) и т.п.
Возможные приложения для IP-телефонии включают телекоммутацию, совместную работу с документами в реальном масштабе времени, дистанционное обучение, видеоконференц-связь, видеопочту, видео по запросам и т.д.
Стандарты
Какие международные стандарты и протоколы регламентируют основные параметры и алгоритмы функционирования аппаратных и программных средств связи, используемых в IP-телефонии? Очевидно (как следует из названия), что данная технология построена на базе протокола IP (Internet Protocol), в том числе с использованием его расширения IP Multicast, которое обеспечивает эффективную связь одновременно для группы пользователей.
 |
|
Протоколы RTP/RTCP
В сетях, не обеспечивающих гарантированное качество обслуживания (к которым относятся сети, построенные на основе протокола IP), пакеты могут теряться; может изменяться порядок их поступления; данные, передаваемые в пакетах, могут искажаться. Для обеспечения надежной доставки передаваемой информации в этих условиях используются различные процедуры транспортного уровня. При передаче цифровых данных для этой цели применяется протокол ТСР (Transmission Control Protocol). Данный протокол обеспечивает надежную доставку данных, восстанавливает исходный порядок следования пакетов. Если в пакете обнаруживается ошибка или пакет теряется, процедуры TCP посылают запрос на повторную передачу.
Для приложений аудио- и видеосвязи задержки пакетов в гораздо большей степени влияют на качество сигнала, чем отдельные искажения данных. Различия в задержках могут приводить к появлению пауз. Для таких приложений необходим другой протокол транспортного уровня, обеспечивающий восстановление исходной последовательности пакетов, их доставку с минимальной задержкой, воспроизведение в реальном масштабе времени в точно заданные моменты, распознавание типа трафика, групповую или двустороннюю связь. Таким протоколом является транспортный протокол реального времени RTP (Real-Time Transport Protocol). Данный протокол регламентирует передачу пакетов мультимедийных данных через ИВС на транспортном уровне и дополняется протоколом управления передачей данных в реальном масштабе времени RTCP (Real-Time Control Protocol). Протокол RTCP, в свою очередь, обеспечивает контроль доставки мультимедийных данных и качества обслуживания, передачу информации об участниках текущего сеанса связи, управление и идентификацию.
Транспортный протокол реального времени RTP обеспечивает услуги сквозной передачи в реальном времени мультимедийных данных, таких как интерактивное аудио и видео. Эти услуги включают распознавание типа трафика, нумерацию последовательности пакетов, работу с метками времени и контроль передачи. Действие протокола RTP сводится к присваиванию каждому исходящему пакету временных меток. На приемной стороне временные метки пакетов указывают на то, в какой последовательности и с какими задержками их необходимо воспроизводить. Порядковые номера, включенные в RTP, позволяют получателю восстанавливать последовательность пакетов отправителя. В целом поддержка RTP и RTCP позволяет принимающему узлу располагать поступающие пакеты в надлежащем порядке, снижать влияние неравномерности в задержках пакетов в сети и восстанавливать синхронизацию между аудио и видео, чтобы поступающая информация могла правильно прослушиваться и просматриваться пользователями.
Протокол RTP поддерживает как двустороннюю связь, так и передачу данных группе адресатов, если многоточечное распределение поддерживается нижележащей сетью. Данный протокол предназначен для обеспечения информации, требуемой отдельным приложениям, и в большинстве случаев интегрируется в работу приложения.
Хотя RTP считается протоколом транспортного уровня, он функционирует обычно поверх другого протокола транспортного уровня UDP (User Datagram Protocol). Оба протокола формируют функциональность транспортного уровня. Следует отметить, что RTP и RTCP не зависят от транспортного и нижележащего сетевого уровней и поэтому могут использоваться с другими подходящими транспортными протоколами.
Для того чтобы протокол RTP был более гибким и применимым для различных приложений, некоторые его параметры сделаны преднамеренно неопределенными, но зато в нем предусмотрено понятие профиля. Профиль (profile) — это набор параметров протоколов RTP и RTCP для конкретного класса приложений, определяющий особенности их функционирования. В профиле задается использование отдельных полей заголовков пакетов, типы трафика, дополнения к заголовкам и расширения заголовков, типы пакетов, услуги и алгоритмы обеспечения безопасности связи, особенности использования протокола нижележащего уровня и т.д. Каждое приложение обычно работает только с одним профилем, и задание типа профиля происходит путем выбора соответствующего приложения. Никакой явной индикации типа профиля номером порта, идентификатором протокола и т.п. не предусмотрено.
|
|
Многоточечная аудиоконференц-связь
Для организации многоточечной аудиоконференц-связи требуется многопользовательский групповой адрес и два порта. При этом один порт необходим для обмена звуковыми данными, а другой используется для пакетов управления протокола RTCP. Информация о групповом адресе и портах сообщается предполагаемым участникам телеконференции. Если требуется конфиденциальность, то информационные и управляющие пакеты могут быть зашифрованы, в этом случае также должен быть сгенерирован и передан ключ шифрования.
Приложение аудиоконференц-связи, используемое каждым участником конференции, посылает звуковые данные малыми порциями, например продолжительностью 20 мс. Каждой порции звуковых данных предшествует заголовок RTP; заголовок RTP и данные поочередно инкапсулируются в пакет UDP. В заголовке RTP содержится, в частности, информация о типе кодирования звука. Это дает возможность изменять тип кодирования в течение конференции, например при введении нового участника, который соединен через линию связи с низкой полосой пропускания, или при перегрузках сети.
В сети Internet, как и в других сетях передачи данных с коммутацией пакетов, пакеты иногда теряются и переупорядочиваются, а также задерживаются на различное время. Для противодействия подобным явлениям заголовок RTP содержит временную метку и порядковый номер, которые позволяют получателям восстановить синхронизацию в исходном виде, так чтобы, например, участки звукового сигнала воспроизводились динамиком непрерывно каждые 20 мс. Эта реконструкция синхронизации выполняется отдельно и независимо для каждого источника пакетов RTP в телеконференции. Порядковый номер может также использоваться получателем для оценки количества потерянных пакетов.
Поскольку участники телеконференции могут вступать и выходить из нее во время ее проведения, полезно знать, кто участвует в ней в данный момент и насколько хорошо он получает звуковые данные. Для этой цели каждый экземпляр звукового приложения во время конференции периодически выдает на порт управления (порт RTCP) для приложений всех остальных участников сообщения о приеме пакетов с указанием имени своего пользователя. Сообщение о приеме указывает, насколько хорошо слышим текущий оратор, и может использоваться для управления адаптивными кодерами. В дополнение к имени пользователя может быть включена также другая информация идентификации для контроля полосы пропускания.
|
|
Видеоконференц-связь
Если в телеконференции используются и звуковые и видеосигналы, то они передаются раздельно. Для передачи каждого типа трафика независимо от другого спецификацией протокола вводится понятие сеанса связи RTP. Сеанс определяется конкретной парой транспортных адресов назначения (один сетевой адрес плюс пара портов для RTP и RTCP). Пакеты для каждого типа трафика передаются с использованием двух различных пар портов UDP и/или групповых адресов. Никакого непосредственного соединения на уровне RTP между аудио- и видеосеансами связи нет, за исключением того, что пользователь, участвующий в обоих сеансах, должен использовать то же самое каноническое имя в RTCP-пакетах для обоих сеансов так, чтобы сеансы могли быть связаны.
Одна из причин такого разделения заключается в том, чтобы позволить некоторым участникам конференции получать только один тип трафика. Несмотря на разделение, синхронное воспроизведение мультимедийных данных источника (звука и видео) может быть достигнуто при использовании информации таймирования, которая переносится в пакетах RTCP для обоих сеансов.
|
|
Микшеры и трансляторы
Не всегда все участники телеконференции имеют возможность получать мультимедийные данные в одинаковом формате. Например, пользователи из одной местности могут быть соединены через низкоскоростную линию связи с другими участниками конференции, которые обладают широкополосным доступом к сети. Вместо того, чтобы вынуждать каждого участника использовать более узкую полосу пропускания и звуковое кодирование с пониженным качеством, на границе области с узкой полосой пропускания может быть размещено средство связи уровня RTP, называемое микшером. Этот микшер повторно синхронизирует входящие звуковые пакеты для восстановления исходных 20-миллисекундных интервалов, микширует восстановленные звуковые потоки в один поток, проводит кодирование звукового сигнала для узкой полосы пропускания и передает поток пакетов через низкоскоростную линию связи. При этом пакеты могут быть адресованы одному получателю или группе получателей с различными адресами. Чтобы в приемных оконечных точках можно было обеспечить правильную индикацию источника сообщений, заголовок RTP включает для микшеров средства опознавания источников, участвовавших в формировании смешанного пакета.
Некоторые из участников аудиоконференции могут быть соединены широкополосными линиями связи, но могут быть недоступны с помощью групповой конференц-связи с использованием протокола IP (IPM — IP multicast). Например, они могут находиться за брандмауэром прикладного уровня, который не будет пропускать IP-пакеты. Для таких случаев нужны не микшеры, а средства связи уровня RTP другого типа, называемые трансляторами. Из двух трансляторов один устанавливается вне брандмауэра и снаружи передает все групповые пакеты, полученные через безопасное соединение, другому транслятору, установленному за брандмауэром. Транслятор за брандмауэром передает их снова, как мультивещательные пакеты, многопользовательской группе, ограниченной внутренней сетью сайта.
Микшеры и трансляторы разрабатываются для различных целей. Например, микшер видеосигнала может масштабировать видеоизображения людей в независимых потоках видеосигнала и объединять их в один поток, моделируя групповую сцену. Примеры трансляции: соединение группы хостов, использующих исключительно протоколы IP/UDP с группой хостов, которые воспринимают только ST-II, или перекодирование видеосигнала, пакет за пакетом, из индивидуальных источников без пересинхронизации или микширования.
|
|
Н.323
Во многих публикациях, посвященных IP-телефонии, отмечается, что большинство сетевого оборудования и специального программного обеспечения для данной технологии разрабатывается на базе Рекомендации Н.323 (в том числе TAPI 3.0, NetMeeting 2.0 и т.д.). Как соотносится Н.323 с протоколами RTP и RTCP? Н.323 — это широкий концептуальный каркас, включающий множество других стандартов, каждый из которых отвечает за различные аспекты передачи информации. Большинство из этих стандартов, например стандарты аудио- и видеокодеков, имеют широкое применение вне IP-телефонии. Что касается протоколов RTP/RTCP, то они, являясь базовыми для стандарта H.323, ориентированы на обеспечение именно IP-технологии и составляют основу IP-телефонии.
Рекомендация Н.323 — это стандарт МСЭ-Т для передачи мультимедийного трафика (речи, видеоизображений и данных) через сети передачи данных с коммутацией пакетов без установления логического соединения, которые не обеспечивают гарантированного качества обслуживания (такие как сети на базе протокола IP и сеть Internet). Данный стандарт обеспечивает управление вызовом, мультимедийным трафиком и полосой пропускания для двусторонних и многоточечных телеконференций. H.323 обеспечивает поддержку стандартных аудио- и видеокодеков и передачу данных согласно Рекомендации T.120. Стандарт H.323 является независимым от сети, платформы и приложения, позволяя взаимодействовать друг с другом любым согласующимся с H.323 терминалам.
До появления этого стандарта сети, обеспечивающие проведение телеконференций, как правило, строились на базе Рекомендации Н.320. Хотя стандарт Н.320 во многом способствовал распространению конференц-связи, поскольку обеспечивал стыкуемость продуктов различных производителей, он налагал и некоторые ограничения. Это связано с тем, что большинство систем, совместимых с Н.320, работает только на линиях ISDN BRI, давая возможность проводить телеконференции со скоростями передачи 64 или 128 Кбит/с. Поэтому компаниям приходилось дополнять существующую у них сетевую инфраструктуру линиями ISDN. Являясь широким стандартом, Н.323 позволяет возлагать исполнение приложений телеконференций на существующие сетевые соединения. Одним из преимуществ этого является возможность расширения сети за счет Internet. Не менее важно и то, что данная технология позволяет создание мультимедийной сети на основе существующей инфраструктуры ЛВС или корпоративной интрасети.
Рекомендация Н.323 представляет собой очень общую спецификацию, которая опирается на множество других стандартов.
H.323 позволяет передавать мультимедийную информацию через существующие сети передачи данных с коммутацией пакетов. Для противодействия влиянию различной задержки пакетов в сетях в качестве протокола транспортного уровня в H.323 используется протокол RTP.
H.323 определяет четыре основных компонента для коммуникационной системы, основанной на данном стандарте: терминальное оборудование; шлюз; устройство управления доступом (gatekeeper); сервер многоточечных конференций (MCU — Multipoint Control Unit). Более подробно об этом читайте в статье «Мультисервисные сети: передача видео».
К настоящему времени о своих намерениях поддерживать стандарт Н.323 заявили более 120 ведущих компаний, в том числе занимающие лидирующее положение на рынке вычислительной техники, такие как Intel Corporation и Microsoft. Такая широкая поддержка делает Н.323 основным стандартом аудио- и видеоконференц-связи для сети Internet и локальных вычислительных сетей.
|
|
Качество обслуживания
В отличие от традиционного трафика данных мультимедийные потоки, такие как используемые в IP-телефонии или видеоконференц-связи, могут быть чрезвычайно чувствительными к пропускной способности линий связи и к задержке, предъявляя сетям специфические требования по качеству обслуживания (QoS — quality of service). К сожалению, протокол IP со своей моделью передачи дейтаграмм без установления соединения не гарантирует их доставку в нужном порядке, своевременную доставку и доставку вообще. Чтобы развертывать приложения реального времени в IP-сетях с допустимым уровнем качества, должны быть выполнены некоторые требования по полосе пропускания, времени задержки и неравномерностям задержки (джиттеру), причем таким образом, чтобы позволить мультимедийному трафику сосуществовать с традиционным в одной и той же сети. Ниже эти требования рассмотрены более подробно.
|
|
Полоса пропускания
Мультимедийным данным и, в частности, видеоизображениям, может требоваться большая полоса пропускания, чем обеспечивали традиционные сети. Несжатый поток видеосигнала стандарта NTSC, например, может требовать для передачи свыше 220 Мбайт/с. Даже в сжатом виде несколько мультимедийных потоков могут полностью подавлять любой другой трафик в сети.
|
|
Время задержки
Количество времени, затрачиваемое мультимедийным пакетом на перемещение от источника до адресата (время задержки), наносит основной ущерб воспринимаемому качеству вызова. Имеется много составляющих времени задержки, в том числе задержки передачи, ожидание в очередях на обслуживание в оборудовании сети и задержки в стеках протокола ГВМ. Для сохранения приемлемого уровня взаимодействия и во избежание неестественных пауз в диалоге время задержки должно быть минимизировано.
|
|
Неравномерности задержки
В отличие от трафика данных мультимедийные пакеты реального времени должны прибывать в определенном порядке и своевременно. Вариации во времени поступления пакетов (джиттер) должны быть ниже некоторого порога во избежание разрежения, пауз между пакетами (и, следовательно, раздражающих звуков и провалов во время сеанса связи). Неравномерности задержки определяют размеры используемых буферов и также влияют на время задержки.
|
|
Сосуществование различных типов трафика
В отличие от мультимедийного трафика данные передаются, как правило, с неравномерной плотностью потока, пачками, и прибывают в непредсказуемые промежутки времени (например, когда кто-то открывает Web-страницу или загружает файл из сайта FTP). Совокупности таких пачек могут забивать маршрутизаторы и вызывать паузы в мультимедийных конференциях, ставя в зависимость качество сеанса связи от работы каждого из пользователей сети (включая других пользователей IP-телефонии). Полоса пропускания, используемая для мультимедийного трафика, должна быть защищена от трафика данных, и наоборот.
Телефонные сети общего пользования гарантируют минимальное качество обслуживания, распределяя коммутируемые каналы для каждого телефонного вызова. Такой подход прост в реализации, но бесполезно расточает полосу пропускания, снижает отказоустойчивость и затрудняет интеграцию речи, видеосигнала и данных. Кроме того, пути данных с коммутацией каналов невозможно создать при использовании сетей без установления логического соединения, таких как IP-сети.
Обеспечение заданного качества обслуживания в IP-сетях предоставляет пользователям следующие возможности:
- поддержка мультимедийных приложений реального времени;
- обеспечение своевременных передач больших объемов данных;
- способность разделять сетевые ресурсы и избегать дефицита полосы пропускания для приложения.
Для обеспечения требуемого качества обслуживания в IP-телефонии предусмотрено использование ряда механизмов:
- протокола резервирования ресурсов (RSVP);
- управления локальным трафиком;
- установок типа обслуживания IP.
|
|
Протокол RSVP
Протокол RSVP (Resource Reservation Protocol) — это стандарт IETF, разработанный для обеспечения резервирования ресурсов (например, полосы пропускания) сети для изменяющейся топологии и мультимедиа. Через протокол RSVP запросы качества обслуживания от пользователя распространяются ко всем маршрутизаторам по пути данных, позволяя сети реконфигурироваться (на всех уровнях) для обеспечения желаемого уровня обслуживания.
Протокол RSVP резервирует ресурсы сети, устанавливая так называемые потоки через сеть. Поток — это путь сети, связанный с одним или более отправителей, одним или более получателей информации и некоторым качеством обслуживания. Передающая ГВМ, желающая послать данные, которые требуют некоторого QoS, будет вещать через разрешенного протоколом RSVP поставщика услуг, посылая сообщения пути соответствующим получателям. Эти сообщения пути, которые описывают требования полосы пропускания и обязательные параметры посылаемых данных, распространяются ко всем промежуточным маршрутизаторам вдоль всего пути.
Принимающая ГВМ, заинтересованная этими частными данными, подтверждает поток (и путь сети), посылая сообщения о резервировании через сеть, описывая характеристики полосы пропускания, требуемой для данных, которые она ожидает получить от отправителя. Как только эти сообщения о резервировании вернутся обратно к отправителю, промежуточные маршрутизаторы, учитывая возможную полосу пропускания, решают, принять или нет предложенное резервирование и ресурсы. Если принято положительное решение, то ресурсы выделяются и сообщения о резервировании передаются на участок пути от источника до адресата.
|
|
Локальное управление трафиком
Планирование передачи пакетов
Этот механизм может использоваться вместе с RSVP (если основная сеть поддерживает RSVP) или без RSVP. Трафик идентифицируется как принадлежность одному или другому потоку, а пакеты из каждого потока планируются к передаче в соответствии с параметрами управления трафиком для потока. Эти параметры в общем случае включают планируемую скорость и некоторую индикацию приоритета.
|
|
802.1p
Управление трафиком может также использоваться для определения величины приоритета пользователя стандарта 802.1, связанного с каждым передаваемым пакетом (для указания относительного приоритета пакета используется поле заголовка MAC). Коммутаторы, поддерживающие стандарт 802.1p, могут затем давать преимущество некоторым пакетам над другими, обеспечивая дополнительное качество обслуживания, поддерживаемое на уровне передачи данных.
|
|
Сигнальные механизмы уровня 2
Поставщик услуг QoS может использовать дополнительные механизмы управления трафиком, зависящие от специального нижележащего уровня передачи данных. Это может заставлять нижележащую сеть, например ATM, устанавливать соответствующий виртуальный канал для каждого потока. Когда среда нижележащего уровня — это традиционная сеть, соответствующая стандарту 802, поставщик услуг QoS может расширять стандартный механизм RSVP для сигнализации менеджеру полосы пропускания подсети (SBM — Subnet Bandwidth Manager). В общедоступных сетях SBM обеспечивает централизованное управление полосой пропускания.
|
|
Тип обслуживания IP
Каждая дейтаграмма протокола IP содержит трехразрядное поле, которое указывает ее приоритет. Для указания задержки, производительности или желаемой надежности для сети может использоваться дополнительное поле. Локальное управление трафиком может применяться для установки этих бит в заголовке протокола IP в отдельных потоках. Эти поля аналогичны установкам приоритета стандарта 802.1p, но интерпретируются средствами более высокого уровня сети.
Программные средства, используемые для IP-телефонии, подробно описываются в статье «IP-телефония с TAPI 3.0» (КомпьютерПресс № 5’99).
КомпьютерПресс 10'1999
