IP-телефония и ТФОП: сосуществование или конфронтация?

Cо времен изобретения телефонного аппарата А.Г.Беллом (США) в 1876г. телефония практически не испытывала конкуренции со стороны других технологий. Первую угрозу своему привилегированному положению телефония почувствовала в 70-е годы, когда начала обсуждаться идея передачи речи по сетям с коммутацией пакетов и даже реализовываться в ряде пилотных проектов. Однако, в силу ограниченных возможностей существовавших тогда технологий, реализация этой задачи не была доведена до коммерческого применения. В начале 90-х годов, когда появились первые компьютеры, оснащенные средствами мультимедиа, и необыкновенную популярность и распространение получила сеть Интернет, стало возможным и актуальным вновь вернуться к решению этой задачи.

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

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

Что такое IP-телефония?

Как уже было сказано, развитие IP-телефонии началось с обеспечения возможности общения между пользователями сети Интернет.

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

Второй сценарий предусматривает взаимодействие компьютера, подключенного к сети Интернет, и телефонного аппарата ТФОП.

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

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

При передаче речевой информации через сеть Интернет должны быть решены две задачи:

• преобразование речевой информации в поток данных;
• управление этим потоком.

Рис. 1. Стандарты для кодирования аудиосигналов

В настоящий момент времени отсутствуют международные рекомендации или стандарты, разработанные специально для IP-телефонии. В тоже время для обеспечения совместимости оконечного оборудования и шлюзов различных поставщиков в качестве базового стандарта используется Рекомендация МСЭ-Т H.323, утвержденная в феврале 1998 г. Она регламентирует характеристики системы мультимедиа для сети с коммутацией пакетов. Рекомендация определяет набор стандартов для кодирования аудио и видео сигналов и протоколов управления каналами передачи (рис. 1).

Согласно Рекомендации H.323 для преобразования речевой информации могут применяться алгоритмы, определенные в Рекомендациях МСЭ-Т: G.711, G.722, G.723, G.728 и G.729.

Рекомендации МСЭ-Т G.711 и G.722 определяют только способ аналого-цифрового преобразования без сжатия.

Рекомендация МСЭ-Т G.722 предназначена для кодирования спектра частот до 7 кГц, который превышает ширину канала ТЧ. Поэтому она не может применяться в сценариях, предусматривающих взаимодействие компьютера с телефонным аппаратом.

Для сжатия речи Рекомендация МСЭ-Т H.323 предусматривает использование нескольких алгоритмов кодирования речевой информации. Они определены в Рекомендациях МСЭ-Т: G.723, G.728, G.729.

Кодирование речевой информации согласно Рекомендации МСЭ-Т G.723 обеспечивает преобразование речевого потока 64 кбит/c в поток 6,3 или 5,3 кбит/c.

Кодирование речевой информации согласно Рекомендации МСЭ-Т G.728 обеспечивает преобразование речевого потока 64 кбит/c в поток 16 кбит/c и менее с малым временем задержки.

Кодирование речевой информации согласно Рекомендации МСЭ-Т G.729 обеспечивает преобразование речевого потока 64 кбит/c в поток 8 кбит/c.

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

Восприятие речи человеком очень чувствительно к задержкам, причем как к ее величине, так и колебаниям. Для телефонной связи задержка не должна превышать 150 мс при работе по наземным линиям связи и 250 мс при использовании спутниковых каналов.

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

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

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

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

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

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

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

Существует два подхода.

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

Для резервирования полосы пропускания в сети IP может использоваться метод WFQ (Weighted Fair Queuing) или протокол RSVP (Resource Reservation Protocol), разрабатываемый группой перспективных разработок Интернет IETF (Internet Engineering Task Force).

Метод WFQ позволяет для каждого вида трафика выделять определенную часть полосы пропускания. Оператор через систему административного управления может задать количество очередей (до 10 очередей для передачи данных и одну очередь для системных сообщений). В случае, если одна очередь не использует полностью выделенную ей полосу пропускания, то свободный резерв полосы пропускания может задействоваться для передачи информации из следующей очереди. Этот метод позволяет гибко использовать ресурсы сети. Например, если для очереди с речевой информацией зарезервировано 50% пропускной способности, а используется только 30%, то следующая очередь получит в свое распоряжение дополнительно 20% до тех пор, пока эта пропускная способность снова не потребуются очереди с речевой информацией. Метод WFQ реализован в оборудовании фирмы Cisco.

