IP-телефония и традиционные телефонные сети

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

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

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

- децентрализованное управление многоточечной конференцией;

- централизованное управление многоточечной конференцией.

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

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

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

Примерами MCU первого типа являются - Encounter Netserver 1.2.1 фирмы VideoServer, MeetingPoint 4.0 фирмы -White Pine Software, PictureTel330 NetConference MultiPoint Video Server фирмы PictureTel.

Продукты MultiMedia Communications Exchange (MMCX) компании Lucent Technologies и MCU-323 фирмы RADVision представляют собой устройства второго типа. Такие системы, будучи однажды сконфигурированными, могут круглосуточно работать в коммутационных шкафах и управляться дистанционно. ММСХ (приложение) компании Lucent представляет собой универсальную коммуникационную систему, поддерживающую любые Н.323-совместимые устройства и IP-телефоны.

2.2.1 Архитектура системы на базе проекта TIPHON

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

Так, функции безопасности (согласно рекомендации Н.235) Определены в Н.323 версии 2 как необязательные. Наличие механизмов аутентификации, шифрования и обеспечения целостности информации не исключается, но и не является необходимым условием того, чтобы считать продукт соответствующим Н.323.

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

Функциональная модель TIPHON также состоит из трех компонентов - gatekeeper, шлюза и терминала, но шлюз разделен на три функциональных объекта. Это шлюз сигнализации (SG, приложение), транспортный шлюз (MG, примложение) и контроллер транспортного шлюза (MGC, приложение).

Шлюз сигнализации служит промежуточным звеном сигнализации между сетями IP и сетями на основе коммутации каналов (СКК). В задачи транспортного шлюза входят:

- преобразование и/или перекодирование передаваемой информации;

- обеспечение терминирования ИКМ-трафика, СКК и пакетного трафика;

- трансляция адресов;

- эхоподавление;

- воспроизведение различных сообщений для абонентов;

- прием и передача цифр кодом DTMF (приложение).

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

Главная функция транспортного шлюза (MG) - преобразование ИКМ-трафика в IP-пакеты и наоборот. В качестве этого элемента могут использоваться разные устройства:

- шлюзы;

- серверы доступа;

- системы передачи ATM;

- серверы интерактивных речевых сообщений.

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

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

Gatekeeper отвечает за контроль и управление объектами сети: выполняет преобразование адресов (например, телефонных номеров в соответствующие IP-адреса Н.323 и обратно) и маршрутизацию вызовов.

Gatekeeper в модели TIPHON поддерживает все те функции, которые определены для него в стандарте Н.323. Но, помимо этого, gatekeeper отвечает за:

- тарификацию;

- взаиморасчеты;

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

- управление.

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

Чтобы соответствовать рекомендациям TIPHON, продукты должны поддерживать следующие интерфейсы:

- интерфейс D - предназначен для маршрутизации вызовов между контроллерами зоны (gatekeeper);

- интерфейс С - для взаимодействия между шлюзом (MGC) и конт-роллером зоны;

- интерфейс N - определяет особенности взаимодействия между объек-тами MGC и MG.

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

2.2.2 Особенности сигнализации по концепции TIPHON

Базируясь на стандарте Н.323 для IP-сети, спецификация TIPHON дополняет его некоторыми обязательными процедурами, а также механизмами взаимодействия с сетями коммутации каналов. Функциональная модель TIPHON состоит из тех же компонентов -gatekeeper, шлюза и терминала, - что и модель Н.323, однако в ней предусмотрено разделение шлюза на три функциональных объекта. Это шлюз сигнализации (SG - Signalling Gateway), транспортный шлюз (MG - Media Gateway) и контроллер транспортного шлюза (MGC - Media Gateway Controller).

