Оборудование IP-телефонии

         

всех цифровых кодеков речевых сигналов,


Кодек G.711 - “дедушка” всех цифровых кодеков речевых сигналов, был одобрен ITU-T в 1965 году. Применяемый в нем способ преобразования аналогового сигнала в цифровой с использованием полулогарифмической шкалы был достаточно подробно описан выше. Типичная оценка MOS составляет 4.2. В первую очередь .отметим, что, как и для ТфОП, минимально необходимым для оборудования VolP является ИКМ-кодирование G.711. Это означает, что любое устройство VolP должно поддерживать этот тип кодирования.

3.3.2 Кодек G.723.1

Рекомендация G.723.1 утверждена ITU-T в ноябре 1995 года. Форум IMTC выбрал кодек G.723.1 как базовый для приложений IP-телефонии.

Кодек G.723.1 производит кадры длительностью 30 мс с продолжительностью предварительного анализа 7.5 мс. Предусмотрено два режима работы: 6.3 Кбит/с (кадр имеет размер 189 битов, дополненных до 24 байтов) и 5.3 Кбит/с (кадр имеет размер 158 битов, дополненных до 20 байтов). Режим работы может меняться динамически от кадра к кадру. Оба режима обязательны для реализации.

Оценка MOS составляет 3.9 в режиме 6.3 Кбит/с и 3.7 в режиме 5.3 Кбит/с.

Кодек специфицирован на основе операций как с плавающей точкой, так и с фиксированной точкой в виде кода на языке С. Реализация кодека на процессоре с фиксированной точкой требует производительности около 16 MIPS.

Кодек G.723.1 имеет детектор речевой активности и обеспечивает генерацию комфортного шума на удаленном конце в период молчания. Эти функции специфицированы в приложении A (Annex А) к рекомендации G.723.1. Параметры фонового шума кодируются очень маленькими кадрами размером 4 байта. Если параметры шума не меняются существенно, передача полностью прекращается.

3.3.3 Кодек G.726

Алгоритм кодирования АДИКМ (рекомендация ITU-TG.726, принятая в 1990 г.) описан выше. Он обеспечивает кодирование цифрового потока G.711 со скоростью 40, 32, 24 или 16 Кбит/с, гарантируя оценки MOS на уровне 4.3 (32 Кбит/с), что часто принимается за эталон уровня качества телефонной связи (toll quality). В приложениях IP-телефонии этот кодек практически не используется, так как он не обеспечивает достаточной устойчивости к потерям информации (см.
выше).

3.3.4 Кодек G.728

Кодек G.728 использует оригинальную технологию с малой задержкой LD-CELP ( low delay code excited linear prediction) и гарантирует оценки MOS, аналогичные АДИКМ G.726 при скорости передачи 16 Кбит/с. Данный кодек специально разрабатывался как более совершенная замена АДИКМ для оборудования уплотнения телефонных каналов, при этом было необходимо обеспечить очень малую величину задержки (менее 5 мс), чтобы исключить необходимость применения эхокомпенсаторов Это требование было успешно выполнено учеными Bell JLabs в 1992 году: кодер имеет длительность кадра только 0.625 мс. Реально задержка может достигать 2.5 мс, так как декодер должен поддерживать синхронизацию в рамках структуры из четырех кадров.

Недостатком алгоритма является высокая сложность - около 20 MIPS для кодера и 13 MIPS для декодера - и относительно высокая чувствительность к потерям кадров.

3.3.5 Кодек G.729



Кодек G.729 очень популярен в приложениях передачи речи по сетям Frame Relay. Он использует технологию CS-ACELP (Conjugate Structure, Algebraic Code Excited Linear Prediction). Кодек использует кадр длительностью 10 мс и обеспечивает скорость передачи 8 Кбит/с. Для кодера необходим предварительный анализ сигнала продолжительностью 5 мс.

Существуют два варианта кодека:

• G.729 (одобрен ITU-T в декабре 1996), требующий около 20 MIPS для кодера и 3 MIPS для декодера.

• Упрощенный вариант G.729A (одобрен ITU-T в ноябре 1995), требующий около 10.5 MIPS для реализации кодера и около 2 MIPS для декодера.