Протокол RSVP предназначен только для резервирования части пропускной способности.

Используя RSVP, отправитель периодически информирует получателя о свободном количестве ресурсов сообщением RSVP Path (рис. 2).

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

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

Рис. 2. Применение протокола RSVP

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

Другой подход предусматривает построение магистральной транспортной сети Интернет на основе технологии Frame Relay или АТМ (рис. 3). В этом случае пограничные узлы IP взаимодействуют друг с другом через виртуальные соединения сети Frame Relay или ATM, для которых обеспечиваются параметры трафика и качества обслуживания, такие как скорость передачи, время задержки, время отклонения от задержки и т.д. Использование Frame Relay или АТМ позволяет отказаться от применения транзитных маршрутизаторов IP. При этом возможно более эффективное использование полосы пропускания за счет установления соединения для каждого телефонного разговора.

Рис. 3. Использование в транспортной сети Интернет технологий АТМ и Frame Relay

Стандартизация

МСЭ-Т начал работу по вопросам исследования и стандартизации взаимодействия между сетями связи и сетями, работающими по протоколу IP, в рамках работ по созданию Глобальной информационной инфраструктуры GII (Global Informational Infrastructure) только в 1998 году. Предполагается, что работа будет проводиться в тесном сотрудничестве с IETF.

С целью ускорения разработки промышленных стандартов ведущие производители оборудования и программного обеспечения IP-телефонии в 1996 г. объединились в неформальную организацию Форум Voice Over IP (VOIP Forum). Инициатором создания форума стали компании Cisco и VocalTec. В Форум вошли такие компании, как Dialogic, 3Com, Creative Labs, Micom Communications, Microsoft, Nortel, Vienna Systems, U.S.Robotics и другие.

Форум предлагает для аналого-цифрового преобразования речи использовать алгоритмы кодирования, определенные в Рекомендациях МСЭ-Т G.723 и G.729. Для поддержки качества передачи речи в сетях IP Форум рекомендует использовать протокол RSVP, а для управления очередями — метод WFQ.

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

Приложения IP-телефонии

На сегодняшний день IP-телефония представлена тремя типовыми сценариями:

• "компьютер–компьютер";
• "компьютер–телефон";
• "телефон–телефон".

Сценарий "компьютер–компьютер" реализуется на базе бытовых компьютеров, оснащенных средствами мультимедиа и подключенных к сети Интернет. Наиболее распространенным программным обеспечением является пакет MicroSoft NetMeeting.

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

Рис. 4. Сценарий "компьютер–компьютер"

Сценарий "компьютер–телефон" находит применение в различного рода справочных и информационных службах Интернет, например, в службах технической поддержки (рис. 5). Данный сценарий реализуется на оборудовании компании, предоставляющей справочную информацию. Пользователь, подключившийся к серверу WWW (World Wide Web) какой-либо компании, имеет возможность обратиться к оператору справочной службы. Речевое соединение между пользователем и оператором будет установлено, когда пользователь выберет соответствующий пункт меню на странице WEB.

Рис. 5. Сценарий "компьютер–телефон"

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

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

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

Привлекательность этого сценария для пользователя заключается в значительно более низкой стоимости телефонных переговоров по сравнению с обычной междугородной или международной телефонной связью. Например, в США некоторые поставщики услуг предоставляют междугородную телефонную связь по тарифам от 3 до 7 центов за минуту, в то время как AT&T требует около 3 долларов за минуту.

Рис. 6. Сценарий "телефон-телефон"

Поскольку сегодня транспортные возможности сети Интернет не способны обеспечить качество IP-телефонии, которое соответствовало бы даже таким низким тарифам, то поставщики услуг для соединения принадлежащего им шлюзового оборудования используют выделенные каналы. При этом для передачи речи часто используются не протоколы IP, а технологии типа "Voice over Frame Relay" или "Voice over ATM", применение которых позволяет повысить качество передачи речи и одновременно установить низкие тарифы на услуги телефонной связи. Поэтому передачу речи с использованием IP необходимо поставить на одну ступень с такими технологиями, как "Voice over Frame Relay", "Voice over ATM", "Voice over X.25", статистического мультиплексирования и целесообразно рассматривать как технологию вторичного уплотнения каналов.