Шлюз сигнализации служит промежуточным звеном сигнализации между сетями с пакетной и канальной коммутацией. В задачи транспортного шлюза входит преобразование и/или перекодирование передаваемой информации; он обеспечивает терминирование ИКМ-трафика телефонных сетей и пакетного трафика, транслирует адреса, подавляет эхо, воспроизводит различные сообщения для абонентов, принимает и передает цифры кодом DTMF и т.д. Контроллер сигнализации MGC выполняет процедуры сигнализации Н.323, которые определены в рекомендациях Н.323, Н.225 (RAS и Q.931) и Н.245, и преобразует сообщения сигнализации телефонных сетей в сообщения сигнализации Н.323. Основная его задача -управлять работой транспортного шлюза, т.е. осуществлять контроль за соединениями, использованием ресурсов, трансляцией протоколов и т.п. Следует отметить, что MGC не обеспечивает управление вызовами. Это задачи gatekeeper, который выполняет их в соответствии с рекомендациями Н.323.

При использовании сигнализации ОКС №7 в контроллер MGC по IP-сети будут передаваться сообщения ISUP (подсистемы обслуживания вызовов сети ISDN, приложение). Если же применяется сигнализация по выделенному каналу (CAS, приложение), сигнальные сообщения сначала вместе с информацией абонента поступят в транспортный шлюз, а затем уже будут выделены в контроллер MGC. При этом предполагается использовать протокол MDTP (Multi-Network Datagram Transmission Protocol), который служит для инкапсуляции телефонных протоколов сигнализации (ISUP, CAS, PRI) и передачи переносимой ими информации в контроллер транспортного шлюза.

MGC анализирует информацию сигнализации и передает управляющую информацию в транспортный шлюз посредством специального протокола управления, в задачи которого входит обеспечение управления различными ресурсами (системой интерактивного речевого отклика, мостами конференцсвязи и т.д.), приемом и формированием сигналов DTMF, формированием тональных сигналов (готовности к набору номера, контроля посылки вызова, «занято» и пр.), эхо-подавлением, использованием кодеков (G.711, G.723.1, G.729, GSM и т.д.), сбором статистики, тестированием конечных точек (например, испытания по шлейфу), резервированием, разъединением и блокировкой конечных точек, шифрованием.

Протокол управления транспортными шлюзами MGCP представляет собой достаточно простой протокол клиент-сервер. Логика управления вызовами выполняется агентом (Call Agent), находящимся вне транспортного шлюза. Сам же транспортный шлюз представляется в виде объекта, состоящего из конечных точек - точек входа/выхода информацион-ных потоков и соединений - двух или более соединенных конечных точек. Модель определяет физические конечные точки (например, окончания соединительных линий) и виртуальные конечные точки (например, аудиоисточники). Сам протокол MGCP использует принцип «ведущий/ ведомый», согласно которому агент управления вызовами передает транспортному шлюзу команды для управления конечными точками и соединениями, а также инициации определенных действий.

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

Дальнейшим развитием протокола MGCP является протокол управления вызовами Megaco (Media Gateway Control), известный также как стандарт ITU H.248, который определяет взаимодействие, с одной стороны, шлюза между разными средами передачи данных (Media Gateway, MG) и, с другой, - контроллера шлюзов между средами передачи данных (Media Gateway Controller, MGC) (рисунок 2.9). Иными словами, Megaco разработан для внутри-доменного удаленного управления устройствами, отвечающими за установление соединения или проведение сеанса связи, включая шлюзы VoIP, серверы удаленного доступа, мультиплексоры цифровых абонентских линий (Digital Subscriber Line Access Multiplexer, DSLAM), маршрутизаторы с поддержкой многопротокольной коммутации с использованием меток (Multiprotocol Label Switching, MPLS), оптические кросс-коннекторы, модули агрегирования сеансов РРР и другие.

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

