Предисловие

 

В 1829 году губернатор Нью-Йорка Мартин ван Бюрен отправил президенту США Эндрю Джексону письмо следующего содержания:

Уважаемый господин Президент!

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

1) Если суда будут вытеснены железными дорогами, это приве­дёт к большой безработице.

2) Производители судов сильно пострадают, а поставщики бук­сирных канатов, кнутов и конной упряжи останутся без средств к су­ществованию.

3)  Суда абсолютно необходимы для обеспечения обороны страны.

Эти слова настолько похожи на рекомендации относительно IP-те­лефонии, услышанные авторами всего лишь два года назад на од­ном научно-техническом совете, что заставляют удивиться такому совпадению уровней и мотивов в разные времена и в разных стра­нах. Однако технический прогресс определяется не этим, и сего­дняшняя IP-телефония обслуживает около двадцати миллионов або­нентов во всем мире, а операторские компании постепенно превра­щают IP-телефонию в индустрию, не зависящую от административ­но-командных решений. Примером для отечественных операторов может служить компания AT&T, уже применяющая передачу речи по IP-сетям и объявившая о долгосрочном плане перевода всего сво­его речевого трафика дальней связи на платформу IP. В составе со­вместного глобального проекта AT&T и British Telecom в течение че­тырех лет создают новую глобальную IP-сеть стоимостью 10 милли­ардов долларов, которая будет предоставлять услуги интегрирован­ной передачи речи и данных многонациональным бизнес-абонентам.

А начиналось все отнюдь не так безоблачно. Первая попытка реа­лизовать IP-телефонию была предпринята в 1983 году в Кембридже, Массачусетс. В состав оборудования рабочих станций, закреплен­ных за отдельными проектами Интернет, была включена так называе­мая «речевая воронка», выполнявшая функции цифровизации речи, пакетирования и передачи пакетов через Интернет между офисами Bolt Beranekand Newman (BBN) на Восточном и Западном побережьях США. С позиций приписываемого А. Эйнштейну высказывания - «от­крытия делаются тогда, когда все знают, что этого сделать нельзя, а потом появляется кто-то, кто этого не знает и совершает откры­тие» - те эксперименты 80-х годов относились к первой части дан­ной формулировки. Немногочисленные студенты и энтузиасты IP-те­лефонии первого поколения были должны использовать на каждом конце одно и то же клиентское программное обеспечение, находиться в режиме подключения к системе в момент вызова, проводить зна­чительную часть времени, терзая регулировки громкости и компрес­сии в попытках устранить эхо, чтобы получше слышать друг друга. Качество речи портили длинные паузы, вызванные переменной за­держкой пакетов, обрезанная речь, получавшаяся в результате вы­брасывания пакетов, эхо обратной связи из-за близкого расположе­ния громкоговорителя компьютера и микрофона.

Открытие IP-телефонии как профессиональной технологии совер­шила израильская компания VocalTec, сумевшая к 1995 году собрать воедино достижения в областях цифровой обработки сигналов (DSP), кодеков, компьютеров и протоколов маршрутизации, чтобы сделать реальными разговоры через Интернет без оглядки на расстояние между абонентами и длительность разговора. О системных аспек­тах, основных сценариях и алгоритмах IP-телефонии говорится в гла­вах 1 и 2.

Начиная с 1995 года, для IP-телефонии стали использоваться два метода звуковой компрессии - GSM, с близкой к 5:1 степенью ком­прессии исходного звукового сигнала, и TrueSpeech компании DSP Group, Inc., обеспечивающей коэффициент компрессии 18:1 с мало­заметной потерей качества звука при декомпрессии. Это обсужда­ется в главе 3 данной книги. Там же рассматриваются аудио-стан­дарты G.7xx, включенные в рекомендованный Международным сою­зом электросвязи (ITU-T) «зонтичный» стандарт Н.323, которому це­ликом посвящены главы 5 и 6. Другие концептуальные подходы и стандартные протоколы IP-телефонии SIP, MGCP и MEGACO рас­смотрены в главах 7, 8 и 9, соответственно.

В дополнение к алгоритмам компрессии/декомпрессии выборок речи и стандартным протоколам, IP-телефония занимается техникой борьбы с задержками в Интернет. Пакеты могут следовать к месту назначения по разным путям и могут не все поступить к месту сборки вовремя и в надлежащем порядке. Если бы это были обычные дан­ные, то запоздавшие или поврежденные пакеты можно было бы про­сто отбросить, а протокол контроля ошибок в рабочей станции за­просил бы повторную передачу этих пакетов. Но такая концепция не может быть принята для пакетов, содержащих компрессированную речь, без опасности значительного ухудшения качества разговоров, которые, разумеется, должны происходить в реальном времени. Только если отбрасывается небольшой процент пакетов, скажем, 15%, пользователи на каждом конце могут не заметить пробелов в разговоре. Когда потеря пакетов достигает 20%, качество разго­вора ощутимо ухудшается. Общему анализу протоколов Интернет для IP-телефонии посвящена глава 4, а проблемы качества обслужива­ния (QoS) для IP-телефонии рассматриваются в главе 10.

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

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

В том, что это, в конце концов, удалось, заслуга тех, кто поддер­живал авторов и помогал им советами, информацией и просто соз­данием стимулирующей атмосферы, в первую очередь - В.А. Соко­лова, Ю.В. Аксенова, А.Е. Кузнецова, В.Д. Кадыкова, а также студен­тов Санкт-Петербургского университета телекоммуникаций им. проф. М.А.Бонч-Бруевича - А.Б.Гольдштейна, В.В. Саморезова, С.Б. Шурыгиной. Результат всех этих усилий перед читателем.

Замечания и предложения по материалам книги просьба направ­лять по адресу nio1@loniis.spb.ru. а информацию о других книгах и разработках можно найти на Web-сайте www.loniis.ru.

 

Глава 1

 

Конвергенция сетей связи

 

1.1      Пропорции в телекоммуникациях

 

Гуляя в тенистой роще, греческий философ Анаксимен беседо­вал со своим учеником. «Скажи мне, - спросил юноша, - почему тебя часто одолевают сомнения? Ты прожил долгую жизнь, умудрен опы­том и учился у великих эллинов. Как же так вышло, что и для тебя ос­талось столь много неясных вопросов?». В ответ философ очертил посохом перед собой два круга: маленький и большой. «Твои знания -это маленький круг, а мои - большой. Но все, что осталось вне этих кругов, - неизвестность. Маленький круг с неизвестностью соприка­сается мало. Чем шире круг твоих знаний, тем протяженнее его гра­ница с неизвестностью. И впредь, чем больше ты будешь узнавать нового, тем больше у тебя будет возникать неясных вопросов».

Классическая телефония с ее традиционными телефонными ус­лугами POTS (Plain Old Telephone Service), достаточно хорошо изу­ченная за свою более чем столетнюю историю, соответствует мало­му кругу из этой поучительной притчи. Большой круг представляет нарождающуюся индустрию инфокоммуникаций, являющуюся ре­зультатом взаимопроникновения (конвергенции) информационных и телекоммуникационных технологий и услуг и действительно поро­ждающую больше неясных вопросов, чем готовых ответов. Не пла­нируя в этой главе (да и во всей книге) рассмотреть множество раз­нообразных аспектов инфокоммуникаций за исключением одного -IP-телефонии, - коснемся лишь их общей базы - телекоммуникаций.

Со времени своего возникновения телекоммуникации базируют­ся на передаче электромагнитных сигналов через транспортную сре­ду, каковой могут быть:

•   металлический кабель,

•   оптоволокно,

•   радиоканал.

Передаваемая в виде электромагнитных сигналов информация может представлять собой:

•  речь,

• данные,

•  видеоизображение

или любую их комбинацию, называемую мультимедийной инфopмацией.

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

Еще в 1996 г. в США трафик передачи данных впервые превысил речевой (рис. 1.1) и продолжает демонстрировать завидные темпы роста (до 30% в год по сравнению с З% в год для телефонии). Тоже произошло в Европе в 1999 году. Все это послужило толчком к нача­лу новой эры в телекоммуникациях - эры интегрированных решений и конвергенции всех видов связи. Протокол IP получил мировое при­знание и, в известной степени, стал «де-факто» стандартом для пе­редачи мультимедийной информации.

Если добавить сюда феномен сети Интернет, где, по самым скром­ным подсчетам, рост числа пользователей составляет 5% в месяц, то станет совершенно ясно, что все эти события самым непосредст­венным образом влекут за собой коренное изменение подходов к по­строению информационных сетей. Речь и данные меняются места­ми. Традиционные сети передачи данных базировались на магист­ралях с коммутацией каналов, предназначенных для телефонного трафика. При новом подходе - все наоборот: телефония будет над­страиваться над инфраструктурой сети передачи данных.

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

Рис. 1.1   Рост трафика Интернет (данные) и телефонного трафика

 

Но понятие Voice over IP подразумевает не только и не столько ис­пользование сети Интернет в качестве среды передачи речи, сколько сам протокол IP и технологии, обеспечивающие надежную и высоко­качественную передачу речевой информации в сетях пакетной ком­мутации. Отсутствие гарантированного качества обслуживания при передаче речи компенсируется появлением таких технологий, как многопротокольная коммутация по меткам - Multiprotocol Label Switching (MPLS), протокол резервирования ресурсов - Resource Reservation Protocol (RSVP), дифференциальное обслуживав разнотипного трафи­ка - Differentiated Services (DiffServ) и других. Все большую популяр­ность приобретает передача пакетов IP, упакованных в контейнеры систем синхронной цифровой иерархии - Synchronous Digital Hierar­chy (SDH), а также технология спектрального мультиплексирования -Wave Division Multiplexing (WDM). Во всех случаях необходимым усло­вием является подчинение каждого узла системы единой политике управления трафиком. Этому же призваны помочь протоколы RTP, RTSP, Diffentiaten Services и другие механизмы, рассматриваемые в следующих главах книги. Здесь же достаточно отметить, что стан­дартизация речевых технологий на основе стека TCP/IP и их поддерж­ка лидерами рынка пакетной телефонии обеспечат совместимость оборудования разных производителей и позволят создавать систе­мы, в которых возможны вызовы с аналогового телефонного аппара­та, подключенного к порту маршрутизатора, на персональный компь­ютер, или с персонального компьютера на номер ТфОП, в рамках трех сценариев IP-телефонии, рассматриваемых в следующей главе.

 

1.2        Перспективы развития ТфОП и IP-сетей

 

Продолжая анализ роста трафика данных и речи, представленно­го в виде графиков на рис.1 в предыдущем параграфе, авторы позволили себе привести прогноз роста количества абонентов (графики на рис.1.2а). Суть прогноза отнюдь не в том, что количество пользо­вателей сетей стационарной связи, мобильной связи и Интернет к 2004-2006 годам достигнет миллиарда, а в том, что емкости этих сетей сближаются. В контексте данной главы последнее обстоятель­ство, согласно закону диалектики о переходе количества в качество, приводит к принципиально новым мыслям по поводу конвергенции этих сетей. Немаловажным стимулом таких мыслей является прогноз общемировых доходов от телекоммуникационных услуг, сделанный Dataquest (рис. 1.26), графическое представление которого почти совпадает с верхней кривой на рис. 1.2а. Пороговая величина в этом прогнозе составляет триллион долларов США совокупного дохода по сегментам рынка (речь, данные, мобильная связь), а переход за этот порог ожидается еще раньше - в 2002-2003 гг.

 

Одним из аспектов, способствующих упомянутой выше конверген­ции, является ключевой принцип отделения организации услуг от транспортировки информации, составляющий основу идеи Интеллектуаль­ных сетей. Суть концепции Интеллектуальной сети (IN) заключается в по­строении универсальной среды, обеспечивающей наибольшую эффек­тивность создания и предоставления новых телефонных услуг Посте­пенно эта концепция стала средством глобального нагнетания вычис­лительной мощности в телефонную сеть общего пользования (ТфОП), о чем немало сказано в только что вышедшей монографии [8].

Здесь же представляется полезным продолжить количественные оценки и попробовать представить себе краткосрочный и долговре­менный прогнозы развития телекоммуникационных услуг.

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

Рис. 1.3 иллюстрирует эволюцию телекоммуникационных прило­жений на основе IP.

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

 

Первоочередная цель конвергенции сетей на базе протокола IP -это снижение общих расходов, складывающихся не только из капи­тальных затрат на приобретение и инсталляцию телекоммуникаци­онного оборудования, но и из затрат на его содержание. Теоретиче­ски одна объединенная сеть уменьшила бы потребность в квалифи­цированном персонале - одни и те же люди стали бы заниматься и те­лефонией, и системами передачи данных. Наличие всего одного ка­нала доступа к распределенной сети тоже основательно снизило бы ежемесячные расходы. Направляя речевой трафик через корпора­тивную магистральную сеть передачи данных, можно существенно уменьшить затраты на традиционные телефонные услуги. И, нако­нец, сокращение единиц используемого оборудования значительно уменьшит стоимость его технического обслуживания. Как отметил представитель одного международного оператора связи, переход на технологию IP-телефонии позволит ему сэкономить порядка 70% средств на капитальные затраты, 60-80% средств, выделяемых на ор­ганизацию каналов доступа, и 50% средств на текущее обслужива­ние и ремонт сети [13].