Регулирование

Рост популярности приложения "телефон-телефон" вызывает негативную реакцию со стороны операторов дальней связи. Она вызвана двумя причинами.

Первая причина заключается в том, что IP-телефония вызывает естественный отток нагрузки у операторов дальней связи, что ведет к сокращению их доходов. Например, по прогнозам зарубежных экспертов, ожидается, что AT&T к 2001 г. может потерять от $620 до $950 млн.

Вторая причина заключается в том, что при внедрении IP-телефонии увеличивается продолжительность разговора. По данным Федеральной комиссии по связи FCC (Federal Communications Commission) США, обычный телефонный разговор длится 5–7 минут, а продолжительность разговора с использованием IP-телефонии составляет от 17 до 21 минут.

По этим причинам Ассоциация американских операторов сетей связи America's Carriers Telecommunication Association (АСТА) США, в которую входят такие известные компании как Sprint и MCI, неоднократно обращалась с жалобами в FCC. Ассоциация АСТА требовала применения для компаний, разрабатывающих продукты и предоставляющих услуги IP-телефонии, тех же регулирующих норм и правил, что и для операторов телефонных сетей. Члены АСТА в своих жалобах указывают на то, что реализация услуг IP-телефонии приводит к деформации сложившегося рынка телефонных услуг, так как при действующей системе расчетов между операторами и компаниями-поставщиками услуг Интернет ISP (Internet Service Provider) соответствующие реальные затраты не поддаются оценке и не могут быть отнесены на счет ISP.

Несмотря на обоснованность претензий АСТА, данная жалоба не была удовлетворена FCC, поскольку в соответствии с американским законодательством IP-телефония относится к улучшенным услугам (exhanced services), для реализации которых используются компьютерные приложения. Регулирование улучшенных услуг, по мнению FCC, будет сдерживать развитие компьютерных приложений. Таким образом вопрос, на сегодня, остался открытым.

Позиция же Европейского Союза (ЕС) заключается в том, что передача речи по Интернет пока не может рассматриваться как телефонная услуга, а только как дополнительная, и поэтому не может регулироваться аналогично телефонной услуге. Свою позицию ЕС аргументирует тем, что телефонные услуги, предоставляемые через Интернет, по качеству пока не соответствуют требованиям, предъявляемым к услугам телефонной связи в ТФОП. В то же время ЕС признает, что по мере развития рынка услуг Интернет критерии оценки могут быть пересмотрены.

Данную позицию развивает ассоциация ETNO (European Public Telecommunications Network Operators Association), которая считает, что предоставление услуг передачи речи по Интернет может регулироваться в технических аспектах, таким же образом, как деятельность операторов телефонных сетей. ETNO предлагает в целях регулирования рассматривать отдельно два сценария передачи речи по Интернет: "компьютер — компьютер" и "телефон — телефон".

Первый сценарий не относится к услугам ТФОП.

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

Заключение

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

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

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

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

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

Список литературы

1. Packet based multimedia communication systems. ITU-T Recommendation H.323. — Geneva, 1998, April.
2. Using the Flow Label Field in IPv6. IETF RFC 1809. — June, 1995.
3. Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification. IETF RFC 2205. — September, 1997.
4. A Framework for a Gateway Location Protocol. IETF Draft. — July, 1998.
5. SIP: Session Initiation Protocol. IETF Draft. — September, 1998.
6. User Multiplexing in RTP payload between IP Telephony Gateways. IETF Draft. — August, 1998.
7. ETNO Reflection Document on the European Commission Notice concerning the status of voice on the Internet pursuant to Directive 90/388/EEC (RD56 06/97).
8. Status of voice on the Internet under directive 90/3888/EEC.
9. Kevin Werbach. Digital Tornado: The Internet and Telecommunications Policy. The FCC Office of Plans and Policy's Working Paper Series. — March, 1997.