Типичным примером работы протокола MGCP является проверка состояния конечной точки на предмет снятия трубки (которую поднимает абонент, чтобы сделать звонок). После фиксации события «снятие трубки» шлюз сообщает об этом контроллеру, после чего последний может послать шлюзу команду подать в линию непрерывный гудок и ждать тональных сигналов DTMF набираемого номера абонента. После получения номера контроллер решает, по какому маршруту следует направить вызов, и, используя протокол сигнализации между контроллерами, в том числе Н.323, SIP или Q.BICC, взаимодействует с оконечным контроллером. Оконечный контроллер дает соответствующему шлюзу указание подать звонок на вызываемую линию. Когда этот шлюз определяет, что вызываемый абонент снял трубку, оба контроллера дают соответствующим шлюзам команды на установление двухсторонней голосовой связи по сети передачи данных. Таким способом данные протоколы распознают состояния конечных точек, уведомляют об этих состояниях контроллер,- генерируют в линии сигналы (например, непрерывный гудок), а также формируют потоки данных между подключенными к шлюзу конечными точками и сетью передачи данных, например потоки RTP (приложение).

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

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

2.3 Характеристики шлюзов IP-телефонии

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

Совместимость со стандартом Н.323: базовым протоколом для работы IP-оборудования подавляющим большинством производителей был принят протокол, описанный МСЭ-Т в рекомендации H.323v2, стандартизирующей мультимедийную связь в сетях с коммутацией пакетов.

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

Стандарты, отличные от Н.323, используют в своей работе шлюзы СХ950 Access Switch компании Memotec Comminications Inc., F-50 IP и F-200.

IP компании Neura Communications Inc., VIP Gateway от Nortel Networks, сетевые станции Network Exchange 2201/2210 фирмы Netrix Corp.

Наличие механизмов резервирования ресурсов: поддержка какой-либо схемы приоритезации (протокол резервирования RSVP или байт дифференциации услуг - DS byte) для осуществления возможности выбора приоритета между передаваемой речью или данными является важной харак-теристикой шлюза. При этом протокол RSVP (приложение) позволяет маршрутизаторам придерживать часть полосы пропускания для организации голосового трафика. У шлюзов IPT (Ericsson Inc.), Netblazer 8500 (Digi International), Packetstar IP Gateway 1000 (Lucent Technologies Inc.), Vocaltec Telephony Gateway (Vocaltec Communications Ltd.), Webphone Gateway Exchange (Netspeak Corp.) эта возможность отсутствует.

Поддержка основных телефонных интерфейсов и типов сигнализаций: важными критериями при оценке характеристик шлюзов является возможно большое разнообразие телефонных интерфейсов, поддерживаемых IP-шлюзом (E1, PRI, BRI) и аналогового в частности, а также поддержка основных типов телефонной сигнализации: CAS, DTMF, PRI и ОКС №7. Существенную роль играет поддержка оборудованием механизмов безопасности в соответствии с Рекомендацией Н.235.

Транспортные архитектуры: диапазон транспортных архитектур, с которыми работают современные шлюзы, достаточно широк: выделенные линии, ISDN, Frame Relay, ATM, Ethernet.

Шлюзы, поддерживающие передачу речи через Frame Relay, производят компании 3COM (Pathbuilder S200 Voice Access Switch), Cisco (серия 2600, 3600), Motorola (Vanguard 6560/6520), Newbridge Networks Corp. (MainStreetXpress 36100 VoIP Gateway) и другие. Режим ATM поддерживают шлюзы, выпускаемые фирмами Lucent Technologies (Packetstar IP Gateway 1000), Cisco (серия 2600, 3600), Ascend Communications (MultiVoice Gateway), Motorola Vanguard 6560/6520 Multiservice Access Device и другие.

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

Обеспечение факс-связью: подавляющее большинство производимых шлюзов имеют возможность обеспечивать факсимильную, связь на базе протокола IP. Она опирается на два основных стандарта, предложенных МСЭ-Т. Стандарт Т.37 сводит передачу факсов к доставке с промежуточным хранением, так как изображения факсов передаются в виде вложений электронной почты. Благодаря Т.37 факс-аппараты и факс-серверы на базе IP различных поставщиков могут взаимодействовать друг с другом так же согласованно, как и традиционные факсы. Еще один стандарт Т.38 описывает передачу факсов в реальном времени либо посредством имитации соединения с факс-аппаратом, либо с помощью метода модуляции под названием FaxRelay. Т.38 может использоваться для реализации функциональности, более схожей с традиционной факсимильной связью, например для немедленного подтверждения.