Однако экономия на стоимости инфраструктуры - это не то, ради чего замышлялся переход к объединенным сетям. Революция про­изойдет тогда, когда появятся новые приложения, например, когда центры обслуживания клиентов смогут в реальном времени «сопро­вождать» каждого покупателя с момента его появления на домаш­ней странице компании в сети Интернет до оформления заказа на покупку нужного продукта, «проводя» его через такие этапы, как де­монстрация каталога предлагаемых изделий и выяснение неясных вопросов в ходе телефонного общения с представителем компании. Другой пример применения новых технологий - использование со­трудниками телефонного сервиса своей корпоративной УАТС неза­висимо оттого, где они находятся, например, при работе дома. К этим применениям IP-телефонии авторы вернутся в главе 11.

При всех оптимистических прогнозах, изложенных выше, не сле­дует забывать, что традиционная телефонная связь опирается на мощную базу, создававшуюся на протяжении многих десятилетий, и такая система не может не обладать определенной инерцией. Ис­ходя из этого, вряд ли стоит ожидать, что не сегодня-завтра произой­дет мгновенный революционный скачок в области связи, и Интер­нет-телефония вытеснит все остальные технологии. Скорее наобо­рот: на протяжении ближайших 5-10 лет традиционная телефония будет по-прежнему занимать доминирующие позиции. Переход на новые, более прогрессивные методы будет происходить постепен­но эволюционным путем, в разных странах с разной скоростью. А это значит, что в течение длительного времени ТфОП и IP-сети будут вы­нуждены существовать параллельно, обеспечивая взаимную про­зрачность и объединяя свои усилия в обслуживании разнородного абонентского трафика.

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

Не менее законов, правил и норм важны традиции, сформировав­шиеся за более чем столетний период существования ТфОП. И. Губерманом дана точная формулировка важности традиций:

 

Владыка наш - традиция. А в ней –

свои благословенья и препоны;

неписаные правила сильней,

чем самые свирепые законы.

 

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

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

 

1.3   Транспортные технологии пакетной коммутации

 

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

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

Рис. 1.4 Сравнение технологий пакетной передачи речи:

a)VoATM,6)VoFR, b)VoIP

 

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

Технологии Frame Relay суждено было сыграть в пакетной теле­фонии ту же роль, что и квазиэлектронным АТС в телефонии с ком­мутацией каналов: они показали пример эффективной программно управляемой техники, но имели ограниченные возможности дальней­шего развития. Пользователями недорогих услуг Frame Relay, обес­печивающих вполне предсказуемую производительность, стали мно­гие корпоративные сети, и большинство из них вполне довольны сво­им выбором. В краткосрочной перспективе технология передачи речи по Frame Relay будет вполне эффективна для организации мультисервисного доступа и каналов дальней связи. Но сети Frame Relay распространены незначительно: как правило, на практике использу­ются некоммутируемые соединения в режиме точка-точка.

Технология передачи речевой информации по сетям с маршрути­зацией пакетов IP привлекает, в первую очередь, своей универсаль­ностью - речь может быть преобразована в поток IP-пакетов в лю­бой точке сетевой инфраструктуры: на магистрали сети оператора, на границе территориально распределенной сети, в корпоративной сети и даже непосредственно в терминале конечного пользователя. В конце концов, она станет наиболее широко распространенной тех­нологией пакетной телефонии, поскольку способна охватить все сег­менты рынка, будучи при этом хорошо адаптируемой к новым условиям применения. Несмотря на универсальность протокола IP, вне­дрение систем IP-телефонии сдерживается тем, что многие опера­торы считают их недостаточно надежными, плохо управляемыми и не очень эффективными. Но грамотно спроектированная сетевая ин­фраструктура с эффективными механизмами обеспечения качества обслуживания, рассматриваемыми в главе 10, делает эти недостат­ки малосущественными. В расчете на порт стоимость систем IP-теле­фонии находится на уровне (или немного ниже) стоимости систем Frame Relay, и заведомо ниже стоимости оборудования ATM. При этом уже сейчас видно, что цены на продукты IP-телефонии снижа­ются быстрее, чем на другие изделия, и что происходит значитель­ное обострение конкуренции на этом рынке.

 

1.4   Уровни архитектуры IР-телефонии

 

Архитектура технологии Voice over IP может быть упрощенно пред­ставлена в виде двух плоскостей. Нижняя плоскость - это базовая сеть с маршрутизацией пакетов IP, верхняя плоскость - это открытая архитектура управления обслуживанием вызовов (запросов связи).

Нижняя плоскость, говоря упрощенно, представляет собой ком­бинацию известных протоколов Интернет: это - RTP (Real Time Transport Protocol), который функционирует поверх протокола UDP (User Datagram Protocol), расположенного, в свою очередь, в стеке протоколов TCP/IP над протоколом IP. Таким образом, иерархия RTP/UDP/IP представляет собой своего рода транспортный меха­низм для речевого трафика. Этот механизм будет более подробно рассмотрен в главе 4, посвященной протоколам Интернет для пе­редачи речи в реальном времени. Здесь же отметим, что в сетях с маршрутизацией пакетов IP для передачи данных всегда преду­сматриваются механизмы повторной передачи пакетов в случае их потери. При передаче информации в реальном времени использо­вание таких механизмов только ухудшит ситуацию, поэтому для пе­редачи информации, чувствительной к задержкам, но менее чувст­вительной к потерям, такой как речь и видеоинформация, исполь­зуется механизм негарантированной доставки информации RTP/UDPD/IP. Рекомендации ITU-T допускают задержки водном на­правлении не превышающие 150 мс. Если приемная станция запро­сит повторную передачу пакета IP, то задержки при этом будут слиш­ком велики. Эти проблемы более подробно рассматриваются в гла­ве 10, посвященной качеству обслуживания.

Теперь перейдем к верхней плоскости управления обслуживани­ем запросов связи. Вообще говоря, управление обслуживанием вы­зова предусматривает принятие решений о том, куда вызов должен быть направлен, и каким образом должно быть установлено соеди­нение между абонентами. Инструмент такого управления - телефон­ные системы сигнализации, начиная с систем, поддерживаемых декадно-шаговыми АТС и предусматривающих объединение функций маршрутизации и функций создания коммутируемого разговорного канала в одних и тех же декадно-шаговых искателях. Далее принци­пы сигнализации эволюционировали к системам сигнализации по выделенным сигнальным каналам, к многочастотной сигнализации, к протоколам общеканальной сигнализации №7 [6, 7] и к передаче функций маршрутизации в соответствующие узлы обработки услуг Интеллектуальной сети [8].

В сетях с коммутацией пакетов ситуация более сложна. Сеть с мар­шрутизацией пакетов IP принципиально поддерживает одновремен­но целый ряд разнообразных протоколов маршрутизации. Такими протоколами на сегодня являются: RIP - Routing Information Proto­col, IGRP - Interior Gateway Routing Protocol, EIGRP - Enhanced Interi­or Gateway Routing Protocol, IS-IS- Intermediate System-to-Intermediate System, OSPF - Open Shortest Path First, BGP - Border Gateway Protocol и др. Точно так же и для IP-телефонии разработан целый ряд протоколов. Рассматриваемые в этой книге стандарты содержат по­ложения, относящиеся к передаче речи по IP-сетям (глава 3) и к сиг­нализации для IP-телефонии (главы 6, 7, 8 и 9).

Наиболее распространенным является протокол, специфициро­ванный в рекомендации Н.323 ITU-T, в частности, потому, что он стал применяться раньше других протоколов, которых, к тому же, до вне­дрения Н.323 вообще не существовало. Этот протокол подробно рас­сматривается в главах 5 и 6.

Другой протокол плоскости управления обслуживанием вызова -SIP - ориентирован на то, чтобы сделать оконечные устройства и шлюзы более интеллектуальными и поддерживать дополнительные услуги для пользователей. Этот протокол подробно рассматривает­ся в главе 7.

Еще один протокол - SGCP - разрабатывался, начиная с 1998 года, для того, чтобы уменьшить стоимость шлюзов за счет реализации функций интеллектуальной обработки вызова в централизованном оборудовании. Протокол IPDC очень похож на SGCP, но имеет много больше, чем SGCP, механизмов эксплуатационного управления (ОАМ&Р). В конце 1998 года рабочая группа MEGACO комитета IETF разработала протокол MGCP, базирующийся, в основном, на прото­коле SGCP, но с некоторыми добавлениями в части ОАМ&Р. Прото­кол MGCP подробно рассматривается в главе 8.

Рабочая группа MEGACO не остановилась на достигнутом, про­должала совершенствовать протокол управления шлюзами и раз­работала более функциональный, чем MGCP, протокол MEGACO. Его адаптированный к Н .323 вариант (под названием Gateway Con­trol Protocol) ITU-T предлагает в рекомендации Н.248. Протоколу MEGACO/H.248 посвящена глава 9.

 

1.5 Различные подходы к построению сетей IP-телефонии

 

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

 

1.5.1   Построение сети по рекомендации Н.323

 

Первый в истории подход к построению сетей IP-телефонии на стандартизованной основе предложен Международным союзом электросвязи (ITU) в рекомендации Н.323 [42]. Сети на базе прото­колов Н.323 ориентированы на интеграцию с телефонными сетями и могут рассматриваться как сети ISDN, наложенные на сети передачи данных. В частности, процедура установления соединения в таких сетях IP-телефонии базируется на рекомендации Q.931 [44] и ана­логична процедуре, используемой в сетях ISDN.

Рекомендация Н.323 предусматривает довольно сложный набор протоколов, который предназначен но просто для передачи речевой информации по IP-сетям с коммутацией пакетов. Его цель - обеспе­чить работу мультимедийных приложений в сетях с негарантирован­ным качеством обслуживания. Речевой трафик - это только одно из приложений Н.323, наряду с видеоинформацией и данными. Атак как ничего в технике (как и в жизни) не достается даром, обеспечение совместимости с Н.323 различных мультимедийных приложений тре­бует весьма значительных усилий. Например, для реализации функ­ции переключения связи (call transfer) требуется отдельная специ­фикация Н.450.2.

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

На рис 1.5. представлена архитектура сети на базе рекомендации Н.323. Основными устройствами сети являются: терминал (Terminal), шлюз (Gateway), привратник (Gatekeeper) и устройство управления конференциями (Multipoint Control Unit - MCU).

 

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

Шлюз IP-телефонии реализует передачу речевого трафика по се­тям с маршрутизацией пакетов IP no протоколу Н.323. Основное на­значение шлюза - преобразование речевой информации, поступаю­щей со стороны ТФОП, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP. Кроме того, шлюз преобразует сиг­нальные сообщения систем сигнализации DSS1 и ОКС7 в сигналь­ные сообщения Н.323 и производит обратное преобразование в со­ответствии с рекомендацией ITU H.246.

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

Рис. 1.6 Зона сети Н.323

 

Наиболее важными функциями привратника являются:

·      регистрация оконечных и других устройств;

·      контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS;

·       преобразование alias-адреса вызываемого пользователя (объяв­ленного имени абонента, телефонного номера, адреса электрон­ной почты и др.) в транспортный адрес сетей с маршрутизацией пакетов IP (IP адрес + номер порта TCP);

·      контроль, управление и резервирование пропускной способности сети;

·         ретрансляция сигнальных сообщений Н.323 между терминалами.

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

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

Устройство управления конференциями обеспечивает возмож­ность организации связи между тремя или более участниками. Реко­мендация Н.323 предусматривает три вида конференции (рис. 1.7): централизованная (т.е. управляемая MCU, с которым каждый участ­ник конференции соединяется в режиме точка-точка), децентрализо­ванная (когда каждый участник конференции соединяется с осталь­ными ее участниками в режиме точка-группа точек) и смешанная.

 

Рис. 1.7  Виды конференции в сетях Н.323

 

Преимуществом централизованной конференции является срав­нительно простое терминальное оборудование, недостатком - боль­шая стоимость устройства управления конференциями.

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

Устройство управления конференциями состоит из одного обя­зательного элемента - контроллера конференций (Multipoint Control­ler - МС), и, кроме того, может включать в себя один или более процессоров для обработки пользовательской информации (Multipoint Processor - МР). Контроллер может быть физически совмещен с при­вратником, шлюзом или устройством управления конференциями, а последнее, в свою очередь, может быть совмещено со шлюзом или привратником.

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

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

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

Существует еще один элемент сети Н.323 - прокси-сервер Н.323, т.е. сервер-посредник. Этот сервер функционирует на прикладном уровне и может проверять пакеты с информацией, которой обмени­ваются два приложения. Прокси-сервер может определять, с каким приложением (Н.323 или другим) ассоциирован вызов, и осуществ­лять нужное соединение. Прокси-сервер выполняет следующие клю­чевые функции:

•   подключение через средства коммутируемого доступа или локаль­ные сети терминалов, не поддерживающих протокол резервиро­вания ресурсов (RSVP). Два таких прокси-сервера могут образо­вать в IP-сети туннельное соединение с заданным качеством об­служивания;

•   маршрутизацию трафика Н.323 отдельно от обычного трафика данных;

•   обеспечение совместимости с преобразователем сетевых адре­сов, поскольку допускается размещение оборудования Н.323 в се­тях с пространством адресов частных сетей;

•   защиту доступа - доступность только для трафика Н .323.

 

Более подробно архитектура сети Н.323 будет рассмотрена в гла­ве 5, а сейчас целесообразно сказать несколько слов о протоколах сигнализации, входящих в семейство Н.323.

Протокол RAS (Registration, Admission, Status) обеспечивает взаи­модействие оконечных и других устройств с привратником. Основ­ными функциями протокола являются: регистрация устройства в сис­теме, контроль его доступа к сетевым ресурсам, изменение полосы пропускания в процессе связи, опрос и индикация текущего состоя­ния устройства. В качестве транспортного протокола используется протокол с негарантированной доставкой информации UDR