В спецификациях G.729 определены алгоритмы VAD, CNG и DTX. В периоды молчания кодер передает 15-битовые кадры с информацией о фоновом шуме, если только шумовая обстановка изменяется.

3.4 Кодеки, стандартизованные ETSI

В рамках деятельности европейского института ETSI стандартизованы узкополосные кодеки для применения в системах мобильной связи (GSM).

Спецификации кодека GSM Full Rate, известного также как GSM 06.10, утверждены в 1987г. Это первый и, скорее всего, наиболее известный из узкополосных кодеков, применяемый в миллионах мобильных телефонов по всему миру.


Обеспечивает хорошее качество и устойчивую работу в условиях фонового шума (оценка MOS порядка 3.7 в условиях без шума). Кодируются кадры длительностью 20 мс, образуя цифровой поток со скоростью 13 Кбит/с. Кодек не требует высокой производительности процессора - необходимо только 4.5 MIPS для дуплексной реализации. Кодек очень важен для некоммерческих проектов в области IP-телефонии, особенно -для проектов, связанных с открытым распространением исходных текстов ПО (open source), благодаря возможности бесплатного лицензирования. Такие проекты сегодня могут использовать только кодеки GSM FR и G.711, а также АДИКМ.

Существуют также спецификации кодеков GSM Half Rate, принятые в 1994 году, и GSM Enhanced Full Rate, принятые в 1995 году. Характеристики этих кодеков превосходят характеристики исходного варианта, описанного выше, однако алгоритмы требуют большей производительности процессора (до 30 MIPS). В приложениях IP-телефонии они, по разным причинам, распространения пока не получили.

Рассмотрение кодеков было бы неполным, если бы, наряду со специфицированными ITU-T и ETSI, не были упомянуты и т.н. нестандартные кодеки.

Сегодня в приложениях VolP, кроме кодеков, прошедших процедуры международной стандартизации в ITU-T и ETSI, в продуктах ряда фирм-производителей применяются также нестандартные внутрифирменные алгоритмы. Такие алгоритмы часто лицензируются для использования в продуктах других компаний. В качестве примеров можно назвать такие кодеки, как Lucent/Elemedia SX7003P, имеющий очень хорошие характеристики при умеренной вычислительной сложности, и Voxware RT24, который предусматривает сверхнизкую (2.4 Кбит/с) скорость передачи информации при сохранении достаточно хорошего качества речи (оценка MOS около 3.2).

3.5 Передача сигналов DTMF

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



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

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

Существуют два основных метода передачи сигналов DTMF по сетям IP-телефонии.

• Обязательный метод. Специальное сообщение протокола Н.245 (Userlnputlndication) может содержать символы цифр и “*”, “#”. В данном случае используется надежное TCP-соединение, так что информация не может быть потеряна. Однако из-за особенностей TCP могут иметь место значительные задержки;

• Нестандартный метод, предложенный Форумом VolP. Он может быть применен в терминалах H.323v2 при использовании процедуры fastStart и отсутствии канала Н.245. Для передачи сигналов DTMF открывается специальная RTP-сессия, в которой передаются кодированные значения принятых цифр, а также данные об амплитуде и длительности сигналов. Может быть использована та же сессия, что и для речи, но со специальным типом полезной нагрузки. Использование RTP позволяет привязать DTMF- сигналы к реальному времени, что является важным преимуществом данного метода.

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



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

3.6 Передача факсимильной информации

В становлении IP-телефонии, наряду с телефоном, значительную роль сыграл телефакс. Идею нынешнего телефакса (от греческого “теле” - далеко и латинского “facsimale” - делай подобное) предложил англичанин Александр Байн в 1843 году, то есть за 33 года до появления телефона. В такой же последовательности (начиная с факсов) стали практически использоваться преимущества IP-телефонии с ее весьма низкими тарифами для передачи информации на дальние расстояния. Значительный экономический эффект от такого применения обусловлен чрезвычайно высокой распространенностью факс-машин; в мире их насчитывается много миллионов.