Управление шлюзом: шлюзы могут отличаться предусмотренными средствами управления. Данные средства управления имеют своей функцией маршрутизацию вызовов между шлюзами и перекодировку телефонных номеров в IP-адреса. Такими средствами оснащаются почти все шлюзы. Они конструктивно могут быть интегрированы со шлюзом или представлять собой отдельный мультимедийный менеджер конференций или многоголосовый менеджер доступа. Одним из решений является использование единого пакета, включающего в себя средства бил-линга, маршрутизации вызовов и сетевого администрирования. Примером является шлюз компании Clarent (Clarent Carrier Gateway), взаимодействующий с пакетом Clarent Command Center, а также пакет Telephony Packet Network компании Northern Telecom Ltd. (Nortel).

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

2.3.1 Классификация шлюзов IP-телефонии

Классификация шлюзов по области применения: шлюзы IP-телефонии по масштабности применения можно разделить на два основных типа: шлюзы, ориентированные на корпоративное применение, и шлюзы, предназначенные для операторов и поставщиков услуг связи. Продукты последнего типа отличаются большой емкостью и масштабируемостью, присутствием средств аутентификации и мониторинга, а также дополнительных возможностей биллинга. Примерами таких устройств являются следующие шлюзы: IPTC (приложение) компании Ericsson, PacketStar IP Gateway 1000 компании Lucent Technologies, MainStreetXpress 36100 от Newbridge, Hi-Gate 1000 компании ECI Telecom, Clarent Gateway фирмы Clarent. Типовая инсталляция этих шлюзов предусматривает их подключение с одной стороны к IP-сети (например, через Ethernet-интерфейс), а с другой - к традиционной телефонной сети общего пользования (обычно по Е1-каналам).

Исполнение шлюзов IP-телефонии:

1) автономные IP-шлюзы;

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

Существуют шлюзы на базе ПК-серверов с платами с цифровой обработкой сигналов (DSP, приложение). Фирма Dialogic выпускает плату DM3 IP (с программным обеспечением от VocalTec); Micom - платы IP-телефонии для аналоговых линий, Т-1 и Е-1; NMS (приложение) - платы E-Fusion Inc., используемые многими разработчиками, в том числе Inter-Tel. Оборудование этого типа производят также компании Vocaltec Communications Ltd., Neura Communications Inc., Netrix Corp. и другие. Автономные устройства могут стать хорошим решением для сетей, уже имеющих маршрутизаторы от различных производителей. Платы-маршрутизаторы, в свою очередь, применимы для дополнительного оснащения работающего оборудования функциями IP-телефонии.

2) маршрутизаторы-шлюзы;

В мире производителей оборудования телекоммуникаций наметилась тенденция к тому, что крупные компании традиционное сетевое оборудование оснащают узлами, отвечающими за IP-телефонию. Одной из первых в этом направлении стала работать компания Cisco Systems (устройства серии 2600 и 3600), за которой последовали другие фирмы (Memotec Comminications Inc. с машиной СХ950 Access Switch, Motorola Inc. с устройством Vanguard). Эта продукция - маршрутизаторы и устройства доступа к распределенным сетям со встроенными шлюзами IP-телефонии - занимает отдельную, важную нишу на рынке сетевого оборудования.

3) RAS-шлюзы;

Свою часть рынка оборудования для IP-телефонии занимают шлюзы для VoIP, состоящие из плат, устанавливаемых в серверы дистанционного доступа. В этом направлении работают компании Ascend Communications и Digi International (устройства Multivoice Gateway и Netblazer 8500 соответственно). Установка устройств данного типа при построении IP-сетей оправдана при работе с приложениями с множеством голосовых портов и имеющими предельно важное значение.