Протокол Н.225.0 (Q.931) поддерживает процедуры установления, поддержания и разрушения соединения. В качестве транспортного протокола используется протокол с установлением соединения и га­рантированной доставкой информации TCP.

По протоколу Н.245 происходит обмен между участниками соеди­нения информацией, которая необходима для создания логических каналов. По этим каналам передается речевая информация, упако­ванная в пакеты RTP/UDP/IP, которые рассматриваются в главе 4.

Выполнение процедур, предусмотренных протоколом RAS, явля­ется начальной фазой установления соединения с использованием сигнализации Н.323. Далее следуют фаза сигнализации Н.225.0 (Q.931) и обмен управляющими сообщениями Н.245. Разрушение соединения происходит в обратной последовательности: в первую очередь закрывается управляющий канал Н.245 и сигнальный канал Н. 225.0, после чего привратник по каналу RAS оповещается об осво­бождении ранее занимавшейся полосы пропускания.

Сложность протокола Н.323 демонстрирует рис. 1.8, на котором представлен упрощенный сценарий установления соединения между двумя пользователями. В данном сценарии предполагается, что ко­нечные пользователи уже знают IP-адреса друг друга. В обычном слу­чае этапов бывает больше, поскольку в установлении соединения уча­ствуют привратники и шлюзы; это будет рассмотрено в главе 6. Рассмотрим шаг за шагом этот упрощенный сценарий.

1.  Оконечное устройство пользователя А посылает запрос соедине­ния - сообщение SETUP - к оконечному устройству пользователя ВнаТСР-порт1720.

2.  Оконечное устройство вызываемого пользователя В отвечает на сообщение SETUP сообщением ALERTING, означающим, что уст­ройство свободно, а вызываемому пользователю подается сиг­нал о входящем вызове.

3.  После того, как пользователь В принимает вызов, к вызывающей стороне А передается сообщение CONNECT с номером ТСР- порта управляющего канала Н.245.

4.  Оконечные устройства обмениваются по каналу Н.245 информа­цией о типах используемых речевых кодеков (G.729, G.723.1 и т.д.),

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

5.  Открываются логические каналы для передачи речевой инфор­мации.

6.  Речевая информация передаётся в обе стороны в сообщениях протокола RTP; кроме того, ведется контроль передачи инфор­мации при помощи протокола RTCP.

Рис. 1.8  Упрощённый сценарий установления

соединения в сети Н.323

 

Приведенная процедура обслуживания вызова базируется на протоколе Н.323 версии 1. Версия 2 протокола Н.323 позволяет пе­редавать информацию, необходимую для создания логических ка­налов, непосредственно в сообщении SETUP протокола Н.225.0 без использования протокола Н.245. Такая процедура называется «бы­стрый старт» (Fast Start) и позволяет сократить количество циклов обмена информацией при установлении соединения. Кроме орга­низации базового соединения, в сетях Н.323 предусмотрено пре­доставление дополнительных услуг в соответствии с рекомендация­ми ITU H.450.x. Более детальный обзор сигнализации Н.323 приво­дится в главе 6.

Следует отметить еще одну важную проблему - качество обслу­живания в сетях Н.323. Оконечное устройство, запрашивающее у при­вратника разрешение на доступ, может, используя поле transportQoS в сообщении ARQ протокола RAS, сообщить о своей способности резервировать сетевые ресурсы. Рекомендация Н.323 определяет протокол резервирования ресурсов (RSVP) как средство обеспечения гарантированного качества обслуживания, что предъявляет к терминалам требование поддержки протокола RSVP. К сожалению, про­токол RSVP используется отнюдь не повсеместно, что оставляет сети Н.323 без основного механизма обеспечения гарантированного качества обслуживания. Это - общая проблема сетей IР-телефонии, характерная не только для сетей Н.323.

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

 

1.5.2 Сеть на базе протокола SIP

 

Второй подход к построению сетей IP-телефонии, предложенный рабочей группой MMUSIC комитета IETF в документе RFC 2543 [54], основан на использовании протокола SIP - Session Initiation Protocol. SIP представляет собой текст - ориентированный протокол, который яв­ляется частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF). Эта архитектура так­же включает в себя протокол резервирования ресурсов (Resource Reservation Protocol, RSVP, RFC 2205), транспортный протокол реального времени (Real-Time Transport Protocol, RTR RFC 1889), протокол пе­редачи потоков в реальном времени (Real-Time Streaming Protocol, RTSP, RFC 2326), протокол описания параметров связи (Session De­scription Protocol, SDR RFC 2327), протокол уведомления о связи (Ses­sion Announcement Protocol, SAP). Однако функции протокола SIP не зависят от любого из этих протоколов.

Сразу следует отметить, что хотя на сегодня наиболее широкое распространение получил протокол Н.323, всё большее количество производителей старается предусмотреть в своих новых продуктах поддержку протокола SIP. Пока это - единичные явления и серьез­ной конкуренции протоколу Н.323 они составить не могут. Однако, учитывая темпы роста популярности протокола SIP, весьма вероят­но, что в ближайшем будущем решения на его базе займут значи­тельную нишу рынка 1Р-телефонии.

Подход SIP к построению сетей IP-телефонии намного проще в реализации, чем Н.323, но меньше подходит для организации взаи­модействия с телефонными сетями. В основном это связано с тем, что протокол сигнализации SIP, базирующийся на протоколе HTTP, плохо согласуется с системами сигнализации, используемыми в ТфОП. Поэтому протокол SIP более подходит поставщикам услуг Интернет для предоставления успуги IP-телефонии, причем эта ус­луга будет являться всего лишь частью пакета услуг.

Тем не менее, протокол SIP поддерживает услуги интеллектуаль­ной сети (IN), такие как преобразование (мэппинг) имён, переадре­сация и маршрутизация [8], что существенно для использования SIP в качестве протокола сигнализации в сети общего пользования, где приоритетной задачей оператора является предоставление широ­кого спектра телефонных услуг. Другой важной особенностью про­токола SIP является поддержка мобильности пользователя, т.е. его способности получать доступ к заказанным услугам в любом месте и с любого терминала, а также способности сети идентифицировать и аутентифицировать пользователя при его перемещении из одного места в другое. Это свойство SIP не уникально, и, например, прото­кол Н.323 тоже в значительной степени поддерживает такую возмож­ность. Сейчас настал момент, когда эта возможность станет главной привлекательной чертой сетей IP-телефонии нового поколения. Дан­ный режим работы потребует дистанционной регистрации пользо­вателей на сервере идентификации и аутентификации.

Перейдем непосредственно к архитектуре сетей, базирующихся на протоколе SIP (рис. 1.9).

Рис. 1.9  Пример сети на базе протокола SIP

 

Сеть SIP содержит основные элементы трех видов: агенты поль­зователя, прокси-серверы и серверы переадресации.

Агенты пользователя (User Agent или SIP client) являются прило­жениями терминального оборудования и включают в себя две состав­ляющие: агент пользователя - клиент (User Agent Client - UAC) и агент пользователя - сервер (User Agent Server - UAS), иначе известные как клиента сервер соответственно. Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и возвращает ответы, т.е. выступает в качестве вызываемой стороны.

Кроме того, существует два типа сетевых серверов SIP: прокси-серверы (серверы-посредники) и серверы переадресации. Серве­ры SIP могут работать как в режиме с сохранением состояний теку­щих соединений (statefull), так и в режиме без сохранения состояний текущих соединений (stateless). Сервер SIP, функционирующий в ре­жиме stateless, может обслужить сколь угодно большое количество пользователей, в отличие от привратника Н.323, который может од­новременно работать с ограниченным количеством пользователей.

Прокси-сервер (Proxy-server) действует «от имени других клиентов» и содержит функции клиента (UAC) и сервера (UAS). Этот сервер ин­терпретирует и может перезаписывать заголовки запросов перед от­правкой их к другим серверам (рис. 1.10). Ответные сообщения сле­дуют по тому же пути обратно к прокси-серверу, а не к клиенту.

Рис. 1.10 Сеть SIP с прокси-сервером

 

Ниже представлен алгоритм установления соединения с помощью протокола SIP при участии прокси-сервера:

1.  Прокси-сервер принимает запрос соединения INVITE от оборудо­вания вызывающего пользователя.

2.   Прокси-сервер устанавливает местонахождение клиента с помо­щью сервера определения местоположения (location server).

3.   Прокси-сервер передает запрос INVITE вызываемому пользова­телю.

4.  Оборудование вызываемого пользователя уведомляет последне­го о входящем вызове и возвращает прокси-серверу сообщение о том, что запрос INVITE обрабатывается {код 100). Прокси-сер­вер, в свою очередь, направляет эту информацию оборудованию вызывающего пользователя.

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

6.  Вызывающая сторона подтверждает установление соединения передачей запроса АСК, которое прокси-сервер переправляет вы­зываемой стороне. Установление соединения закончено, абонен­ты могут обмениваться речевой информацией.

Сервер переадресации (Redirect server) определяет текущее ме­стоположение вызываемого абонента и сообщает его вызывающе­му пользователю (рис. 1.11). Для определения текущего местополо­жения вызываемого абонента сервер переадресации обращается к серверу определения местоположения, принципы работы которо­го в документе RFC 2543 не специфицированы.

Рис. 1.11   Сеть SIP с сервером переадресации

 

Алгоритм установления соединения с использованием протоко­ла SIP при участии сервера переадресации выглядит следующим образом:

1.  Сервер переадресации принимает от вызывающей стороны за­прос соединения INVITE и связывается с сервером определения местонахождения, который выдает текущий адрес вызываемого клиента.

2.  Сервер переадресации передает этот адрес вызывающей сторо­не. В отличие от прокси-сервера, запрос INVITE к оборудованию вызываемого пользователя сервер переадресации не передает.

3.  Оборудование вызывающего пользователя подтверждает завер­шение транзакции с сервером переадресации запросом АСК.

4.  Далее оборудование вызывающего пользователя передает запрос INVITE на адрес, полученный от сервера переадресации.

5.  Оборудование вызываемого пользователя уведомляет послед­него о входящем вызове и возвращает вызывающему обору­дованию сообщение о том, что запрос INVITE обрабатывается (код 100).

6.  Когда вызываемый абонент принимает вызов, об этом извещает­ся оборудование вызывающего пользователя (код 200). Установ­ление соединения закончено, абоненты могут обмениваться ре­чевой информацией.

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

Дадим краткую характеристику самого протокола SIP. Следует заметить, что сообщения SIP могут переноситься как протоколом TCP, так и протоколом UDR

Протокол SIP предусматривает 6 запросов и ответов на них. Сиг­нализация SIP дает возможность пользовательским агентам и сете­вым серверам определять местоположение, выдавать запросы и управлять соединениями.

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

АСК - запрос подтверждает прием от вызываемой стороны отве­та на команду INVITE и завершает транзакцию.

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

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

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

REGISTER - запрос применяется клиентами для регистрации ин­формации о местоположении с использованием серверов SIP.

Более подробная информация о протоколе SIP приведена в главе 7.

 

15.3  Сеть на базе MGCP и MEGACO

 

Третий подход к построению сетей IP-телефонии, основанный на использовании протокола MGCP [56], также предложен комитетом IETF, рабочей группой MEGACO.

При разработке этого протокола рабочая группа MEGACO опира­лась на сетевую архитектуру, содержащую основные функциональ­ные блоки трех видов (рис. 1.12):

•   шлюз - Media Gateway (MG), который выполняет функции преоб­разования речевой информации, поступающей со стороны ТфОП с постоянной скоростью передачи, в вид, пригодный для переда­чи по сетям с маршрутизацией пакетов IP (кодирование и упаков­ку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование);

•   контроллер шлюзов - Call Agent, которой выполняет функции управления шлюзами;

•   шлюз сигнализации - Signaling Gateway (SG), который обеспечи­вает доставку сигнальной информации, поступающей со стороны ТфОП, к контроллеру шлюзов и перенос сигнальной информации в обратном направлении.

 

Рис. 1.12  Архитектура сети на базе протокола MGCP

 

Таким образом, весь интеллект функционально распределенного шлюза сосредоточен в контроллере, функции которого могут быть распределены между несколькими компьютерными платформами. Шлюз сигнализации выполняет функции STP - транзитного пункта сети сигнализации ОКС7. Сами шлюзы выполняют только функций преобразования речевой информации. Один контроллер управляем одновременно несколькими шлюзами. В сети могут присутствовать несколько контроллеров. Предполагается, что они синхронизованы между собой и согласованно управляют шлюзами, участвующими в соединении. Вместе с тем, MEGACO не определяет протокола для синхронизации работы контроллеров. В ряде работ, посвященных ис­следованию возможностей протокола MGCP, для этой цели предла­гается использовать протоколы Н.323, SIP или ISUP/IP.

Сообщения протокола MGCP переносятся протоколом без гаран­тированной доставки сообщений UDP. Рабочая группа SIGTRAN ко­митета IETF в настоящее время разрабатывает механизм взаимодей­ствия контроллера шлюзов и шлюза сигнализации.

Шлюз сигнализации должен принимать поступающие из ТфОП пакеты трех нижних уровней системы сигнализации ОКС7 (уровней подсистемы переноса сообщений МТР) и передавать сигнальные сообщения верхнего, пользовательского, уровня к контроллеру шлю­зов. Шлюз сигнализации также должен уметь передавать по IР-сети приходящие из ТфОП сигнальные сообщения 0.931 .