Говоря о распространенности факс-машин, отметим, что имеются в виду аппараты группы 3, специфицированные в рекомендации ITU-TT.30. Именно появление этой технологии и открыло дорогу широкому внедрению услуг факсимильной связи. Оказалось, что функции, реализованные в факсах группы 3, вполне устраивают пользователей, а стандарт практически не требует развития. Об этом свидетельствует тот факт, что более современная технология, т.н. факс группы 4, не получила никакого распространения и практически забыта. На наш взгляд, неуспех этой технологии можно объяснить тем, что, во-первых, все ее потенциальные преимущества (передача цветных изображений, высокая скорость обмена и т.д.) проще и дешевле реализуются на базе компьютерных технологий (обмен файлами по электронной почте, например), а во-вторых, сеть ISDN, на которую были ориентированы факсы группы 4, не получила глобального распространения.

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


Пересылка факсов через Интернет не является чем-то новым. Очень многие компании предлагают услуги факс-серверов отложенной доставки (Store & Forward). Пользователь отправляет факс на специальный сервер по заранее установленному телефонному номеру, вводя вслед за этим телефонный номер пункта назначения. Сервер, имитирующий работу факса принимающей стороны, принимает сообщение, преобразует его в набор графических файлов и отправляет данные файлы через Интернет к другому серверу, который находится ближе к месту назначения, например, в другой стране. Сервер-получатель организует связь с пунктом назначения по полученному им телефонному номеру и передает факсимильное сообщение адресату, уведомляя отправителя об успешной (или неуспешной) передаче. Технология Store & Forward Fax описана в рекомендации Т.37.

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

Единственным полноценным решением этих проблем является организация передачи факсов по IP-сетям в реальном времени и так, чтобы пользователи двух факсимильных аппаратов не подозревали о том, что связь между их терминалами осуществляется с использованием сети с коммутацией пакетов. К счастью, спецификации протокола передачи факсимильной информации группы 3 позволяют реализовать такое решение. Результатом усилий ITU-T в данном направлении стала рекомендация Т.38, определяющая процедуры взаимодействия факсимильных терминалов группы 3 в реальном времени с использованием IP-сетей.


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

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

Рекомендация Т.38 предусматривает использование особого протокола IFP, цель которого - перенос сообщений между шлюзами и/или компьютерами. Сообщения IFP, в свою очередь, могут передаваться внутри TCP-соединения или с использованием UDP, причем в последнем случае предусматривается введение информационной избыточности, обеспечивающей восстановление одиночных потерянных пакетов. Использование протокола Т.38 закреплено в рамках рекомендации Н.323. Обязательным условием является поддержка протокола TCP для переноса информации IFP, а использование протокола UDP является лишь возможным вариантом. Информация IFP передается по двум логическим каналам (от отправителя к получателю и в обратном направлении).


Когда в качестве транспорта применяется протокол TCP, существует два возможных варианта: передавать сообщения IFP, используя их Туннелирование в канале H.225.0/Q.931, или использовать для этого выделенное соединение.

Несмотря на то, что согласно ITU-T реализация на основе протокола TCP является обязательной, в шлюзах большинства крупных производителей реализован транспорт IFP поверх протокола UDP. Отчасти это можно объяснить тем, что при таком решении механизм открытия логических каналов выглядит совершенно аналогично механизму, используемому для передачи речевой информации. Кроме того, протокол Т.38 обычно реализуется на основе либо тех же DSP, что и речевые кодеки, либо специализированного процессора, обеспечивающего пересылку речевой информации, а для таких процессоров реализация протокола TCP слишком тяжеловесна, и ее стараются избежать. Как бы то ни было, реализации Т.38 на базе протокола UDP широко эксплуатируются и доказали работоспособность такого решения. Шлюз IP-телефонии семейства оборудования Протей-IP использует транспорт UDP, а вариант с TCP может быть реализован, если на рынке появится в достаточном количестве оборудование, использующее этот подход.

3.7 О реализации “стандартных” алгоритмов

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

алгоритмы кодирования речи стандартизованы и отлично документированы, более того, на рынке доступны весьма эффективные их реализации для всех популярных DSP-платформ. С другой стороны, в оборудовании IP-телефонии должны быть реализованы многие другие функции, способ реализации которых не является объектом стандартизации, а представляет собой “know-how” разработчиков.

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


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

К этому остается добавить необходимость передачи факсимильной информации в реальном времени с автоматическим распознаванием сигналов факсимильных аппаратов и передачу DTMF-сигна-лов с корректным их восстановлением в приемнике.

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


Содержание раздела