4) шлюзы - модуль и для УПАТС;

В настоящее время получили распространение шлюзы IP-телефонии, представляющие собой конструктивно модули для классических учрежденческих АТС. Компании Lucent Technologies и Nortel Networks производят их для своих станций Defmity и Meridian 1. Причем, такая система перед тем, как установить соединение через IP-сеть, проверяет качество связи. В случае достаточного ее качества (норма устанавливается администратором системы), соединение устанавливается. Иначе, вызов направляется по традиционным линиям связи.

5) шлюзы с интеграцией бизнес-приложений;

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

6) учрежденческие АТС на базе шлюзов;

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

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

7) сетевые платы с функциями телефонии;

Одним из решений IP-телефонии являются многоцелевые сетевые платы с функциями телефонии (небольшие устройства типа Internet PhoneJACK от Quicknet Technologies, EtherPhone фирмы PhoNet Communications или крупные устройства типа плат ATM от Sphere Communications). Такие устройства оборудованы портами RJ-11 для подключения обычного телефонного аппарата.

8) автономные IP-телефоны;

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

Помимо аппаратной существуют и программные реализации IP-телефонов. В этом случае персональный компьютер (ПК), оборудованный телефонной гарнитурой или микрофоном и акустическими системами, превращается в многофункциональный коммуникационный центр. Пользователь ПК, кроме доступа к обычному телефонному сервису, получает набор дополнительных возможностей: получение информации о звонящем клиенте (благодаря наличию стандартного интерфейса TAPI (приложение) к другим программам), контроль за телефонными вызовами и работой с речевой почтой. Недостатками таких систем является неполная совместимость с Н.323 версии 2, а также отсутствие поддержки функций по обеспечению безопасности в работе с gatekeeper [22].

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

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

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

Основными составляющими качества IP -телефонии являются (демон-страционный лист 3):

- качество речи, которое включает;

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

- разборчивость - чистота и тональность речи; эхо - слышимость собственной речи; уровень - громкость речи;

- качество сигнализации, включающее;

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

- завершение вызова - время отбоя и скорость разъединения;

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

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

- факторы качества IP-сети;

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

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

- факторы качества шлюза;

- требуемая полоса пропускания - различные вокодеры требуют раз-личную полосу. Например, вокодер G.723 требует полосы 16,3 кбит/с для каждого речевого канала; - задержка - время, необходимое цифровому сигнальному процессору DSP или другим устройствам обработки для кодирования и декодирования речевого сигнала; буфер джиттера - сохранение пакетов данных до тех пор, пока все пакеты не будут получены и можно будет передать в требуемой последовательности для минимизации джиттера;

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

- подавление эхо - механизм для подавления эхо, возникающего при пе-редаче по сети; управление уровнем - возможность регулировать громкость речи.



2.5 Влияние сети на показатели качества IP-телефонии

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

Затруднение диалога и перекрытие разговоров становятся серьезным вопросом качества, когда задержка в одном направлении передачи превышает 250 мс. Можно выделить следующие источники задержки при пакетной передачи речи из конца в конец (рисунок 2.12).

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

- G.729 CS-ACELP (8 кбит/с) - 10 мс;

- G.723.1 -Multi Rate Coder (5,3; 6,3 кбит/с) - 30 мс.

- задержка обработки: процесс кодирования и сбора закодированных отсчетов в пакеты для передачи через пакетную сеть создает определенные задержки. Задержка кодирования или обработки зависит от времени работы процессора и используемого типа алгоритма обработки. Для уменьшения загрузки пакетной сети обычно несколько кадров речевого кодера объединяются в один пакет. Например, три кадра кодовых слов G.729, соответствующих 30 мс речи, могут быть объединены для уменьшения размера одного пакета;

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

Время задержки при передаче речевого сигнала можно отнести к одному из трех уровней:

- первый уровень до 200 мс - отличное качество связи. Для сравнения, в телефонной сети общего пользования допустимы задержки до 150-200 мс;

- второй уровень до 400 мс - считается хорошим качеством связи. Но если сравнивать с качеством связи по сетям ТфОП, то разница будет видна. Если задержки постоянно удерживается на верхней границе 2-го уровня (на 400 мс), то не рекомендуется использовать эту связь для деловых переговоров;

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

Качество Интернет-телефонии попадает под 2-3 уровни, причем невозможно уверенно сказать, что тот или иной провайдер Интернет- телефонии работает по второму уровню, так как задержки в сети Интернет изменчивы. Более точно можно сказать о провайдерах IP-телефонии, работающих по выделенным каналам. Они попадают под 1-2 уровни. Также необходимо учитывать задержки при кодировании/декодировании голосового сигнала. Средние суммарные задержки при использовании IP-телефонии обычно находятся в пределах 150-250 мс.

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

Важно отметить тот факт, что задержки в сетях с коммутацией пакетов влияют не только на качество передачи речевого трафика в реальном времени. Не менее важно и то, что данные задержки в определенных ситуациях могут нарушить правильность функционирования телефонной сигнализации в цифровых трактах Е1/Т1 на стыке голосовых шлюзов с оборудованием коммутируемых телефонных сетей. Причиной этого можно назвать тот факт, что набор рекомендаций Н.323 в момент своего появления в 1997 г. был ориентирован на мультимедийные приложения, осуществляющие аудио и видеоконференцсвязь через сети IP. Данное решение позволяло значительно снизить стоимость таких систем по сравнению с их аналогами, работающими в сетях традиционной телефонии с коммутацией каналов. В процессе выделения IP-телефонии в самостоятельное направление и развития ее до услуги операторского уровня возникла необходимость соединения IP-шлюзов с телефонными станциями ТфОП по цифровым трактам Е1/Т1. При этом, шлюзы осуществляют взаимодействие с цифровыми АТС, используя стандартные механизмы телефонной сигнализации Q.931, интерпретированные через команды Н.225 и транслируемые в IP-сети с использованием протокола TCP. Согласно рекомендации Q.931, при установлении телефонного соединения значения временных задержек между фазами выполнения команд сигнализации строго регламентированы. Однако, при интерпретации в IP-шлюзах команд телефонной сигнализации Q.931 стеком Н.225/ТСРЯР, задержки, возникшие на пути прохождения сигнала, увеличивают заданные временные интервалы между командами Q.931, и в большинстве случаев нарушают целостность функционирования данного протокола. Хотя версия 2 набора рекомендаций Н.323 в фазе 2 предусмат-ривает процедуру H.323v2 Fast Connect, ускоряющую обработку команд Q.931 стеком Н.225/ТСР, задержки IP-канала, особенно характерные для инфраструктуры Интернет, могут заведомо превышать все допустимые значения временных интервалов протокола Q.931. Данное обстоятельство можно расценивать как еще один аргумент в пользу использования выделенных каналов при построении сетей IP-телефонии [1].

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

1) джиттер, зависимый от данных (Data Dependent Jitter - DDJ) - проис-ходит в случае ограниченной полосы пропускания или при нарушениях в сетевых компонентах;

2) искажение рабочего цикла (Duty Cycle Distortion - DCD) - обуслов-лено задержкой распространения между передачей снизу вверх и сверху вниз;

3) случайный джиггер (Random Jitter - RJ) - является результатом теп-лового шума.

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

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

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

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

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

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

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



3. Практическая часть

3.1 Обеспечение качества IP-телефонии на базе протокола RSVP