Основное внимание рабочей группы SIGTRAN уделяется вопро­сам разработки наиболее эффективного механизма передачи сигнальной информации по IP-сетям. Следует отметить, что существу­ет несколько причин, по которым пришлось отказаться от использо­вания для этой цели протокола TCP. Рабочая группа SIGTRAN пред­лагает использовать для передачи сигнальной информации прото­кол Stream Control Transport Protocol (SCTP), имеющий ряд преиму­ществ перед протоколом TCP, основным из которых является значи­тельное снижение времени доставки сигнальной информации и, сле­довательно, времени установления соединения - одного из важней­ших параметров качества обслуживания.

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

Отметим, что протокол MGCP является внутренним протоколом для обмена информацией между функциональными блоками распре­деленного шлюза, который извне представляется одним шлюзом. Протокол MGCP является master/slave протоколом. Это означает, что контроллер шлюзов является ведущим, а сам шлюз - ведомым уст­ройством, которое должно выполнять все команды, поступающие от контроллера Call Agent.

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

Третий подход, предлагаемый организацией IETF (рабочая груп­па MEGACO), хорошо подходит для развертывания глобальных се­тей IP-телефонии, приходящих на смену традиционным телефонным сетям. Более подробная информация о протоколе MGCP приведена в главе 8.

Рассмотрим алгоритмы установления и разрушения соединения с использованием протокола MGCP Первый пример охватывает взаи­модействие протокола MGCP с протоколом 0КС7 (рис. 1.13).

Рис. 1.13  Установление и разрушение соединения с использованием протокола MGCP (Пример 1)

 

1.           От телефонной станции АТС-А к шлюзу сигнализации SG1 по об­щему каналу сигнализации поступает запрос соединения в виде сообщения IAM протокола ISUP [6]. На рис. 1.13 шлюз сигнализа­ции SG1 и SС2 совмещены с транспортными шлюзами TGW1 и TGW2 соответственно. Шлюз SG1 передает сообщение IAM к контролле­ру шлюзов, который обрабатывает запрос и определяет, что вызов должен быть направлен к АТС-Б посредством шлюза TGW2.

2.  Контроллер резервирует порт шлюзаTGW1 (разговорный канал). С этой целью он передает к шлюзу команду CreateConnection. Отметим, что порт шлюза TGW1 может только принимать инфор­мацию (режим «recvonly»), так как он еще не осведомлен о том, по какому адресу и каким образом ему следует передавать ин­формацию.

3.  В ответе на эту команду шлюз TGW1 возвращает описание пара­метров сеанса связи.

4.  Приняв ответ шлюза TGW1, контроллер передает команду CRCX второму шлюзу TGW2 с целью зарезервировать порт в этом шлюзе.

5.  Шлюз TGW 2 выбирает порт, который будет участвовать в соеди­нении, и подтверждает прием команды CRCX. При помощи двух команд CRCX создается однонаправленный разговорный канал для передачи вызывающему абоненту акустических сигналов или речевых подсказок и извещений. В то же время, порт шлюза TGW2 уже может не только принимать, но и передавать информацию, так как он получил описание параметров связи от встречного шлюза.

6.  Далее контроллер шлюзов передает сообщение IAM к АТС-Б.

7.   На сообщение IAM станция АТС-Б отвечает подтверждением АСМ, которое немедленно пересылается к станции АТС-А.

8.  После того как вызываемый абонент примет вызов, АТС-Б пере­дает к контроллеру шлюзов сообщение ANM.

9.  Далее контроллер заменяет в шлюзе TGW1 режим «recvonly» на полнодуплексный режим при помощи команды MDCX.

10.  ШлюзТGW1 выполняет и подтверждает изменение режима.

11.  Контроллер передает сообщение ANM к АТС-А, после чего начи­нается разговорная фаза соединения.

12.  Завершение разговорной фазы происходит следующим обра­зом. В нашем случае вызвавший абонент Б дает отбой первым. АТС-Б передает через шлюз сигнализации сообщение REL к кон­троллеру шлюзов.

13.  Приняв сообщение REL, контроллер шлюзов завершает соеди­нение с вызыванным абонентом.

14.  Шлюз подтверждает завершение соединения и передает к кон­троллеру собранные за время соединения статистические дан­ные.

15.  Контроллер шлюзов передает сообщение RLC к АТС-Б с целью подтвердить разъединение.

16.  Параллельно контроллер завершает соединение с вызвавшей стороной

17.  Шлюз TGW1 подтверждает завершение соединения и передает к контроллеру собранные за время соединения статистические данные.

18.  АТС-А подтверждает завершение соединения передачей сооб­щения RLC, после чего соединение считается разрушенным.

Второй пример иллюстрирует взаимодействие протокола MGCP с протоколами ОКС7 и Н.323 (рис. 1.14).

Рис. 1.14 Установлением разрушение соединения с использованием протокола MGCP (Пример 2)

 

1. С телефонной станции АТС-А к шлюзу сигнализации SG1 по об­щему каналу сигнализации поступает запрос соединения (сооб­щение IAM). На рис. 1.14 шлюз сигнализации SG1 также совме­щен с транспортным шлюзом TGW1. Шлюз SG1 передает сооб­щение IAM контроллеру шлюзов, который обрабатывает запрос и определяет, что вызов должен быть направлен к оконечному уст­ройству вызываемого пользователя - терминалу Н.323.

2.   Контроллер шлюзов резервирует порт шлюза TGW1 (разговорный канал). С этой целью он передает к шлюзу команду Create Connection. И в этом примере порт шлюза TGW1 может только принимать информацию (режим «recvonly»).

3.   В ответе на принятую команду шлюз TGW1 возвращает описание параметров связи.

4.  Приняв ответ от шлюза TGW1, контроллер передает к приврат­нику сети Н.323 сообщение ARQ с alias адресом вызываемого абонента.

5.   В ответ на сообщение ARQ привратник передает сообщение ACF с указанием транспортного адреса своего сигнального канала.

6.   Контроллер передает запрос соединения SETUP на транспортный адрес сигнального канала привратника, при этом используется процедура Fast Start. Привратник пересылает сообщение SETUP к вызываемому терминалу.

7.   Вызываемый терминал передает запрос допуска к ресурсам сети ARQ.

8.   В ответ на запрос ARQ привратник передает подтверждение за­проса ACF.

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

10.  Контроллер преобразует сообщение ALERTING в сообщение АСМ, которое немедленно пересылается к АТС-А.

11.   После того как вызываемый пользователь примет входящий вы­зов, контроллер получит сообщение CONNECT.

12.   Контроллер шлюзов меняет в шлюзе TGW1 режим «recvonly» на полнодуплексный режим.

13.   Шлюз TGW1выполняет и подтверждает изменение режима со­единения.

14.   Контроллер передает сообщение ANM к АТС-А, после чего начи­нается разговорная фаза соединения, в ходе которой оборудова­ние вызвавшего пользователя передает речевую информацию, упакованную в пакеты RTP/UDP/IP, на транспортный адрес RTP-канала терминала вызванного абонента, а тот передает пакетиро­ванную речевую информацию на транспортный адрес RTP-канала терминала вызвавшего абонента. При помощи канала RTCP ведется контроль передачи информации по RTP каналу.

15.   После окончания разговорной фазы начинается фаза разруше­ния соединения. Оборудование пользователя, инициирующего разрушение соединения, должно прекратить передачу речевой информации, закрыть логические каналы и передать сообщение RELEASE COMPLETE, после чего сигнальный канал закрывается.

16.  Контроллер шлюзов передает сообщение RELEASE к АТС-А с це­лью завершения соединения.

17.  Кроме того, контроллер передает к шлюзу команду DLCX.

18.   Шлюз подтверждает завершение соединения и передает к кон­троллеру собранные за время соединения статистические данные.

19.  После вышеописанных действий контроллер и оконечное обо­рудование извещают привратник об освобождении занимавшей­ся полосы пропускания. С этой целью каждый из участников со­единения посылает привратнику по каналу RAS запрос выхода из соединения DRQ, на который привратник должен передать подтверждение DCF.

20.  От АТС-А приходит подтверждение разъединения RLC, после чего соединение считается разрушенным.

Следует заметить, что алгоритм взаимодействия протоколов SIP и MGCP не сильно отличается от вышеописанного алгоритма.

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

Международный союз электросвязи в проекте версии 4 рекомен­дации Н.323 ввел принцип декомпозиции шлюзов. Управление функ­циональными блоками распределенного шлюза будет осуществлять­ся контроллером шлюза - Media Gateway Controller - при помощи адаптированного к Н.323 протокола MEGACO, который в рекомен­дации Н.248 назван Gateway Control Protocol.

Сообщения протокола MEGACO отличаются от сообщений про­токола MGCP, но процедуры установления и разрушения соедине­ний с использованием обоих протоколов идентичны, поэтому опи­сание процедуры установления соединения на базе протокола MEGA­CO здесь не приводится. Эти процедуры, вместе с детальным ана­лизом протокола MEGACO, рассматриваются в главе 9.

 

1.5. 4  Сравнение подходов к построению сети IР- телефонии

 

 

В настоящее время для построения хорошо функционирующих и совместимых с ТфОП сетей IP-телефонии подходят протоколы Н.323 и MGCP. Как уже отмечалось, протокол SIP несколько хуже взаи­модействует с системами сигнализации, используемыми в ТфОП (сравнительный анализ протоколов Н.323 и SIP приведен в главе 7). Подход, основанный на использовании протокола MGCP, обладает весьма важным преимуществом перед подходом, предложенным ITU в рекомендации Н.323: поддержка контроллером шлюзов сигнали­зации ОКС7 и других видов сигнализации, а также прозрачная транс­ляция сигнальной информации по сети IP-телефонии. В сети, построенной на базе рекомендации Н.323, сигнализация ОКС7, как и любая другая сигнализация, конвертируется шлюзом в сигнальные сооб­щения Н.225.0 (Q.931).

Основным недостатком третьего из приведенных в данном пара­графе подходов является незаконченность стандартов. Функцио­нальные составляющие распределенных шлюзов, разработанные разными фирмами-производителями телекоммуникационного обо­рудования, практически несовместимы. Функции контроллера шлю­зов точно не определены. Не стандартизированы механизмы пере­носа сигнальной информации от шлюза сигнализации к контроллеру и в обратном направлении. К недостаткам можно отнести также от­сутствие стандартизированного протокола взаимодействия между контроллерами. Кроме того, протокол MGCP является протоколом управления шлюзами, но не предназначен для управления соедине­ниями с участием терминального оборудования пользователей (IP-телефонов). Это означает, что в сети, построенной на базе про­токола MGCP, для управления терминальным оборудованием должен присутствовать привратник или сервер SIP.

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

В последнем из упомянутых подходов (в проекте версии 4 реко­мендации Н.323) ITU-T ввел принцип декомпозиции шлюзов, исполь­зованный в третьем подходе. Управление функциональными блока­ми распределенного шлюза будет осуществляться контроллером шлюза - MGC (Media Gateway Controller) при помощи протокола MEGACO/H.248. В проекте версии 4 рекомендации Н.323 предусмот­рена также возможность прозрачной передачи сигнализации ОКС7 и других видов сигнализации по сетям IP-телефонии и обработка сигнализации всех видов привратником без преобразования в сиг­нальные сообщения Н. 225.0.

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

 

Глава 2

 

Сетевые аспекты IP-телефонии

 

2.1      Три основных сценария IP-телефонии

 

Материал предыдущей главы дал в первом приближении ответ на вопрос: что такое IP-телефония? Прежде чем обсудить более под­робно различные подходы к архитектуре, протоколам и вариантам построения систем и оборудования, полезно обратить внимание на другой вопрос: для чего нужна IP-телефония? В качестве ответа на этот вопрос рассмотрим три наиболее часто используемых сцена­рия 1Р-телефонии:

 

•   «компьютер-компьютер»;

•   «компьютер-телефон»;

•   «телефон-телефон".

Сценарий «компьютер-компьютер» реализуется на базе стандарт­ных компьютеров, оснащенных средствами мультимедиа и подклю­ченных к сети Интернет.

Компоненты модели IP-телефонии по сценарию «компьютер-ком­пьютер» показаны на рис. 2.1. В этом сценарии аналоговые речевые сигналы от микрофона абонента А преобразуются в цифровую форму с помощью аналого-цифрового преобразователя (АЦП), обычно при 8000 отсчетов/с, 8 битов/отсчет, в итоге - 64 Кбит/с. Отсчеты речевых данных в цифровой форме затем сжимаются кодирующим устройст­вом для сокращения нужной для их передачи полосы в отношении 4:1, 8:1 или 10:1. Алгоритмы сжатия речи подробно рассматриваются в сле­дующей главе. Выходные данные после сжатия формируются в паке­ты, к которым добавляются заголовки протоколов, после чего пакеты передаются через IP-сеть в систему IP-телефонии, обслуживающую абонента Б. Когда пакеты принимаются системой абонента Б, заго­ловки протокола удаляются, а сжатые речевые данные поступают в уст­ройство, развертывающее их в первоначальную форму, после чего речевые данные снова преобразуются в аналоговую форму с помо­щью цифроаналогового преобразователя (ЦАП) и попадают в теле­фон абонента Б. Для обычного соединения между двумя абонентами системы IP-телефонии на каждом конце одновременно реализуют как функции передачи, так и функции приема. Под IP-сетью, изображен­ной на рис. 2.1, подразумевается либо глобальная сеть Интернет, либо корпоративная сеть предприятия Intranet. Описанию протоколов, ис­пользуемых в IP-сетях, в том числе протоколов передачи речевой ин­формации по IP-сети, посвящена глава 4.

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

 

