Рис. 1. Структурная схема организации телефонной связи через сеть Интернет
(информация взята с http://www.phone-xxi.ru)
Известны и практически
реализуются две базовые схемы IP-телефонии.
Первая из них рис. 1 связана с организацией
телефонных переговоров между пользователями
персональных компьютеров, оснащенных
мультимедийным оборудованием и (или)
специальными программными (программно-аппаратными)
средствами, обеспечивающим ведение дуплексных
телефонных переговоров, необходимый сервис и
контроль. Пользовательские компьютеры могут
входить в состав локальной сети, иметь
персональный IP-адрес или подключаться к сети
Интернет при помощи модема.
Вторая схема - рис. 2, предусматривает использование специальных многофункциональных устройств - шлюзов. Шлюз предназначен для преобразования аналоговых речевых и служебных сигналов в цифровую последовательность, организации из этой последовательности пакетов глобальной сети Интернет и передачи их в сеть, прием пакетов и восстановление цифровой последовательности - цифровых речевых и служебных сигналов и их преобразование в аналоговую форму, а так же решение большого перечня задач, связанных с организацией интерфейсов, генерированием и детектированием сигналов абонентской сигнализации, управлением режимами телефонных переговоров и многое другое.
Шлюзы могут устанавливаться на серверах Интернет-провайдеров, городских телефонных станциях, учрежденческих АТС, серверах локальных вычислительных сетей, Web-серверах компаний, нуждающихся в организации голосовых горячих линий, служб технической поддержки, диалоговых справочных служб и т.д. Шлюзы, наконец, могут устанавливаться на маршрутизаторах.
В зависимости от схемы организации связи архитектура шлюза может меняться, могут модифицироваться некоторые функции, выполняемые шлюзом, интерфейсы. Однако главные задачи шлюза - обеспечение качественного дуплексного телефонного общения абонентов в режиме пакетной передачи и коммутации цифровых сигналов сохраняются.
Понятно, что рассмотренные выше
базовые схемы могут комбинироваться. Возможны
разнообразные способы организации IP-телефонной
связи с использованием шлюзов, размещенных в
функционально различных точках сети. Однако как
свидетельствуют результаты многочисленных
обзорных публикаций, рекламные сообщения
практически всех фирм, работающих в области IP-телефонии,
и здравый смысл применение шлюзов является
сегодня магистральным направлением, а
собственно шлюз - ключевым элементом.
Рассмотрим процесс речевого диалога в системе Интернет с информационной точки зрения. Этот процесс имеет следующие три фазы:
соединение абонентов,
обмен информацией,
разъединение абонентов.
Во время исполнения первой и третьей фаз передаются только управляющие данные и при этом происходит установление соединения. На протяжении второй фазы абоненты обмениваются как управляющими так и информационными данными.
Источником информационных данных является речевой сигнал, возможной моделью которого является нестационарный случайный процесс. В первом приближении можно выделить следующие типы сигнальных фрагментов: вокализированные, невокализированные, переходные и паузы. При передаче речи в цифровой форме, т.е. в виде последовательности чисел, каждый тип сигнала при одной и той же длительности и одинаковом качестве требует различного числа двоичных единиц (бит) для кодирования и передачи. Следовательно, скорость передачи разных типов сигнала также может быть различной. Отсюда следует важный вывод: передачу речевых данных в каждом направлении дуплексного канала разумно рассматривать как передачу асинхронных логически самостоятельных фрагментов цифровых последовательностей (транзакций) с блочной (дейтаграммной) синхронизацией внутри транзакции, наполненной блоками различной длины.
Описанная модель речевого сигнала является базисной для изучения (анализа)и построения (синтеза) IP-телефонных систем. Асинхронность же транзакций позволяет с одной стороны оптимизировать трафик за счет снижения средней скорости передачи и с другой - за счет относительной свободы в воспроизведении каждой транзакции скомпенсировать неидеальности канала передачи. В связи с изложенным обсуждаемая информационная модель речевого сигнала позволяет изменить стандартную постановку задачи конструирования кодека речевого сигнала для систем IP-телефонии. В отличие от традиционных обсуждаемые кодеки целесообразно строить с переменной скоростью.
Среди каналов, на которых может быть организована IP-телефонная связь, особый интерес представляют каналы Интернет. Несмотря на большое разнообразие, характеризуемое пропускными способностями, числом маршрутизаторов, характеристиками физических линий и пр. реально действующие каналы Интернет характеризуются
действительной пропускной способностью, определяемой наиболее "узким местом" в виртуальном канале в данный момент времени;
трафиком, также являющимся функцией времени;
задержкой пакетов, что определяется трафиком, числом маршрутизаторов, реальными физическими свойствами каналов передачи, образующими в данный момент времени виртуальный канал, задержками на обработку сигналов, возникающими в речевых кодеках и других устройствах шлюзов; все это также обеспечивает зависимость задержки от времени;
потерей пакетов, обусловленной наличием "узких мест", очередями;
перестановкой пакетов, пришедших разными путями.
Упомянутые
обстоятельства и эффекты наглядно могут быть
представлены в графической форме. Так, на рис. 3
приведены гистограммы задержек пакетов,
показывающие эмпирические распределения
вероятностей задержек. На оси абсцисс отложена
относительная задержка, характеризующая
реальное положение пакета в последовательности
на временной оси по отношению к идеальному в
предположении, что первый пакет пришел без
задержки.
Рис. 3. Гистограммы задержки пакетов
Детальное изучение
явлений задержки и потери пакетов позволяет
сделать следующие выводы. Задержки пакетов
существенно зависят от времени. Кривая этой
зависимости имеет большой динамический диапазон
и скорость изменения. Заметные изменения времени
распространения могут произойти на протяжении
одного не продолжительного сеанса связи, а
колебания времени передачи могут быть в
диапазоне от десятков до сотен миллисекунд и
даже превышать секунду.
Зависимость рис. 3 показывает величины возникающих задержек и их вероятности. Данная информация исключительно важна для организации процедуры обработки и выбора параметров обработки. Так, становится ясным, что временная структура речевого пакетного потока меняется. Возникает необходимость организации буфера для превращения пакетной речи, отягощенной нестационарными задержками в канале, возможными перестановками пакетов, в непрерывный естественный речевой сигнал реального времени. Параметры буфера определяются компромиссом между величиной запаздывания телефонного сигнала в режиме дуплексной связи и процентом потерянных пакетов. Потеря пакетов является другим важнейшим негативным явлением в Интернет -телефонии.
На рис. 4 представлены гистограммы потерь пакетов. По оси абсцисс отложено число подряд потерянных пакетов. Анализ гистограммы показывает, что наиболее вероятны потери одного, двух и трех пакетов. Потери больших пачек пакетов редки.
Существенно, что потеря большой группы пакетов приводит к необратимым локальным искажениям речи, тогда как потери одного, двух, трех пакетов можно пытаться компенсировать.
Далее будет показано, что отмеченные обстоятельства по новому ставят задачу синтеза речевых кодеков для IP-систем. Интуитивно ясно, что с повышением трафика возрастают задержки и потери в телефонном канале. В условиях ограниченных пропускных способностей это проявляется не только при интегральном увеличении загрузки каналов, например, в часы наибольшей нагрузки, но и при увеличении потока локального источника информации. Кривые графиков рис. 3 и 4, построенные для различных скоростей передачи информации убедительно свидетельствуют о необходимости использования как можно более низких скоростей передачи речевой информации при естественном требовании обеспечения желаемого качества телефонной связи.
Особенности функционирования каналов для передачи речевых данных, и прежде всего сети Интернет, а также возможные варианты построения систем телефонной связи на базе сети Интернет предъявляют ряд специфических требований к речевым кодекам (вокодерам). В силу пакетного принципа передачи и коммутации речевых данных отпадает необходимость кодирования и синхронной передачи одинаковых по длительности фрагментов речи, Как было отмечено выше, наиболее целесообразным и естественным для систем IP-телефонии является применение кодеков с переменной скоростью кодирования речевого сигнала. В основе кодека речи с переменной скоростью лежит классификатор входного сигнала, определяющий степень его информативности и, таким образом, задающий метод кодирования и скорость передачи речевых данных. Наиболее простым классификатором речевого сигнала является Voice Activity Detector (VAD), который выделяет во входном речевом сигнале активную речь и паузы. При этом, фрагменты сигнала, классифицируемые как активная речь, кодируются каким-либо из известных алгоритмов (как правило на базе метода Code Excited Linear Prediction - CELP) с типичной скоростью 4 - 8 Кбит/с. Фрагменты, классифицированные как паузы, кодируются и передаются с очень низкой скоростью (порядка 0.1 - 0.2 Кбит/с), либо не передаются вообще. Передача минимальной информации о паузных фрагментах предпочтительна.
Схемы более эффективных классификаторов входного сигнала детальнее осуществляют классификацию фрагментов, соответствующих активной речи. Это позволяет оптимизировать выбор стратегии кодирования (скорости передачи данных), выделяя для особо ответственных за качество речи участков речевого сигнала большее число бит (сответственно большую скорость), для менее ответственных - меньше бит (меньшую скорость). При таком построении кодеков могут быть достигнуты низкие средние скорости (2 - 4 Кбит/с) при высоком качестве синтезируемой речи.
Необходимо отметить, что для рассматриваемых приложений традиционная для вокодеров проблема снижения задержки при обработке сигнала в кодеке не является актуальной, так как величина суммарной задержки при передаче речи в системах IP-телефонии главным образом определяется задержками вносимыми каналами сети Интернет. Тем не менее, решения, позволяющие снизить задержку в вокодере, представляют практический интерес.
Проведенный в различных исследовательских группах анализ качества синтезированной речи при передачи речевых данных через сеть Интернет показывает, что основным источником возникновения искажений, снижения качества и разборчивости синтезированной речи является прерывание потока речевых данных, вызванное потерями при передачи по сети либо превышением предельно допустимого времени доставки пакета с речевыми данными. Гистограммы распределения числа последовательно потерянных пакетов, приведенные на рис. 4, показывают, что вероятность одиночных потерь выше вероятности потерь нескольких кадров подряд. Можно ожидать, что с развитием сети Интернет при дальнейшем увеличении ее пропускной способности, оптимизации маршрутизаторов и протоколов преобладающую роль будут играть потери одиночных пакетов. Следует заметить, что в случае прихода пакета данные, как правило, доставляются без ошибок. В таких условиях помехоустойчивое кодирование речевых данных нецелесообразно.
Таким образом, одной из важнейших задач при построении вокодеров для IP-телефонии является создание алгоритмов компрессии речи толерантных к потерям пакетов.
Для обслуживания широкой сети абонентов система IP телефонной связи с использованием шлюзов должна включать абонентские линии связи с аналоговыми окончаниями. Это означает, что синтезированный в шлюзе аналоговый речевой сигнал по соединительной линии будет поступать на телефонный аппарат абонента. Точно также сигнал с выхода микрофона телефонного аппарата абонента по аналоговой линии будет поступать на вход вокодера, размещенного в шлюзе. Хорошо известно, что классические алгоритмы низкоскоростной компрессии речи чувствительны к амплитудно-частотным искажениям, возможным в соединительных линиях и акустических трактах. При создании алгоритмов низкоскоростных вокодеров это обстоятельство должно приниматься во внимание.
Каковы же перспективы создания вокодеров для IP-телефонии? Что имеется сегодня и ожидается в ближайшее время? Насколько можно судить по литературным данным специальных разработок для Интернет-телефонии, рекомендованных ITU-T (сектор стандартизации в области телекоммуникаций международного союза телекоммуникаций) пока не существует. Среди международных стандартов, рекомендуемых для подобных систем, чаще других упоминается G.723.1, обеспечивающий передачу речи со скоростью 5.3 и 6.3 Кбит/с, а так же G.729 для скорости передачи 8 Кбит/с.
Гарантируя достаточно высокое качество речи в идеальных условиях передачи, упомянутые стандарты были разработаны для использования в каналах, отличных от Интернет и уже позже частично адаптировались для условий потерь пакетов. Развития этих стандартов включают в себя Voice Activity Detector и элементы, ответственные за синтез речевого сигнала на фрагментах, соответствующих потерянным речевым данным. В настоящее время ведущие в области телекоммуникаций фирмы и университеты проводят разработки алгоритмов вокодеров для Интернет-телефонии. Ориентируясь на рекламные публикации и собственные исследования, можно ожидать появления в ближайшие годы алгоритмов компрессии со средними скоростями 2 - 4 Кбит/с и ниже с качеством синтезированной речи, близким к коммерческому, при допустимых искажениях в условиях 20% потерь пакетов с речевыми данными.
В заключении этого раздела следует коротко отметить перспективные пути построения низкоскоростных вокодеров с переменной скоростью. Во всех случаях здесь предпочтительными являются методы, использующие линейное предсказание. При этом, для скоростей более 3 Кбит/с целесообразно использование CELP-алгоритмов. Для более низких скоростей передачи данных алгоритмы будут, по-видимому, строится на базе тщательной классификации речевого сигнала с их последующим рациональным кодированием.
Реализовывать функции IP-телефонии будет устройство (или устройства) - шлюз, которое с сетевой точки зрения осуществляет преобразование управляющей информации и данных, поступающих из одной сети (например PSTN) в пакеты глобальной сети Интернет и обратно. Причем такое преобразование не должно значительно исказить исходный речевой сигнал, а режим передачи обязан сохранить обмен информацией между абонентами в реальном масштабе времени.
Более полно основные функции выполняемые шлюзом при соединении типа "точка-точка" состоят в следующем.
Реализация физического интерфейса с коммуникационной сетью.
Детектирование и генерация сигналов абонентской сигнализации.
Преобразование сигналов абонентской сигнализации в пакеты данных и обратно.
Преобразование речевого сигнала в пакеты данных и обратно.
Соединение абонентов.
Передача по сети сигнализационных и речевых пакетов.
Разъединение связи.
Большая часть функций шлюза в рамках архитектуры TCP/IP реализуются в процессах прикладного уровня.
Наличие разноплановых с вычислительной точки зрения функций, выполняемых системой, порождает проблему ее программной и аппаратной реализации. Рациональное решение этой проблемы основано на использовании распределенной системы, в которой управленческие задачи и связь с сетью осуществляется с помощью универсального процессора, а решения задач сигнальной обработки и телефонного интерфейса выполняются на цифровом процессоре обработки сигналов.
Схема сигнальной обработки в
шлюзе при подключении аналогового 2-х проводного
телефонного канала PSTN показана на рис. 5.
Телефонный сигнал с 2-х проводной линии поступает на дифференциальную систему, которая разделяет приемную и передающую часть канала. Далее сигнал передачи вместе с "просочившейся" частью сигнала приема подается на аналого-цифровой преобразователь и превращается либо в стандартный 12 разрядный сигнал либо в 8-ми разрядный сигнал, закодированный по µ- либо А- закону. В последнем случае обработка должна также включать соответствующий экспандер. В устройстве эхо-компенсации из сигнала передачи удаляются остатки принимаемого сигнала. Эхо-компенсатор представляет собой адаптивный нерекурсивный фильтр, длина памяти (порядок) которого и механизм адаптации выбираются такими, чтобы удовлетворить требованиям рекомендации МКKТТ (ITU-T) G.165. Для обнаружения и определения сигналов внутриполосной телефонной сигнализации (MF сигналов), сигналов DTMF либо импульсного наборов используются детекторы соответствующих типов. В режиме сессии дальнейшая обработка входного сигнала происходит в речевом кодере. В анализаторе кодера сигнал сегментируется на отдельные фрагменты длительностью 30 мс и каждому входному блоку, состоящему из 240 отсчетов (1920 бит при А либо µ- коде и 2880 бит при 12-ти разрядном линейном коде), сопоставляется информационный кадр длиной 137 бит.
Часть параметров, вычисленная в анализаторе, используется в блоке определения голосовой активности (VAD - voice activity detector), который решает является ли текущий анализируемый фрагмент сигнала речью или паузой. При наличии паузы информационный кадр может не передаваться в службу виртуального канала. Режим передачи паузных кадров следующий. На сеансовый уровень передается лишь каждый пятый кадр такого типа. Кроме того, при отсутствии речи для кодировки текущих спектральных параметров используется только 27 бит. На приемной стороне из виртуального канала в логический поступает либо информационный кадр (длиной 137 или 27 бит) либо флаг наличия паузы. На паузных кадрах вместо речевого синтезатора включается генератор комфортного шума, который восстанавливает спектральный состав паузного сигнала. Параметры генератора обновляются при получении паузного информационного кадра. Наличие информационного кадра длиной 137 бит включает речевой декодер, на выходе которого формируется 12-ти разрядный речевой сигнал. Для эхо-компенсатора этот сигнал является сигналом дальнего абонента, фильтрация которого дает составляющую электрического эха в передаваемом сигнале. В зависимости от типа цифро-аналогового преобразования сигнал может быть подвергнут дополнительной кодировке по А- либо µ- закону.
Анализ схемы сигнальной обработки и опыт разработки позволяют выделить следующие основные проблемы цифровой обработки сигналов в шлюзе.
При использовании двухпроводных абонентских линий актуальной остаётся задача эхокомпенсации, особенность которой состоит в том, что компенсировать необходимо два различных класса сигналов - речи и телефонной сигнализации. Очень важной является задача обнаружения и детектирования телефонной сигнализации. Её сложность состоит в том, что служебные сигналы могут перемешиваться с сигналами речи.
Ключевая задача построения кодеков речи подробно обсуждалось в разделе "Речевые кодеки для IP телефонии". С построением кодеков тесно связана задача синтеза VAD. Основная трудность состоит в правильном детектировании пауз речи на фоне достаточно интенсивного акустического шума (шум офиса, улицы, автомобиля и т.д.)
Реализация шлюзов для IP-телефонии
Все системы IP- телефонии условно можно разделить на базовых схемы: для пользователей персональных компьютеров и пользователей телефонной сети (осуществляющих связь через интернет без использования компьютера.)
Для первой схемы мы можем говорить о двух вариантах реализации: программном (когда все процедуры делает персональный компьютер со встроенной звуковой картой), и программно-аппаратном (когда в компьютер устанавливается специализированная DSP карта, выполняющая основные функции и разгружая тем самым компьютер для другой работы). Первый вариант нашел воплощение в значительном множестве программных продуктов, выпускаемых различными фирмами. Среди них наиболее распространен известный продукт Net Meeting фирмы Microsoft.
Второй вариант также в настоящее время достаточно широко распространен. Для второй схемы можно говорить только об аппаратно-программной реализации, когда в систему входит набор специализированных DSP карт или модулей, работающих, как правило, под управлением некоторого модуля центрального процессора (CPU). Первые продукты такого рода появились примерно 1.5 -2 года тому назад и были реализованы на основе плат фирмы Dialogic (мирового лидера в области компьютерной телефонии) и программного обеспечения, разработанного фирмой VocalTech (пионера в области Интернет-телефонии). Шлюз назывался VocalTech Gateway и коммерчески доступен в настоящее время. Подобный продукт V/IP был создан фирмой Micom и также представляет собой DSP плату в конструктиве IBM-PС, работающую под управлением специального ПО.
Подобные способы построения шлюзов достаточны удобны для офисных и возможно (в некоторых случаях) для корпоративных применений, но для крупных интернет-провайдеров и телекоммуникационных компаний, которым необходима установка многоканальных систем, такая реализация малопригодна из-за ненадежности функционирования и сложности обеспечения большого числа каналов. Задачи повышения надежности и обеспечения многоканальности должны решаться при разработке аппаратного обеспечения шлюза с учетом ограничения удельной стоимости на канал. Современное развитие элементной базы и стандартизации в области промышленных компьютеров (в том числе с конкретными особенностями для телекоммуникаций) позволяют достаточно эффективно решать эти задачи.
Основной компонент для реализации аппаратного обеспечения шлюзов - это цифровые процессоры обработки сигналов (DSP). В последние годы наблюдается необычайно бурный рост номенклатуры приборов, их производительности, расширение функциональных свойств чипов. Особо следует отметить появление DSP, специально предназначенных для многоканальной обработки, что существенно снижает удельную стоимость оборудования. Первым и наиболее мощным DSP этого класса является TMS320C6201 фирмы Texas Instruments с производительностью до 1600 MIPs, на котором возможна реализация 16 и более голосовых каналов через IP. В гонку за лидером включилась компания Analog Devices, анонсировавшая недавно свой 600 MIPs DSP с плавающей точкой ADSP21160, который несмотря на некоторый проигрыш по производительности имеет свои больший объем внутренней памяти и улучшенную архитектуру.
Что касается развития стандартизации в области промышленных платформ, то одной из наиболее популярных является платформа на базе шины Compact PCI, отличающаяся высокой скоростью (что необходимо для построения многоканальных систем), широкой распространенностью и невысокой стоимостью поддерживающего программного обеспечения (полный электрический и функциональный аналог шины PCI), мощной поддержкой производителей промышленных систем. Следует заметить, что для телекоммуникационных применений стандартизованы дополнительные шины, которые также находят активное применение. Первой такой шиной явилась шина SCbus, разработанная и предложенная фирмой Dialogic. И примерно год назад появилась шина CTbus, являющаяся развитием шины SNbus и совместимая с ней снизу.
Для всех упомянутых шин существуют специализированные микросхемы, необходимые для построения адаптеров шин, что значительно упрощает и удешевляет построение аппаратных средств.
Крупные компании - производители телекоммуникационного оборудования такие как Siemens, Lucent, Motorola, Nokia активно осваивают этот перспективный сегмент рынка IP-телефонии. Как правило, каждый крупный производитель, предлагает свою собственную архитектуру, свою внутреннюю шину, свой способ управления и контроля, свои конструктивы. Мелкие и средние компании также получили высокие шансы для конкуренции с гигантами прежде всего в связи с бурным развитием стандартизации в области промышленных компьютеров, доступностью и сравнительно недорогой стоимостью различных комплектующих (начиная от корпуса и кончая любыми компонентами) при обеспечении всех необходимых свойств промышленных систем.
Задачи, возникающие при реализации шлюзов, во многом аналогичны задачам, решаемым при создании современного станционного оборудования. Вместе с тем, имеется специфика, определяемая широким применением DSP (до десятка и более на одной плате) и особенностями используемых алгоритмов.
Если на плате шлюза совместно размещаются аналоговая и цифровая части, возникает задача электромагнитной совместимости. Если же аналоговая и цифровая части разнесены - задача их сопряжения.
При размещении на одной плате большого числа мощных DSP, например TMS320C6201, возникают серьёзные проблемы с большим энергопотреблением.
При конструировании шлюза важно обеспечить согласование алгоритма с аппаратной частью. Дело в том, что аппаратная часть должна рационально обслуживать алгоритм работы шлюза. Это при экономном использовании аппаратуры не всегда легко (возможно) сделать. Вместе с тем, допустимые модификации алгоритма (распараллеливание вычислений, оптимизация управления ресурсами, рациональный порядок вычислений и пр.) могут оказать заметное влияние на структуру аппаратной реализации и, в целом, обеспечить лучшее решение.
При организации телефонных переговоров по вычислительным сетям необходимо передавать два типа информации: командную и речевую. К командной информации относятся сигналы вызова, разъединения, а также другие служебные сообщения.
Краеугольный камень сети ИНТЕРНЕТ - Internet Protocol (IP). Это протокол сетевого уровня, который обеспечивает маршрутизацию пакетов в сети. Он, однако, не гарантирует надежную доставку пакетов. Таким образом, пакеты могут искажаться, задерживаться, передаваться по различным маршрутам (а значит иметь различное время передачи) и т. д. На основе IP работают протоколы транспортного уровня Transport Control Protocol (TCP) и User Datagram Protocol (UDP).
Основное требование к передаче командной информации - отсутствие ошибок передачи. В результате необходимо использовать достоверный протокол доставки сообщений. Обычно, в качестве такого протокола используется TCP, обеспечивающий гарантированную доставку сообщений. Время доставки сообщений также играет немаловажную роль в этом случае. К сожалению, этот параметр является нестабильным, т. к. при появлении ошибок передачи сообщение передается повторно. Передача повторяется до тех пор пока сообщение не будет доставлено успешно. Таким образом, длительность служебных процедур может бесконтрольно увеличиваться, что недопустимо, например, для этапа установления соединения, а также некоторых процедур связанных с передачей по сети телефонной сигнализации. Открытой проблемой в этой области является создание достоверного механизма передачи, который не только гарантирует безошибочную доставку информации, но также минимизирует время доставки при появлении ошибок передачи.
При передаче речевой информации проблема времени доставки пакетов по сети становиться основной. Это вызвано необходимостью поддерживать общение абонентов в реальном масштабе времени, для чего задержки не должны превышать 250 - 300 мс. В таком режиме использование повторных передач недопустимо, и следовательно, для передачи речевых пакетов приходится использовать недостоверные транспортные протоколы, например, UDP. При обнаружении ошибки передачи факт ошибки фиксируется, но повторной передачи для ее устранения не производится. Пакеты, передаваемые по протоколу UDP могут теряться. В одних случаях это может быть связано со сбоями оборудования. В других - с тем, что "время жизни" пакета истекло, и он был уничтожен на одном из маршрутизаторов. При потерях пакетов повторные передачи также не организуются. В процессе передачи возможны перестановки пакетов в потоке, а также искажения речевых пакетов. Последнее однако происходит крайне редко.
Перед поступлением речевого потока на декодер он должен быть восстановлен. Для этого используется протокол реального времени. В заголовке данного протокола передаются, в частности, временная метка и номер пакета. Эти параметры позволяют определить не только порядок пакетов в потоке, но и момент декодирования каждого пакета, т. е. позволяют восстановить поток. Наиболее распространенный протокол реального времени - Real Time Protocol (RTP), рекомендованный к использованию в стандарте на построение систем реального времени H.323.
Искажения потока пакетов связаны с загруженностью сети. При отсутствии перегрузок искажения минимальны, а часто отсутствуют. Поток речевых пакетов может значительно загружать сеть, особенно, в случае многоканальных систем. Это происходит из-за высокой интенсивности потока (кадры небольшого размера передаются через малые промежутки времени 20 байт/ 30 мс) и большого объема передаваемой служебной информации. Зная размеры заголовков сетевых протоколов (IP - 20 байт, UDP - 8 байт, RTP - 12 байт), легко вычислить общий объем заголовка речевого пакета - 40 байт. Это в 2 раза превышает размер самого пакета. Передача такого объема служебной информации неприемлема, особенно, при построении многоканальных систем. Таким образом, необходимо искать способы уменьшения количества служебной информации, передаваемой по сети. Существует два возможных варианта решения этой проблемы. Первый предполагает создание специальных транспортных протоколов для IP-телефонии, которые могли бы уменьшить заголовок протокола транспортного уровня. Второй вариант - мультеплексирование каналов в многоканальных системах. В этом случае речевые пакеты от разных каналов передаются под одним сетевым заголовком. Такое решение не только уменьшает количество передаваемой служебной информации, но и снижает интенсивность потока.
Основной задачей IP-телефонии является приближение качества услуг к телефонному сервису. С точки зрения используемых сетевых протоколов это означает необходимость создания транспортных механизмов, минимизирующих время доставки по сети, как командной, так и речевой информации.
Технология Internet-телефонии основана на использовании для передачи голоса сетей, изначально рассчитанных на передачу данных. При этом голосовой сигнал оцифровывается, разделяется на пакеты, которые обычно применяются при работе с данными, и в таком виде пересылается по сети. На противоположном конце канала связи пакеты собираются, голосовой сигнал восстанавливается, и таким образом обеспечиваются телефонные переговоры между двумя устройствами, подключенными к сети передачи данных.
Так выглядит идея в самых общих чертах. Реализовать ее можно на разных уровнях стека протоколов ISO/OSI. Для передачи голоса по информационным сетям на втором уровне стека протоколов обычно используются сети либо ATM, либо frame relay, для подключения к которым необходима специальная аппаратура. Установка такой технологии требует весьма значительных затрат, поэтому это решение рассчитано на крупные организации, в первую очередь на те, где уже имеется подключение к соответствующей сети - тогда добавить передачу голоса можно по сравнительно невысокой цене; часто для этого нужно просто вставить дополнительный модуль в соответствующее устройство.
Internet-телефония осуществляется на следующем, сетевом, уровне стека протоколов. В ней для передачи цифровых пакетов, несущих голосовую информацию, используется имеющаяся в настоящее время практически в каждой организации всемирная сеть Internet. Для подключения к Internet-телефонии нужно просто обзавестись дополнительным оборудованием, обеспечивающим перевод голоса в цифровую форму (в простейшем случае подойдет и обычный мультимедийный компьютер), и поставить соответствующее программное обеспечение. При этом конкретное технологическое решение, реализуемое для передачи данных через Сеть, никакой роли не играет (например это может быть IP поверх frame relay, или X.25, или что-то еще).
Впрочем, в таком простом виде описываемая технология больше годится для использования в качестве игрушки, чем для различных бизнес-приложений. Конечно, очень удобно поставить на своем компьютере модем с большой пропускной способностью и установить нужную программу, а потом свистнуть своему приятелю где-нибудь в Чикаго, чтобы поставил у себя такую же конфигурацию. И - разговаривай сколько влезет. Влезет, надо сказать, не слишком много,
потому что довольно скоро одному из абонентов (или обоим) надоест, что ответа на вопрос приходится дожидаться довольно долго, что слышно не очень хорошо, и часто приходится переспрашивать, и т. д.С бизнес-приложениями Internet-телефонии все обстоит не так просто. Во-первых, перевод голосового трафика на Internet резко повышает требования к пропускной способности канала связи, используемого для подключения организации к Сети. Во-вторых, и это на сегодняшний день главное, качество связи, обеспечиваемое Inte
rnet-телефонией, довольно низкое. То, что приемлемо при болтовне между двумя приятелями (которым к тому же нравится сам процесс передачи голоса через Сеть), не слишком годится для корпоративных применений, не говоря уже о предоставлении коммерческих услуг на базе этой технологии. Наконец, в-третьих, между телефонной сетью и IP-сетью имеется одно существенное различие. Телефонные номера, как правило, присваиваются абонентам раз и навсегда, поэтому для этой сети можно составить список абонентов с указанием присвоенных им номеров. Что же касается IP-адресов, то они часто присваиваются в динамическом режиме, только на текущий сеанс. Поэтому Internet-телефонную книгу составить затруднительно.Основные усилия разработчиков систем Internet-телефонии сосредоточены сейчас на решении второй проблемы. Атака идет с нескольких направлений. Во-первых, голос после оцифровки следует сжимать. Чем сильнее он будет сжат, тем меньше пакетов понадобится для передачи одного и того же речевого фрагмента и, соответственно, тем меньше вероятность искажений и задержек, связанных с разборкой-сборкой голосового потока в процессе передачи. Тут есть и противоположная тенденция - чем сильнее сжимается голос, тем значительнее искажения, вносимые в сигнал самим процессом сжатия-восстановления. Во-вторых, предпринимаются попытки ввести в IP-сетях некое подобие понятия уровня обслуживания (quality of service, QoS), имеющегося в сетях ATM.
Для обеспечения управления задержками в доставке пакетов данных по назначению был разработан ряд протоколов. В частности, протокол RTP (Real-Time Transport Protocol) позволяет снабжать пакеты данных временными метками, обеспечивающими синхронизацию потоков данных. Протокол RTP описывается в документе RFC1889. Еще один протокол, носящий название RTCP (Real-Time
Transport Control Protocol), позволяет приложению реагировать на изменение состояния сети. В частности, получив информацию о снижении эффективной пропускной способности сети, приложение может повысить степень компрессии голоса, пожертвовав его качеством. Как только обстановка в Сети разрядится, степень компрессии голоса можно будет понизить. Наконец, разрабатываемый в настоящее время протокол RSVP (Resource Reservation Protocol) позволит приложениям динамически резервировать определенную долю полосы пропускания для передачи потока голосовой информации. Реализация RSVP будет означать появление в Internet некоего аналога QoS.Еще одна проблема, которую приходится решать производителям систем Internet-телефонии, - отсутствие единого стандарта на программы, обеспечивающие связь. В настоящее время связь через IP-сеть возможна только в том случае, если с обеих сторон устанавливаемого соединения используются одинаковые системы. Поэтому весьма позитивным фактом можно считать то, что в ноябре прошлого года ведущие компании образовали комитет под названием Voice over IP Forum. Этот комитет, учредителями которого стали фирмы Cisco Systems, Dialogic, VocalTec, нацелен на разработку общего стандарта, который мог бы обеспечить интероперабельность систем передачи голоса через Internet и другие IP-сети. В качестве основы нового документа был принят стандарт H.323, в котором описывается передача мультимедиа между локальными сетями и телефонными системами (например ISDN).
Стандарты являются критическим фактором для мира IP-телефонии. Одна из наиболее важных областей стандартизации - протокол обмена сообщениями в IP-телефонии.
Ранние решения IP-телефонии использовали для связи друг с другом закрытые протоколы. Оба участника беседы должны были иметь аналогичные продукты. Intel и Microsoft возглавили направление на разработку стандартов на основе H.323, рекомендованного International Telecommunications Union (ITU). Этот стандарт формулирует технические требования для передачи аудио- и видеоданных по сетям передачи данных. H.323 включает в себя:
Стандарты на видео кодер/декодеры;
Стандарты на голосовые кодер/декодеры;
Стандарты на общедоступные приложения;
Стандарты на управление вызовами;
Стандарты на управление системой.
Стандарты на видео кодер-декодеры не требуются для обработки телефонных звонков, но существуют внутри той же системы стандартов.
Технические требования к голосовым кодерам включают следующие:
малая полоса пропускания (8 kbit/s или меньше);
высокое качество голоса;
небольшие задержки;
возможность реконструкции потерянных пакетов.
При передаче в режиме реального времени до 30% пакетов могут потеряться или опоздать (что в режиме реального времени одно и то же). Хорошее приложение IP-телефонии должно возместить нехватку пакетов, восстановив потерянные данные. Сам алгоритм кодировки также оказывает влияние на восстановление данных. Сложные алгоритмы увеличивают стоимость необходимого оборудования. Наиболее популярным алгоритмом кодирования является G.723.1.
Еще одна особенность состоит в том, что системы IP-телефонии должны иметь возможность поддерживать разные кодеры и добавлять новые по необходимости. H.323 был первоначально разработан для локальных вычислительных сетей, так что переменная ширина полосы частот и время задержки Интернет уменьшают полезность некоторых элементов H.323. По умолчанию голосовым кодер-декодером в стандарте H.323 является G.711. Однако ширина полосы частот в 64 kbps, требуемая в G.711, неприемлема при использовании в Интернет, т.к. большинство пользователей Интернета имеет канал заведомо меньшей ширины. Но даже в этом случае многое из стандарта является полезным.
Кроме G.711 стандарт H.323 определяет звуковые кодер-декодеры G.722, G.723,G.723.1, MPEG1, G.728, и G.729. Кодеры с низкой шириной полосы частот - G.729 в 8 kbps и G.723 в 5.3/6.3 kbps - вполне подходят для использования в Интернет. В частности, G.723 является одним из нескольких "стандартных" кодеров для IP-телефонии, особенно после того, как Intel, Microsoft и Netscape объявили о поддержке этого кодера. Основной недостаток G.723 состоит в том, что он требует весьма больших ресурсов процессора. Intel, например, определяет 100 MHz Pentium-процессор как минимальный для использования в Интернет-телефонии. H.323 — основополагающий стандарт, где описывается, каким образом чувствительный к задержке трафик, в частности голос и видео, получает приоритет в локальных и глобальных сетях. Он состоит из ряда рекомендаций по смежным техническим вопросам, таким, как качество речи, контроль вызовов и спецификации привратников. (Привратники — это приложения, чья функция состоит в преобразовании IP-адресов, контроле доступа и управлении пропускной способностью для других компонентов H.323, включая шлюзы и конечные точки.) Ратифицированная вторая версия H.323 ликвидирует некоторые недостатки первой версии (принятой в 1996 году). Так она предусматривает более жесткие меры защиты, более быструю процедуру прохождения вызова и расширенные услуги типа перевода вызова и конференций. Однако она пока еще не была широко реализована в коммерческих продуктах.
Никто из более десятка крупнейших производителей и отраслевых экспертов не выразил сомнений по поводу жизнеспособности и практичности H.323. Но, как это часто случается со стандартами, реализации производителей отличаются настолько, что их продукты часто оказываются неспособны взаимодействовать с продуктами их конкурентов. "Шлюз Cisco 5300 говорит на диалекте Cisco 5300 языка H.323, в то время как Lucent ITS-SP — на своем собственном облегченном диалекте, — констатирует Мартин Кэролл из Lucent Technologies в техническом описании PacketStar IP Services Platform, выпущенной осенью 1998 года программной платформе для разрешения подобных конфликтов. — Как результат, сервис-провайдер со шлюзами Cisco 5300 в США и шлюзами ITS-SP в Европе не может маршрутизировать трансатлантические звонки по Internet".
Проблема отсутствия совместимости решается простейшим способом — посредством установки шлюзов одного производителя. Однако совместимость шлюзов улучшается. В сентябре 1998 г. VocalTec Communications и Lucent на совместной пресс-конференции объявили об успешном завершении тестирования совместимости своих устройств. Кроме того, все большее число производителей присоединяется к программе тестирования на совместимость Форума "Голос по IP" (Voice over IP Forum, VOIP Forum) Международного консорциума мультимедийных телеконференций (International Multimedia Teleconferencing Consortium, IMTC).
Конечно, разнообразие существующих или разрабатываемых стандартов не исчерпывается H.323. Система сигнализации №7, конкурирующая в некоторых отношениях с H.323, продвигается операторами связи, потому что она представляет собой более развитую технологию контроля вызовов и поддерживает технологии беспроводной связи. Однако большинство опрошенных производителей заявляют, что они собираются поддерживать оба стандарта в своих новых продуктах.