Одним из средств обеспечения качества IP-телефонии и особенно Интернет-телефонии является использование протокола резервирования ресурсов (Resource Reservation Protocol, RSVP), рекомендованного комитетом IETF. С помощью PSVP (приложение) мультимедиа-программы могут потребовать специального качества обслуживания (specific quality of service, QoS) посредством любого из существующих сетевых протоколов - главным образом IP, хотя возможно использовать и UDP (приложение) - чтобы обеспечить качественную передачу видео- и аудиосигналов. Протокол RSVP предусматривает гарантированное QoS (приложение) благодаря тому, что через каждый компьютер, или узел, который связывает между собой участников телефонного разговора, может передаваться определенное количество данных.

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

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

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

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

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

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

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

3.1.2 Обеспечение качества IP-телефонии на базе протоколов RTP и RTCP

Для уменьшение значений джиггера и задержек на сетевом уровне применяются гарантирующие пользователю заданный уровень качества механизмы RSVP, MPLS, Diff-Serv, ATM (приложение) и др. Они улучшают качество услуг, предоставляемых сетью, но не могут полностью устранить образование очередей в сетевых устройствах, а, следовательно, и совсем убрать джиттер. Компенсировать его негативное влияние позволяет разработанный IETF протокол прикладного уровня RTP (Realtime Transport Protocol), который используется технологиями Н.323 и SIP (приложение).

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

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

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

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

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

Возможности RTF можно расширить, объединив его с еще одним протоколом IETF, a именно с протоколом управления передачей в реальном времени (Realtime Transport Control Protocol, RTCP). С помощью RTCP (приложение) контролируется доставка RTF-пакетов и обеспечивается обратная связь с передающей стороной и другими участниками сеанса. RTCP периодически рассылает свои управляющие пакеты, используя тот же механизм распределения, какой применяется и для RTF-пакетов с пользовательской информацией.

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

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

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



3.1.3 Обеспечение качества IP-телефонии на базе протокола IPv6

После нескольких лет тестирования организация Internet Assigned Numbers Authority приступила к развертыванию IPv6 (версии 6 протокола Internet Protocol) - системы цифровой адресации Internet нового поколения.

Начать разработку IPv6 организацию Internet Engineering Task Force побудили опасения, что Internet израсходует весь запас уникальных адресов. Первоначально сеть Internet была рассчитана на связь небольшого количества исследовательских сетей. Поэтому поле адреса в используемой в настоящее время системе адресации IPv4 может принимать около 4 млрд. уникальных значений. Число уникальных адресов, обеспечиваемых новой системой -десять в восемнадцатой степени, или миллиард миллиардов. Этого должно хватить на много лет вперед.

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

IPv6 включает следующие возможности, отсутствующие у IPv4:

- расширенное адресное пространство: IPv6 использует 128-битовые адреса вместо 32-битовых IPv4. В результате адресное пространство увеличивается в 2⁹⁶раз, что явно достаточно даже в случае неэффективного распределения сетевых адресов;

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

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

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

Не вызывает сомнений тот факт, что переход от IPv4 к IPv6 не может быть мгновенным. Долгое время две версии IP будут сосуществовать. Более того, поначалу узлы, реализующие IPv6, не будут предоставлять всех необходимых сервисов, а их расположение окажется напоминающим острова в океане IPv4. Следовательно, от узлов с IPv6 требуется выполнение двух свойств:

- возможность взаимодействовать с 1Ру4-узлами;

- возможность передавать пакеты IPv6 через существующую инфраст-руктуру IPv4.

Чтобы выполнить эти требования, рабочая группа по переходу на IP нового поколения предлагает два основных метода:

- одновременная поддержка в узлах (и в хостах, и в маршрутизаторах) IPv6 двух стеков протоколов (IPv6/IPv4);

- туннелирования пакетов IPv6 для их передачи через инфраструктуру IPv4 [19].

3.1.4 Обеспечение качества IP-телефонии на базе дифференцированного обслуживания

Еще одна технология обеспечения QoS разработана рабочей группой IETF (приложение) по дифференцированному обслуживанию (Differentiated Services, DiffServ). Эта группа выделилась из рабочей группы по интегрированному обслуживанию (Integrated Services, IntServ), задача которой состоит в разработке стандартов для поддержки трафика Internet реального времени.