Для поддержки сценария «компьютер - компьютер» поставщику услуг Интернет желательно иметь отдельный сервер (привратник), преобразующий имена пользователей в динамические адреса IP. Сам сценарий ориентирован на пользователя, которому сеть нужна, в ос­новном, для передачи данных, а программное обеспечение IP-теле­фонии требуется лишь иногда для разговоров с коллегами. Эффек­тивное использование телефонной связи по сценарию «компьютер-компьютер» обычно связано с повышением продуктивности работы крупных компаний, например, при организации виртуальной презен­тации в корпоративной сети с возможностью не только видеть документы на Web-сервере, но и обсуждать их содержание с помощью IP-телефона. При этом между двумя IP-сетями могут использовать­ся элементы ТфОП, а идентификация вызываемой стороны может осуществляться как на основе Е.164, так и на основе IP-адресации. Наиболее распространенным программным обеспечением для этих целей является пакет Microsoft NetMeeting, доступный для бесплат­ной загрузки с узла Microsoft.

Рассмотрим представленный на рис. 2.1 сценарий установления соединения «компьютер-компьютер» более подробно.

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

1. Абонент А запускает свое приложение IP-телефонии, поддер­живающее протокол Н.323.

2. Абонент Б уже заранее запустил свое приложение IP-телефо­нии, поддерживающее протокол Н.323.

3.  Абонент А знает доменное имя абонента В элемент системы имен доменов- Domain Name System (DNS), вводит это имя в раздел «кому позвонить» в своем приложении IP-телефонии и нажимает кнопку Return.

4 4. Приложение IP-телефонии обращается к DNS-серверу {кото­рый в данном примере реализован непосредственно в персональ­ном компьютере абонента А) для того, чтобы преобразовать домен­ное имя абонента Б в IP-адрес.

5. Сервер DNS возвращает IP-адрес абонента Б.

6.  Приложение IP-телефонии абонента А получает IP-адрес або­нента Б и отправляет ему сигнальное сообщение Н.225 Setup.

7. При получении сообщения Н.225 Setup приложение абонента Б сигнализирует ему о входящем вызове.

8. Абонент Б принимает вызов и приложение IP-телефонии отправ­ляет ответное сообщение Н.225 Connect.

9.  Приложение IP-телефонии у абонента А начинает взаимодей­ствие с приложением у абонента Б в соответствии с рекомендацией Н.245.

10. После окончания взаимодействия по протоколу Н.245 и откры­тия логических каналов абоненты А и Б могут разговаривать друг с другом через IP-сеть.

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

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

 

Рис. 2.2  Упрощенный сценарий IP-телефонии

"компьютер-компьютер" (аналог рис.2.1)

 

 

Замена изображений имеет и более глубокий смысл. Название сценария «компьютер - компьютер» отнюдь не означает, что в рас­поряжении пользователя обязательно должен быть стандартный PC с микрофоном и колонками, как это представлено на рис. 2.1. Глав­ным требованием для такой схемы является то, что оба пользовате­ля должны иметь подключенные к сети персональные компьютеры. И эти PC должны быть всегда включены, подсоединены к сети и иметь в запущенном виде программное обеспечение IP-телефонии для приема входящих вызовов. При всем этом должна быть полная со­вместимость между программно-аппаратными средствами IP-теле­фонии, полученными от разных поставщиков, т.е. пользователи, же­лающие разговаривать друг с другом, должны иметь идентичное про­граммное обеспечение, например, реализующее протокол Н.323.

Принимая во внимание эти обстоятельства, под названием «ком­пьютер» во всех сценариях мы будем понимать терминал пользова­теля, включенный в IP-сеть, а под названием «телефон» - терминал пользователя, включенный в сеть коммутации каналов любого типа: ТфОП, ISDN или GSM.

И еще одно, более существенное замечание. До сих пор в обсуж­дении сценария «компьютер - компьютер» на рис. 2.1 и 2.2 полагалось, что оба пользователя включены в одну и ту же IP-сеть (Интер­нет, Интранет или другую сеть с протоколом IP). В рамках проекта TIPHON, которому посвящен следующий параграф этой главы, рас­сматривается другая, более сложная модификация сценария «ком­пьютер - компьютер». Эта модификация, представленная на рис. 2.3, предусматривает организацию связи между абонентами IP-сети с учетом того, что вызов транзитом проходит через сеть коммутации каналов (СКК). Заметим, что на этом и на следующих рисунках в ка­честве СКК выступает телефонная сеть общего пользования (ТфОП), хотя излагаемые в данной главе материалы справедливы для ISDN, GSM и др.

 

Рис. 2.3  Упрощенный сценарий IP-телефонии "компьютер-компьютер". Соединение пользователей IP-сетей через транзитную СКК

 

Следующий сценарий - «телефон-компьютер» - находит примене­ние в разного рода справочно-информационных службах Интернет, в службах сбыта товаров или в службах технической поддержки. Поль­зователь, подключившийся к серверу WWW какой-либо компании, име­ет возможность обратиться к оператору справочной службы. Этот сце­нарий в ближайшие несколько лет будет, по всей вероятности, более активно востребован деловым сектором. Компании будут использо­вать данную технологию для наращивания своих Web-страниц (и сво­его присутствия во всемирной паутине). Пользователи компьютеров смогут просматривать в «реальном времени» каталоги, почти мгно­венно заказывать товары и получать множество других услуг Это впол­не соответствует стилю жизни современных потребителей, связанно­му с потребностью в дополнительных удобствах и экономии времени. Уже сегодня осознаются все выгоды и удобства централизованного приобретения предметов широкого потребления {например, компакт-дисков, книг, программного обеспечения и т. д.) и уже привычно со­вершаются операции электронной коммерции.

В рамках проекта TIPHON рассматриваются две модификации этого сценария 1Р-телефонии:

•   от компьютера (пользователя IP-сети) к телефону (абоненту ТфОП), в частности, в связи с предоставлением пользователям IP-сетей доступа к телефонным услугам, в том числе, к справочно-информационным услугам и к услугам Интеллектуальной сети;

•   от абонента ТфОП к пользователю IP-сети с идентификацией вы­зываемой стороны на основе нумерации no E.164 или IP-адре­сации.

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

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

 

Рис. 2.4  Вызов абонента ТфОП пользователем IP-сети по сценарию "компьютер - телефон"

 

Шлюз (GW) для взаимодействия сетей ТфОП и IP может быть реа­лизован в отдельном устройстве или интегрирован в существующее оборудование ТфОП или IP-сети. Показанная на рисунке сеть СКК может быть корпоративной сетью или сетью общего пользования.

В соответствии со второй модификацией сценария «компьютер -телефон» соединение устанавливается между пользователем IP-се­ти и абонентом ТфОП, но инициирует его создание абонент ТфОП (рис. 2.5).

 

Рис. 2.5  Пользователя IP-сети вызывает абонент ТФОП

по сценарию "компьютер - телефон"

 

Рассмотрим несколько подробнее пример представленной на рис. 2.5 упрощенной архитектуры системы IP-телефонии по сцена­рию «телефон-компьютер». При попытке вызвать справочно-информационную службу, используя услуги пакетной телефонии и обычный телефон, на начальной фазе абонент А вызывает близлежащий шлюз IP-телефонии. От шлюза к абоненту А поступает запрос ввести но­мер, к которому должен быть направлен вызов (например, номер службы), и личный идентификационный номер (PIN) для аутентифи­кации и последующего начисления платы, если это служба, вызов которой оплачивается вызывающим абонентом. Основываясь на вызываемом номере, шлюз определяет наиболее доступный путь к данной службе. Кроме того, шлюз активизирует свои функции ко­дирования и пакетизации речи, устанавливает контакт со службой, ведет мониторинг процесса обслуживания вызова и принимает ин­формацию о состояниях этого процесса (например, занятость, по­сылка вызова, разъединение и т.п.) от исходящей стороны через про­токол управления и сигнализации. Разъединение с любой стороны передается противоположной стороне по протоколу сигнализации и вызывает завершение установленных соединений и освобождение ресурсов шлюза для обслуживания следующего вызова.

Для организации соединений от службы к абонентам (рис. 2.4) ис­пользуется аналогичная процедура. Популярными программными про­дуктами для этого варианта сценария IP-телефонии «компьютер-те­лефон» являются IDT Net2Phone и DotDialer, организующие вызовы к обычным абонентским телефонным аппаратам в любой точке мира.

Эффективность объединения услуг передачи речи и данных явля­ется основным стимулом использования IP-телефонии по сценари­ям «компьютер-компьютер» и «компьютер-телефон», не нанося при этом никакого ущерба интересам операторов традиционных теле­фонных сетей.

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

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

Типичная услуга IP-телефонии по сценарию «телефон-телефон» использует стандартный телефон в качестве интерфейса пользова­теля, а вместо междугородного компонента ТфОП использует либо частную IP-ceть/Intranet, либо сеть Интернет. Благодаря маршрути­зации телефонного трафика по IP-сети стало возможным обходить сети общего пользования и, соответственно, не платить за междуго­одную/международную связь операторам этих сетей.

Следует отметить, что сама идея использовать альтернативные транспортные механизмы для обхода сети ТфОП не является новой. Достаточно вспомнить статистические мультиплексоры, передачу речи по сети Frame Relay или оборудование передачи речи по сети ATM.

Как показано на рис. 2.6, поставщики услуг IP-телефонии предос­тавляют услуги «телефон-телефон» путём установки шлюзов IP-те­лефонии на входе и выходе IP-сетей. Абоненты подключаются к шлю­зу поставщика через ТфОП, набирая специальный номер доступа. Абонент получает доступ к шлюзу, используя персональный иденти­фикационный номер (PIN) или услугу идентификации номера вызы­вающего абонента (Calling Line Identification). После этого шлюз про­сит ввести телефонный номер вызываемого абонента, анализирует этот номер и определяет, какой шлюз имеет лучший доступ к нужно­му телефону. Как только между входным и выходным шлюзами ус­танавливается контакт, дальнейшее установление соединения к вы­зываемому абоненту выполняется выходным шлюзом через его ме­стную телефонную сеть.

Полная стоимость такой связи будет складываться для пользова­теля из расценок ТфОП на связь с входным шлюзом, расценок Ин­тернет-провайдера на транспортировку и расценок удалённой ТфОП на связь выходного шлюза с вызванным абонентом.

Рис. 2.6  Соединение абонентов ТфОП через транзитную IP-сеть по сценарию "телефон-телефон"

 

Одним из алгоритмов организации связи по сценарию «телефон-телефон» является выпуск поставщиком услуги своих телефонных карт. Имея такую карту, пользователь, желающий позвонить в дру­гой город, набирает номер данного поставщика услуги, затем в ре­жиме донабора вводит свой идентификационный номер и PIN-код, указанный на карте. После процедуры аутентификации он набирает телефонный номер адресата.

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

 

Рассмотренные выше сценарии сведены в таблице 2.1.

 

Таблица 2.1   Варианты межсетевого взаимодействия

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

Следующий параграф посвящен анализу проекта TIPHON Европей­ского института стандартизации в области телекоммуникаций –Europe Telecommunications Standardization Institute (ETSI). Именно этот институт вплотную занимается сетевыми вопросами IР-телефонии, в то время как другие стандартизирующие телекоммуникационные ор­ганизации основное внимание уделяют вопросам разработки прото­колов сигнализации или механизмов переноса речевой информации по сетям с маршрутизацией пакетов IP. Так, например, область дея­тельности основоположников IP-телефонии ITU-T и IETF ограничива­ется только сетями с маршрутизацией пакетов IP. Вопросы взаимо­действия телефонных и IP сетей рассматривались ITU-T в основном, в части преобразования систем сигнализации [Н.246] и практически не затрагивались комитетом IETF. Более подробно деятельность ITU-T в области IP-телефонии освещена в главах 5 и 6, посвященных архи­тектуре и протоколам Н.323, а результаты деятельности комитета IETF в этой же области рассмотрены в главах 7, 8 и 9.

В проекте TIPHON предполагается разработка новых стандартов и профилей существующих стандартов для каждого из приведенных в таблице 2.1 сценариев. Новые стандарты будут разрабатываться только для тех областей связи, для которых действующие стандарты отсутствуют. Там, где существуют действующие стандарты ETSI, ITU или других стандартизирующих организаций, будет проводиться разработка и преобразование профилей этих стандартов.

 

2.2        Проект TIPHON

 

Работа над проектом TIPHON (Telecommunication and Internet Pro­tocol Harmonization over Networks) была начата институтом ETSI в ап­реле 1997 г. Основная задача проекта - решение проблем взаимо­действия между сетями с маршрутизацией пакетов IP и сетями с ком­мутацией каналов в части поддержки прозрачной передачи речевой и факсимильной информации. Под сетями с коммутацией каналов подразумеваются ТфОП, ISDN и GSM.

В проекте принимают участие свыше 40 крупнейших телекомму­никационных компаний. Имеется восемь рабочих групп, последняя из которых ~ по защите информации - была организована во время 15-го совещания рабочих групп 4-8 октября 1999 г. в Лейпциге. Ре­зультатом деятельности рабочих групп TIPHON являются технические спецификации и отчеты.

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

Была отмечена растущая потребность в организации связи в ре­альном времени, в том числе, телефонной связи, в сетях, реализую­щих технологию маршрутизации пакетов IP. Для удовлетворения этой потребности институт ETSI предлагает в проекте TIPHON концепцию «сети сетей», такой, что сети, входящие в ее состав, могут базиро­ваться на технологиях коммутации каналов и маршрутизации паке­тов IP (рис. 2.7).

Рис. 2.7  Обобщенная структура сети TIPHON

 

В рамках проекта TIPHON сети, использующие различные техно­логии коммутации, имеют статус доменов «глобальной сети». В ос­нову взаимодействия этих доменов положено обеспечение гаранти­рованного качества обслуживания (QoS) и защиты межсетевых со­единений. Кроме того, обеспечивается возможность управлять со­единениями, используя стандартные протоколы сигнализации. Та­ким образом, сеть TIPHON можно определить как сеть высшего уров­ня, поддерживающую предоставление услуг телефонной связи и ба­зирующуюся на совокупности сетей более низкого уровня.

В основу проекта TIPHON положены следующие правила:

•   терминалами TIPHON могут быть персональные компьютеры и обычные телефоны;

•   интерфейс «человек-машина» (MMI) строится по аналогии с те­лефонным интерфейсом;

• пользователи могут менять точки доступа к услугам глобальной сети; при этом должен сохраняться набор предоставляемых ус­луг и качество обслуживания (QoS).

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

Проект TIPHON предусматривает решение ряда технических за­дач, связанных с обеспечением приемлемого качества услуг теле­фонной связи. В число этих задач входит разработка эталонных кон­фигураций и функциональных моделей, требований к взаимодейст­вию различных функциональных объектов, процедур управления со­единением и протоколов; преобразование адресов в формате Е. 164 в IP-адреса; рассмотрение технических аспектов защиты; изучение вопросов мобильности и обеспечения качества обслуживания. Ра­нее указывалось, что в работе над проектом TIPHON участвуют не­сколько групп, каждая из которых отвечает за решение определен­ной задачи. Ниже представлены основные направления деятельно­сти рабочих групп TIPHON.

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

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

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

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

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

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

Вопросы качества обслуживания. Конечный пользователь ожида­ет, что услуга передачи речевой информации будет предоставлять­ся с хорошим качеством и высокой надежностью. Но такие примеры, как предоставление услуг сотовой связи стандарта GSM и микросо­товой связи стандарта DECT, показали, что конечного пользователя удовлетворяет качество обслуживания, худшее по сравнению сТфОП или ISDN, до тех пор, пока он получает выгоду от использования но­вой услуги. В случае предоставления услуг сотовой связи - это мо­бильность терминала, а в случае IP-телефонии это могут быть низ­кая стоимость, возможности интеграции услуг в рамках единой сети.

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

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

Взятую за основу рекомендацию ITU-T H.323, спецификации TIPHON дополняют некоторыми обязательными процедурами, а также механизмами взаимодействия IP-сетей сТфОП. Функциональная модель сети IP-телефонии, разработанная TIPHON, состоит из тех же компонентов, что и модель сети Н.323 (привратник, шлюз, терми­нал), однако в ней предусмотрено разделение шлюза на три функ­ционально-независимых объекта. Это шлюз сигнализации (SG), транспортный шлюз (MG) и контроллер транспортного шлюза (MGC).

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

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

Следует особо подчеркнуть, что MGC - это объект, контролирую­щий работу транспортного шлюза. Управление соединениями в его функции не входит. Это - задача привратника, который выполняет ее в соответствии с рекомендацией ITU-T Н.323.

Разработанная в рамках проекта TIPHON модель сети, состоящая из функциональных элементов и интерфейсов (точек доступа) меж­ду ними, показана на рис. 2.8. Чтобы соответствовать рекомендаци­ям TIPHON, оборудование должно поддерживать эти интерфейсы. Так, интерфейс D предназначен для организации взаимодействия ме­жду привратниками, а интерфейс С - между контроллером шлюза MGC и привратником. Интерфейс N поддерживает взаимодействие между объектами MGCn MG. Они могут общаться на предмет созда­ния, модификации и завершения соединений; определения требуе­мого формата информации; генерации акустических сигналов и раз­личных речевых уведомлений; запроса отчетов о событиях, связан­ных с прохождением информационного потока. Показанные на рис. 2.8 функции поддержки (back-end) могут быть использованы для аутентификации, биллинга, преобразования адресов и других задач.

Смоделированный на основе трех описанных элементов распре­деленный шлюз воспринимается другими элементами сети как еди­ная система.

Рис. 2.8   Модель сети TIPHON

Три упомянутых элемента (SG, MG, MGC) могут не быть физически разделены, однако такое разделение дает определенные преимуще­ства. Дело в том, что использование трех отдельных объектов позво­лит обрабатывать больше вызовов, поскольку в этом случае разные функции распределяются по отдельным процессорам. В идеале та­кие объекты должны иметь стандартные интерфейсы, что даст опера­тору возможность использовать продукцию разных фирм-производи­телей. В приведенной выше модели один шлюз сигнализации с целью более экономичного развертывания сети может быть использован для обслуживания большого числа транспортных шлюзов.

Теперь следует рассмотреть вопрос об адресации в рамках про­екта TIPHON. От решения задач адресации во многом зависят удоб­ство пользования услугой, работа алгоритмов маршрутизации, обес­печение мобильности абонентов и т.д. Концепцией телефонной свя­зи предусмотрено, что абонент сети ТфОП должен иметь возмож­ность связаться с другим абонентом со своего телефона путём на­бора номера вне зависимости от того, к сети какого типа подключён адресат. Формат номера обычно соответствует рекомендации Е. 164. В настоящее время органами стандартизации разрабатываются ме­ханизмы преобразования телефонных номеров либо в IP-адреса, либо в унифицированные указатели ресурсов (URL).

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

Отображение телефонных номеров на URL немного упрощает про­блему преобразования адресов путём использования интернетов­ского ярлыка для идентификации пользователя. Однако, как только телефонный номер преобразован в ярлык, последний должен быть преобразован в адрес поставщика услуг Интернет, который, в свою очередь, формирует окончательный IP-адрес получателя. Наличие такого большого количества стадий, нужных, чтобы найти вызывае­мого абонента, будет, очевидно, существенно увеличивать время между набором номера вызывающим абонентом и получением им сигнала КПВ или зуммера «Занято».

В настоящее время органами стандартизации разрабатываются и другие механизмы, обеспечивающие надлежащую адресацию и маршрутизацию номеров Е. 164, однако простых и универсальных путей решения этой проблемы пока не видно. Вопрос преобразова­ния номера телефонной сети общего пользования в IP-адрес пред­ставляется пока еще довольно сложным, и пути его решения разра­батываются не только рабочей группой 4 в рамках проекта TIPHON, но и другими организациями, например IETF.

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

 

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

 

2.3        Установление телефонного соединения в IP-сети

 

Рассмотрим процедуру установления соединения через сеть IP при вызове с предоплатой или с оплатой после разговора. Для ор­ганизации такого соединения абонент А набирает местный теле­фонный номер шлюза своего поставщика услуг IP-телефонии. Або­ненту А передается второй сигнал ответа станции и предлагается ввести телефонный номер вызываемого абонента, номер счёта и пароль, если вызов производится не с домашнего, зафиксиро­ванного у поставщика телефона. Далее устанавливается соедине­ние со стороной вызываемого абонента В. На рис. 2.9 приведены компоненты IP-телефонии, которые обычно используются в таком соединении.

Рис. 2.9   Компоненты IP-телефонии

 

Одним из этих компонентов является шлюз Н.323, который слу­жит средством взаимодействия между ТфОП и IP-сетью. Преобра­зование адресной информации Е. 164 в IP-адрес и маршрутизацию вызова осуществляет привратник Н.323. Для конкретного сценария могут потребоваться и другие компоненты. Может потребоваться, на­пример, процедура обращения к поставщику услуг урегулирования (settlement provider) для того, чтобы обеспечить телефонные соеди­нения с абонентами в тех местах, где у данного поставщика услуг IP-телефонии нет физического присутствия. Поставщик услуг урегу­лирования обычно работает с несколькими поставщиками услуг IP-те­лефонии и следит за тем, какому из них, в каком регионе и по какой стоимости целесообразно перепоручить соединение.

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

На рис. 2.10, 2.11 и 2.12 более подробно представлена процеду­ра установления соединения для вызовов с предоплатой или с опла­той после разговора, являющаяся, в известном смысле, уточнением упрощенной процедуры на рис. 1.8 предыдущей главы. Рис. 2.10 от­ражает следующие стадии установления соединения.

1. Абонент А набирает местный номер доступа к шлюзу.

2. Шлюз запрашивает у специального сервера данные о вызываю­щем абоненте (по информации АОН или по идентификационному но­меру). Сервер может быть совмещен с привратником.

3. Сервер просматривает информацию АОН для того, чтобы убе­диться, что абоненту А разрешено пользоваться данной услугой, и за­тем передает к шлюзу сообщение аутентификации пользователя.

Рис. 2.10 Установление соединения: Часть 1

 

Рис. 2.11 отражает следующие стадии.

4. Абонент А набирает телефонный номер вызываемого абонента Б.

5. Шлюз консультируется с привратником о возможных способах маршрутизации вызова.

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

Рис. 2.11   Установление соединения: Часть 2

 

Финальные стадии установления соединения показаны на рис. 2.12:

 

7. Исходящий шлюз направляет вызов Н.323 по IP-сети к входящему шлюзу.

 

8. Входящий шлюз направляет вызов по сети ТфОП к вызываемому абоненту.

9. Шлюзы посылают на упоминавшийся ранее специальный сер­вер данные о начале/окончании установления соединения для начис­ления платы за связь.

 

Рис. 2.12  Установление соединения: Часть 3

2.4        Эффективность IP-телефонии

 

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

Предоставление телефонных услуг через инфраструктуру IP по­зволяет поставщику услуг IP получать большую, по сравнению с тра­диционными операторами, прибыль благодаря тому, что:

•   функции предоставления услуг телефонии и передачи данных объ­единяются в общей инфраструктуре IP; основной объём обслужи­ваемого трафика приходится на традиционные данные Интернет, а транспортировка относительно невысокого объёма трафика IP-телефонии может осуществляться с использованием той же ин­фраструктуры при очень незначительных дополнительных затра­тах,

•   отсутствует необходимость обеспечивать качество и объём услуг, требуемые от операторов ТфОП, что допускает реализацию услуг IP-телефонии на базе более дешёвого оборудования.

Для традиционных телефонных операторов IP-телефония также достаточно перспективна. Операторы ТфОП в США и Европе вкла­дывают значительные средства в создание развитой инфраструкту­ры IP и в привлечение на свою сторону поставщиков услуг Интернет.Так, например, компания US West Inc. (Инглвуд, Колорадо) объявила о проекте реализации технологии xDSL в масштабе всей страны, ком­пания WorldCom Inc. (Джексон, Миссисипи) уже владеет первым по­ставщиком услуг Интернет - Uunet Technologies Inc. (Фоллс Черч, Виргиния) - и намеревается приобрести фирму MCI Communications Corp. (Вашингтон, округ Колумбия).

Но мотивы такой тенденции не только в сокращении затрат на обслуживание трафика. В настоящее время минута телефонного раз­говора по сетям коммутации каналов внутри США обходится мест­ной телефонной компании примерно в 6 центов, а передача речи по Интернет стоит от 1 до 2 центов за минуту. Такая разница вряд ли достаточна для того, чтобы радикально перестроить инфраструкту­ру дальней связи, использующую технологию 1980-х годов, но по­требовавшую в свое время многомиллиардных затрат на цифровизацию сети. В свете этого, сегодняшняя ситуация с расценками на междугородную и международную телефонную связь кратковременна и в ближайшее время перестанет быть столь же важной причиной развития IP-телефонии, как это имело место на начальной стадии ее внедрения. Стратегические преимущества новой технологии заклю­чаются в конвергенции услуг, в создании интегрированных приложе­ний в конечных узлах. Контролируя технологии коммутации каналов и пакетов, можно приобрести гигантское преимущество (во всемир­ном масштабе) при вступлении в следующее столетие.

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

В этом направлении ведется разработка оборудования следую­щего поколения. Шлюзы (маршрутизаторы) располагаются только на краях сети, где должны приниматься наиболее часто сложные реше­ния и где должны вызываться наиболее используемые процессы, а далее развертываются высокоскоростные коммутаторы ATM, при­чем, в соответствии с проектными спецификациями, маршрутиза­торы и коммутаторы смогут работать со скоростью 1 Тбит/с. Если к этому добавить невероятно высокоскоростные системы оптоволо­конной передачи в сети, то перспектива представляется весьма оп­тимистичной. Каждое оптическое волокно в настоящее время может поддерживать не менее 32 световых волн (оптических частот), при­чем каждая запускается на скорости не менее 10 Гбит/с и поддержи­вает приблизительно 130,000 каналов передачи речевой информа­ции при стандартных скоростях 64 кбит/с. Вдоль маршрута уклады­ваются сотни оптических волокон.

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

Стала очевидной также избыточность традиционной передачи ре­чевой информации со скоростью 64 Кбит/с. Современные алгоритмы сжатия позволяют использовать для передачи речи полосу пропуска­ния 5,3 Кбит/с. По мере уменьшения требований к ширине полосы возрастает производительность, за тот же период времени по тем же каналам и через те же коммутаторы передается больше данных, и цены на телефонные разговоры снижаются. Соответствующие стандарты сжатия речи были разработаны уже в середине 90-х гг.

Это - рекомендация G.729, которая предусматривает 8-кратное сжатие речевого сигнала, что дает возможность передавать его в по­лосе 8 Кбит/с с тем качеством, которое поддерживают обычные те­лефонные сети. В основу стандарта положен алгоритм сжатия CS-ACELP. Последняя его версия, G.729A, использует тот же алгоритм, но упрощенный кодек, что значительно снижает нагрузку на процес­сор при обработке речевого потока.

Другая рекомендация - G.723.1 - позволяет сжимать речевой сиг­нал в 12 раз и транспортировать его со скоростью 5,3 или 6,3 Кбит/с. При этом качество передачи речи немного снижается, но остается вполне достаточным для делового общения. Для сжатия полосы до 5,3 Кбит/с применяется алгоритм ACELP, а до 6,3 Кбит/с-алгоритм MP-MLQ.

Общее правило гласит, что более «плотное» сжатие приводит к снижению качества речи, однако разработка все более сложных ал­горитмов компрессии делает это правило спорным. Выбор алгорит­ма обуславливается тремя основными факторами - распространен­ностью, поддержкой в имеющемся оборудовании и ожиданиями пользователей. На нынешнем этапе оба алгоритма хорошо себя по­казали и приняты производителями средств пакетной телефонии.

Отметим, что устройства, поддерживающие G.723.1, не могут «разговаривать» напрямую с устройствами на основе G.729; для их взаимодействия необходим специальный конвертер. Сигнальный процессор DSP, реализующий эти функции, может вносить задерж­ки и искажения, снижающие качество речи до неприемлемого уров­ня. Кроме того, современные технологии не способны производить такое преобразование в реальном времени. Более подробно эти во­просы рассматриваются в следующей главе.

 

Глава 3

Передача речи по IP-сетям

3.1  Особенности передачи речевой информации по IP – сетям

 

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

 

3.1.1           Задержки

 

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

 

Влияние сети

 

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

 

Влияние операционной системы

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

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

Из сказанного следует, что выбор операционной системы являет­ся важным фактором, влияющим на общую величину задержки. Что­бы минимизировать влияние операционной системы, некоторые про­изводители шлюзов и IP-телефонов используют так называемые ОС реального времени (VxWorks, pSOS, QNX Neutrino и т.д.), которые используют более сложные механизмы разделения времени процес­сора, действующие таким образом, чтобы обеспечивать значитель­но более быструю реакцию на прерывания и более эффективный обмен потоками данных между процессами.

Другой, более плодотворный подход - переложить все функции, которые необходимо выполнять в жестких временных рамках (обмен данными между речевыми кодеками и сетевым интерфейсом, поддержку RTP и т.д.), на отдельный быстродействующий специализи­рованный процессор. При этом пересылка речевых данных осуще­ствляется через выделенный сетевой интерфейс периферийного устройства, а операционная система рабочей станции поддержива­ет только алгоритмы управления соединениями и протоколы сигна­лизации, т.е. задачи, для выполнения которых жестких временных рамок не требуется. Этот подход реализован в платах для приложе­ний IP-телефонии, производимых фирмами Dialogic, Audiocodes, Natural Microsystems. По такой же технологии выполнен и шлюз IP-те­лефонии в платформе Протей-IP, что позволило обеспечить высокое качество передачи речи.

 

Влияние джиттер-буфера

 

Проблема джиттера весьма существенна в пакетно-ориентиро-ванных сетях. Отправитель речевых пакетов передает их через фик­сированные промежутки времени (например, через каждые 20 мс), но при прохождении через сеть задержки пакетов оказываются не­одинаковыми, так что они прибывают в пункт назначения через раз­ные промежутки времени. Это иллюстрирует рис. 3.1.

Рис. 3.1   Различие интервалов между

моментами прибытия пакетов (джиттер)

 

Задержка прохождения пакетов по сети Т может быть представ­лена как сумма постоянной составляющей Т (время распростране­ния плюс средняя длительность задержки в очередях) и переменной величины j, являющейся результатом джиттера: T = T±j.

Для того, чтобы компенсировать влияние джиттера, в терминалах используется т.н. джиттер-буфер. Этот буфер хранит в памяти при-/и бывшие пакеты в течение времени, определяемого его емкостью (длиной). Пакеты, прибывающие слишком поздно, когда буфер за­полнен, отбрасываются. Интервалы между пакетами восстанавлива­ются на основе значений временных меток RTP-пакетов. В функции джиттер-буфера обычно входит и восстановление исходной очеред­ности следования пакетов, если при транспортировке по сети они оказались «перепутаны».

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

Влияние кодека и количества передаваемых в пакете кадров

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

На первый взгляд, можно было бы заключить, что чем меньше дли­на кадра, тем меньше должна быть задержка. Однако, как будет по­казано ниже, из-за значительного объема служебной информации, передаваемой в RTP/UDP/IP-пакетах, передача маленьких порций данных очень неэффективна, так что при применении кодеков с ма­лой длиной кадра приходится упаковывать несколько кадров в один пакет. Кроме того, кодеки с большей длиной кадра более эффектив­ны, поскольку могут «наблюдать» сигнал в течение большего време­ни и, следовательно, могут более эффективно моделировать этот сигнал.

ITU-T в рекомендации G.114 определил требования к качеству передачи речи. Оно считается хорошим, если сквозная задержка при передаче сигнала в одну сторону не превышает 150 мс (рис. 3.2). Современное оборудование IP-телефонии при включении «спина к спине» (два устройства - шлюза - соединяются напрямую) вносит задержку порядка 60-70 мс. Таким образом, остается еще около 90 мс на сетевую задержку при передаче IP-пакета от отправителя к пункту назначения, что говорит о возможности обеспечить при современ­ном уровне технологии передачу речи с достаточно хорошим каче­ством.

Рис. 3.2 Задержка при передаче

 

Авторам отнюдь не хотелось бы, чтобы у читателя сложилось впе­чатление, будто временные задержки - проблема исключительно IP-телефонии. Именно поэтому на рис. 3.2 приведены также харак­теристики спутниковой передачи, при которой требуется примерно 250 мс для того, чтобы сигнал достиг спутника и вернулся обратно к Земле (без учета затрат времени на обработку сигнала). Таким об­разом, полное время задержки превышает 250-ЗООмс. Согласно ре­комендации G. 114, такая задержка выходит за границы диапазона, приемлемого для передачи речи. Тем не менее, ежедневно значи­тельное количество разговоров ведется по спутниковым линиям свя­зи. Следовательно, приемлемое качество речи определяется, преж­де всего, требованиями пользователей.

 

3.1.2 Эхо

 

Феномен эха вызывает затруднения при разговоре и у говоряще­го, и у слушающего. Говорящий слышит с определенной задержкой свой собственный голос. Если сигнал отражается дважды, то слушаю­щий дважды слышит речь говорящего (второй раз - с ослаблением и задержкой).

Эхо может иметь электрическую и акустическую природу.

Отражения в дифсистеме являются неотъемлемым свойством ТфОП. Поэтому они проявляются при взаимодействии ТфОП и IP-сетей.

С целью экономии кабеля в ТфОП для подключения абонентских терминалов с давних пор используются двухпроводные линии, по которым речевые сигналы передаются в обоих направлениях. Более того, во многих телефонных сетях передача сигналов обоих направ­лений по двум проводам используется и в соединительных линиях между электромеханическими АТС [6] (хотя теперь для организации связи между АТС всё чаще используется раздельная передача сиг­налов разных направлений, т.е. четырехпроводная схема их переда­чи). Для разделения сигналов разных направлений в терминалах або­нентов (телефонных аппаратах) и на АТС применяются простые мос­товые схемы, называемые дифеистемами (hybrid). Работа этих мостовых схем основывается на согласовании импедансов в плечах мос­та, одним из плеч которого является двухпроводная абонентская ли­ния. Так как абонентские линии могут очень сильно различаться по своим параметрам (длине, диаметру жил кабеля и т.п.), то достичь точного согласования (тем более, во всей полосе передаваемых час­тот) невозможно. Вместо этого администрация связи вынуждена ориентироваться на некоторую среднюю величину импеданса для всех абонентских линий своей национальной сети. Это приводит к то­му, что сигналы прямого и обратного направления в большинстве слу­чаев не разделяются полностью, и в дифсистеме возникает частич­ное отражение сигналов.

Если задержка распространения сигнала в сети невелика (что обычно и бывает в местных сетях), такой отраженный сигнал попро­сту незаметен и не вызывает неприятных ощущений. Если задержка достигает величины 15-20мс, возникает эффект «огромного пустого помещения». При дальнейшем увеличении задержки субъективная оценка качества разговора резко ухудшается, вплоть до полной не­возможности продолжать беседу.

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

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

 

3.1.3. Устройства ограничения эффектов эха

 

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

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

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

Рис. 3.3 Упрощенная блок-схема эхокомпенсатора

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

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

По изложенным выше причинам эхокомпенсаторы являются не­отъемлемой частью шлюзов IP-телефонии. Алгоритмы эхокомпенсации реализуются обычно на базе тех же цифровых сигнальных про­цессоров, что и речевые кодеки, и обеспечивают подавление эхо-сигналов длительностью до 32-64 мс. К эхокомпенсаторам терми­налов громкоговорящей связи предъявляются гораздо более стро­гие требования, которые здесь рассматриваться не будут, так как проблема акустического эха не входит в число проблем, специфиче­ских для IР-телефонии.

 

3.2    Принципы кодирования речи

 

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

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

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

При преобразовании речевого сигнала в цифровую форму, так или иначе, имеют место два процесса - дискретизаций (sampling), т.е. формирование дискретных во времени отсчетов амплитуды сигна­ла, и квантование, т.е. дискретизация полученных отсчетов по ам­плитуде (кодирование непрерывной величины - амплитуды - числом с конечной точностью). Эти две функции выполняются т.н. аналого-цифровыми преобразователями (АЦП), которые размещаются в со­временных АТС на плате абонентских комплектов, а в случае переда­чи речи по IP-сетям - в терминале пользователя (компьютере или IP-телефоне).

Так называемая теорема отсчетов гласит, что аналоговый сигнал может быть успешно восстановлен из последовательности выборок с частотой, которая превышает, как минимум, вдвое максимальную частоту, присутствующую в спектре сигнала. В телефонных сетях полоса частот речевого сигнала намеренно, посредством специаль­ных фильтров, ограничена диапазоном 0.3 - 3.4 кГц, что не влияет на разборчивость речи и позволяет узнавать собеседника по голосу. По этой причине частота дискретизации при аналого-цифровом преоб­разовании выбрана равной 8кГц, причем такая частота используется во всех телефонных сетях на нашей планете.

 

Рис. 3.4 Дискретизация и квантование аналогового речевого сигнала

 

При квантовании непрерывная величина отображается на множе­ство дискретных значений, что, естественно, приводит к потерям информации. Для того, чтобы обеспечить в такой схеме достаточ­ный динамический диапазон (способность передавать без искаже­ний как сильные, так и слабые сигналы), дискретная амплитуда сиг­нала кодируется 12/13-ти разрядным двоичным числом по линейно­му закону.

Процесс аналого-цифрового преобразования получил, приме­нительно к системам связи, название импульсно-кодовоймодуля­ции (ИКМ).

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

После длительных и бурных дебатов в отношении законов коди­рования сегодня применяются две основные разновидности ИКМ: с кодированием по μ- закону и по А-закону. В результате сжатия сиг­нал с амплитудой, кодируемой 12-13 битами, описывается всего восемью битами. Различаются эти разновидности ИКМ деталями процесса сжатия (μ-закон кодирования предпочтительнее использо­вать при малой амплитуде сигнала и при малом отношении сигнал/шум). Исторически сложилось так, что в Северной Америке ис­пользуется кодирование по μ-закону, а в Европе - по А-закону. По­этому при международной связи во многих случаях требуется пре­образование (μ- закона в А-закон, ответственность за которое несет страна, в которой используется μ- закон кодирования. В обоих слу­чаях каждый отсчет кодируется 8 битами, или одним байтом, кото­рый можно считать звуковым фрагментом. Для передачи последо­вательности таких фрагментов необходима пропускная способность канала, равная 64 Кбит/с. Это определяется простыми арифметиче­скими действиями:

4 000 Гц  *2 = 8 000 отсчетов/с, 8 000 отсчетов/с * 8 битов = 64 Кбит/с, что составляет основу всей цифровой телефонии. Поскольку ИКМ была первой стандартной технологией, получившей широкое приме­нение в цифровых системах передачи, пропускная способность ка­нала, равная 64 Кбит/с, стала всемирным стандартом для цифровых сетей всех видов, причем - стандартом, который обеспечивает пе­редачу речи с очень хорошим качеством. Соответствующие проце­дуры кодирования и декодирования стандартизованы ITU-T в реко­мендации G.71 1.

Однако такое высокое качество передачи речевого сигнала (яв­ляющееся эталоном при оценке качества других схем кодирования) достигнуто в системах ИКМ за счет явно избыточной, при современ­ном уровне технологии, скорости передачи информации.

Чтобы уменьшить присущую ИКМ избыточность и снизить требо­вания к полосе пропускания, последовательность чисел, полученная в результате преобразования речевого аналогового сигнала в циф­ровую форму, подвергается математическим преобразованиям, по­зволяющим уменьшить необходимую скорость передачи. Эти пре­образования «сырого» цифрового потока в поток меньшей скорости называют «сжатием» (а часто - кодированием, рассматривая ИКМ как некую отправную точку для дальнейшей обработки информации). Существует множество подходов к «сжатию» речевой информа­ции; все их можно разделить на три категории: кодирование формы сигнала (waveform coding), кодирование исходной информации (source coding) и гибридное кодирование, представляющее собой сочетание двух предыдущих подходов.

 

3.2.1           Кодирование формы сигнала

 

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

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

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

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

Если отсчеты входного сигнала обозначить как y(i), то предска­занное значение в момент времени i представляет собой линейную комбинацию нескольких р предыдущих отсчетов:

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

Разность имеет меньший динамический диапазон и может кодироваться меньшим числом битов, что позволяет сни­зить требования к полосе пропускания.

Описанный метод называется линейным предсказанием, так как он использует только линейные функции предыдущих отсчетов. Ко­эффициенты предсказания выбираются так, чтобы минимизировать среднеквадратическое значение ошибки предсказания e(i), при этом значения коэффициентов изменяются, в среднем, каждые 10-25 мс.

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

Наиболее совершенным алгоритмом, построенным на описан­ных выше принципах, является алгоритм адаптивной дифференци­альной импульсно-кодовой модуляции (АДИКМ), предложенный ITU-T в рекомендации G.726. Алгоритм предусматривает формиро­вание сигнала ошибки предсказания и его последующее адаптив­ное квантование. Существует версия этого алгоритма, в которой ин­формационные биты выходного цифрового потока организованы по иерархической схеме, что позволяет отбрасывать наименее значи­мую информацию, не уведомляя об этом кодер, и получать поток меньшей скорости за счет некоторого ухудшения качества. Доку­мент G.726 специфицирует кодирование при скоростях 40, 32, 24 и 16 Кбит/с, что соответствует передаче 5, 4, 3 или 2 битов на от­счет. Качество речи, передаваемой с использованием АДИКМ G.726 при скорости 32 Кбит/с соответствует качеству речи, обеспечивае­мому алгоритмом кодирования G.711.

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

 

3.2.2           Кодеры исходной информации (вокодеры) и гибридные алгоритмы

 

Многие методы кодирования используют особенности человече­ской речи, связанные со строением голосового аппарата. Кодеры, в которых реализуются такие методы, называют кодерами исходной информации или вокодерами (voice coding).

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

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

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

Рис. 3.5   Модель функционирования голосового тракта

 

Описанный принцип кодирования получил название LPC (Linear Prediction Coding - кодирование с линейным предсказанием), по­скольку центральным элементом модели голосового тракта являет­ся линейный фильтр. Наиболее известный стандартный алгоритм, по­строенный по описанному принципу, был стандартизован министер­ством обороны США под названием LPC-10, где число 10 соответст­вует количеству коэффициентов фильтра. Данный кодер обеспечи­вает очень низкую скорость передачи информации 2.4 Кбит/с, одна­ко качество воспроизводимых речевых сигналов оставляет желать лучшего и не удовлетворяет требованиям коммерческой речевой связи - речь носит ярко выраженный «синтетический» характер.

Как уже отмечалось, алгоритмы кодирования формы сигнала ос­нованы на наличии корреляционных связей между отсчетами сигна­ла, которые дают возможность линейного предсказания. В сочета­нии с адаптивным квантованием этот подход позволяет обеспечить хорошее качество речи при скорости передачи битов порядка 24-32 Кбит/с. LPC-кодеры (вокодеры) используют простую математическую модель голосового тракта и позволяют использовать очень низкие скорости передачи информации 1200-2400 бит/с, однако це­ной «синтетического» характера речи.

Гибридные алгоритмы кодирования и алгоритмы типа «анализ путем синтеза» (ABS) представляют собой попытки совместить по­ложительные свойства двух описанных выше основных подходов и строить эффективные схемы кодирования с диапазоном скоростей передачи битов6-16Кбит/с.

Важное отличие кодеров такого типа состоит в том, что в рамках этих алгоритмов нет необходимости принимать решение о типе вос­производимого звука (тоновый или нетоновый), так как предусмат­риваются специальные меры для кодирования сигнала ошибки по­сле прохождения возбуждения через LPC-фильтр. Например, сигнал ошибки может быть закодирован по алгоритму, аналогичному АДИКМ, что обеспечит высокую точность его передачи. ABS-кодеры не могут быть строго классифицированы как кодеры формы сигна­ла, однако реально целью процедуры минимизации ошибки (рис. 3.6), т.е. различия между входным и синтезированным сигналами, явля­ется синтез на выходе кодера сигналов, форма которых наиболее близка к форме входных. ABS-декодер является малой частью коде­ра и очень прост (рис. 3.7).

 

 

3.2.3.                      Процессоры цифровой обработки сигналов для речевых кодеков

 

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

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

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

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

Существует множество модификацией процессоров DSP, разли­чающихся производительностью, объемом памяти, потребляемой мощностью. В оборудовании IP-телефонии используются дешевые процессоры со средней производительностью и малой потребляе­мой мощностью, ориентированные на реализацию малого числа (единицы) каналов обработки речевой информации и применяемые, в основном, в составе терминальных устройств, или мощные высо­копроизводительные процессоры, ориентированные на многока­нальные (десятки каналов) приложения и используемые в составе таких групповых устройств как многоканальные шлюзы IP-телефо­нии, подключаемые к ТфОП по цифровым трактам Е1.

Одними из самых известных производителей DSP являются фир­мы Texas Instruments (www.ti.comi ). Analog Devices (www.analoa.com ) Motorola (www.motorola.com    ), на сайтах которых можно получить до­полнительную информацию о номенклатуре DSP и об их применении.

Оборудование ПРОТЕЙ-IP использует DSP с лицензированным у од­ной из ведущих в данной области фирм программным обеспечением, реализующим необходимые алгоритмы (речевые кодеки, факс, мо­дем). Это позволило, опираясь на существующий опыт, резко сокра­тить время выхода оборудования на рынок. Кроме того, в данном слу­чае исключается трудоемкая и длительная процедура лицензирова­ния алгоритмов речевых кодеков {G.723.1, G.729), требующая значи­тельных единовременных финансовых затрат. По такому же пути идут и ведущие мировые производители оборудования VoIP (Cisco, Dialog­ic и др.), лицензируя программное обеспечение DSP у компаний, спе­циализирующихся именно в этой области, и концентрируя свои силы на реализации тех функций, которые традиционно обеспечивают дан­ным производителям оборудования технологическое лидерство.

 

3.2.4   Основные алгоритмы кодирования речи, используемые в IP-телефонии

 

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

Использование полосы пропускания канала

Скорость передачи, которую предусматривают имеющиеся сего­дня узкополосные кодеки, лежит в пределах 1.2 - 64 Кбит/с. Естест­венно, что от этого параметра прямо зависит качество воспроизво­димой речи. Существует множество подходов к проблеме определе­ния качества. Наиболее широко используемый подход оперирует оцен­кой MOS (Mean Opinion Score), которая определяется для конкретно­го кодека как средняя оценка качества большой группой слушателей по пятибалльной шкале. Для прослушивания экспертам предъявляют­ся разные звуковые фрагменты - речь, музыка, речь на фоне различ­ного шума и т.д. Оценки интерпретируют следующим образом:

•   4-5 - высокое качество; аналогично качеству передачи речи в ISDN, или еще выше;

•   3.5-4 - качество ТфОП (toll quality); аналогично качеству речи, пе­редаваемой с помощью кодека АДИКМ при скорости 32 Кбит/с. Такое качество обычно обеспечивается в большинстве телефон­ных разговоров. Мобильные сети обеспечивают качество чуть ниже toll quality;

•   3-3.5- качество речи, по-прежнему, удовлетворительно, однако его ухудшение явно заметно на слух;

•   2.5-3 - речь разборчива, однако требует концентрации внима­ния для понимания. Такое качество обычно обеспечивается в сис­темах связи специального применения (например, в вооруженных силах).

В рамках существующих технологий качество ТфОП (toll quality) невозможно обеспечить при скоростях менее 5 Кбит/с.

Подавление периодов молчания (VAD, CNG, DTX)

 При диалоге один его участник говорит, в среднем, только 35 про­центов времени. Таким образом, если применить алгоритмы, кото­рые позволяют уменьшить объем информации, передаваемой в пе­риоды молчания, то можно значительно сузить необходимую полосу пропускания. В двустороннем разговоре такие меры позволяют дос­тичь сокращения объема передаваемой информации до 50%, а в де­централизованных многоадресных конференциях (за счет большего количества говорящих) - и более. Нет никакого смысла организовы­вать многоадресные конференции с числом участников больше 5-6, не подавляя периоды молчания. Технология подавления таких перио­дов имеет три важные составляющие.

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

Детектор речевой активности (Voice Activity Detector - VAD) необ­ходим для определения периодов времени, когда пользователь говорит. Детектор VAD должен обладать малым временем реакции, что­бы не допускать потерь начальных слов и не упускать бесполезные фрагменты молчания в конце предложений; в то же время детектор VAD не должен срабатывать от воздействия фонового шума.

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

Поддержка прерывистой передачи (Discontinuous Transmission -DTX) позволяет кодеку прекратить передачу пакетов в тот момент, когда VAD обнаружил период молчания. Некоторые наиболее совер­шенные кодеры не прекращают передачу полностью, а переходят в режим передачи гораздо меньшего объема информации (интенсив­ность, спектральные характеристики), нужной для того, чтобы деко­дер на удаленном конце мог восстановить фоновый шум.

Генератор комфортного шума (Comfort Noise Generator - CNG) служит для генерации фонового шума. В момент, когда в речи актив­ного участника беседы начинается период молчания, терминалы слу­шающих могут просто отключить воспроизведение звука. Однако это было бы неразумно. Если в трубке возникает «гробовая тишина», т.е. фоновый шум (шум улицы и т.д.), который был слышен во время раз­говора, внезапно исчезает, то слушающему кажется, что соединение по каким-то причинам нарушилось, и он обычно начинает спраши­вать, слышит ли его собеседник.

Генератор CNG позволяет избежать таких неприятных эффектов. Простейшие кодеки просто прекращают передачу в период молча­ния, и декодер генерирует какой-либо шум с уровнем, равным мини­мальному уровню, отмеченному в период речевой активности. Бо­лее совершенные кодеки (G.723.1 Annex A, G.729 Annex В) имеют воз­можность предоставлять удаленному декодеру информацию для вос­становления шума с параметрами, близкими к фактически наблю­давшимся.

 

Размер кадра

 

Большинство узкополосных кодеков обрабатывает речевую ин­формацию блоками, называемыми кадрами (frames), и им необхо­димо производить предварительный анализ отсчетов, следующих непосредственно за отсчетами в блоке, который они в данный мо­мент кодируют.

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

Можно, казалось бы, заключить, что кодеки с меньшим размером кадра лучше в смысле такого важного критерия как минимизация за­держки. Если, однако, учесть, что происходит при передаче информа­ции по сети, то мы увидим, что к кадру, сформированному кодеком, добавляется множество дополнительной информации - заголовки IP (20 байтов), UDP (8 байтов), RTP (12 байтов). Для кодека с длительно­стью кадра 30 мс посылка таких кадров по сети привела бы к переда­че избыточной информации со скоростью 10.6 кбит/с, что превышает скорость передачи речевой информации у большинства узкополос­ных кодеков.

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

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

 

Чувствительность к потерям кадров

 

Потери пакетов являются неотъемлемым атрибутом IP-сетей. Так как пакеты содержат кадры, сформированные кодеком, то это вы­зывает потери кадров. Но потери пакетов и потери кадров не обязательно напрямую связаны между собой, так как существуют подходы (такие как применение кодов с исправлением ошибок -forward error correction), позволяющие уменьшить число потерян­ных кадров при данном числе потерянных пакетов. Требующаяся для этого дополнительная служебная информация распределяется ме­жду несколькими пакетами, так что при потере некоторого числа пакетов кадры могут быть восстановлены.

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

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

Влияние потерь кадров на качество воспроизводимой речи за­висит от используемого кодека. Если потерян кадр, состоящий из N речевых отсчетов кодека G.711, то на приемном конце будет от­мечен пропуск звукового фрагмента длительностью N*125 мкс. Если используется более совершенный узкополосный кодек, то потеря одного кадра может сказаться на воспроизведении не­скольких следующих, так как декодеру потребуется время для того, чтобы достичь синхронизации с кодером - потеря кадра длитель­ностью 20 мс может приводить к слышимому эффекту в течение 150 мс и более.

Кодеры типа G.723.1 разработаны так, что они функционируют без существенного ухудшения качества в условиях некоррелированных потерь до 3% кадров, однако при превышении этого порога качест­во ухудшается катастрофически.

 

3.3   Кодеки, стандартизованные ITU-T

 

3.3.1                  кодек G. 711

 

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

 

3.3.2                  КодекС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-T G.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 Labs в 1992 году: кодер имеет длительность кадра только 0.625 мс. Реально задержка может достигать 2.5 мс, так как декодер должен поддерживать синхронизацию в рамках струк­туры из четырех кадров.

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

 

3.3.5  Кодек G.729

 

Кодек G.729 очень популярен в приложениях передачи речи по се­тям Frame Relay. Он использует технологию CS-ACELP (Conjugate Struc­ture, 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

 

В рамках деятельности европейского института ETS1 стандарти­зованы узкополосные кодеки для применения в системах мобильной связи (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-Ти ETSI, не были упомянуты ит.н. нестан­дартные кодеки.

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

 

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

 

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

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

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

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

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

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

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

Шлюзы 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 предусматривает использование особого про­токола IFR цель которого - перенос сообщений между шлюзами и/или компьютерами. Сообщения IFR в свою очередь, могут передаваться внутри TCP-соединения или с использованием UDR причем в послед­нем случае предусматривается введение информационной избыточ­ности, обеспечивающей восстановление одиночных потерянных па­кетов. Использование протокола Т.38 закреплено в рамках рекомен­дации Н.323. Обязательным условием является поддержка протоко­ла TCP для переноса информации IFR а использование протокола UDP является лишь возможным вариантом. Информация IFP пере­дается по двум логическим каналам (от отправителя к получателю и в обратном направлении). Когда в качестве транспорта применя­ется протокол TCP, существует два возможных варианта: передавать сообщения IFR используя их туннелирование в канале Н.225.0/Q.931, или использовать для этого выделенное соединение.

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

 

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

 

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

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

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

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