Голосовые услуги в сети следующего поколения

Как в будущем будут предоставляться голосовые услуги и каким образом потребуется изменить корпоративные сети для их поддержки?

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

Но прежде чем «браться за гуж», администраторам и планировщикам сетей необходимо сориентироваться в быстро меняющемся ландшафте сетей следующего поколения. Прежде всего, им требуется понять, чем отличаются базовые телефонные услуги от расширенных? Затем, что такое новые протоколы, с помощью которых эти новые голосовые услуги будут предоставляться? Далее, как эти протоколы будут реализовываться? И, наконец, как будет выглядеть сетевая архитектура для предоставления новых услуг?

НАСЛЕДСТВО ТЕЛЕФОННЫХ СЕТЕЙ

Рисунок 1. Модель телефонной сети общего пользования и интеллектуальной сети.

Ни для кого не новость, что сетевой ландшафт меняется очень быстро. Современная телефонная сеть общего пользования состоит из множества коммутаторов (Классов 4 и 5), цифровых кроссов, мультиплексоров, оборудования передачи SONET/SDH и корпоративных УАТС (см. Рисунок 1). Она также имеет сервисный уровень, известный как интеллектуальная сеть (Advanced Intelligent Network, AIN). AIN обладает определенными интеллектуальными функциями, но не независимостью от поставщиков.

Независимость услуг обеспечивается в AIN за счет отделения узлов коммутации сервиса (Service Switching Point, SSP) от узлов управления сервисом (Service Control Point, SCP). Это было сделано в целях переноса интеллектуальных функций с коммутирующих платформ SSP в их архитектуру баз данных. Однако концепция AIN появилась гораздо позже самих телефонных сетей. В результате введение новых услуг происходит чрезвычайно медленно и обходится дорого.

AIN иногда путают с системой сигнализации номер 7 (Signaling System 7, SS7). Протокол SS7 служит для отделения управления носителем (полезной нагрузкой телефонного звонка) от управления сигнализацией (установлением и разрывом соединения и услуг) в сервисной сети AIN. В AIN эти проблемы решаются вынесением услуг за пределы сетевой инфраструктуры. SSP обрабатывают обычный голосовой трафик, в то время как SCP отвечают за предоставление услуг. Сеть SS7 доставляет управляющие сигналы и другую информацию от SSP к SCP и обратно.

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

Однако производители оборудования вынуждены были адаптировать модель для своих имеющихся в наличии продуктов. Чтобы ее реализовать, они ограничились упрощенной версией, где было оставлено только преобразование телефонных номеров и исключена поддержка более развитых возможностей. И хотя все реализации опирались преимущественно на стандарты, каждый производитель воплощал в своих коммутаторах и SCP собственную несколько отличную от прочих модель вызова. В результате оператор, у которого имелись коммутаторы 5ESS производства Lucent Technologies в одной части сети и DMS-100S производства Nortel Networks в другой, вынужден был адаптировать их друг к другу, часто безуспешно.

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

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

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

БАЗОВЫЕ И РАСШИРЕННЫЕ УСЛУГИ

Базовые услуги — это контроль вызовов, идентификация и защита, биллинг и управление пропускной способностью. Сегодня эти сервисы функционируют вполне удовлетворительно, так что у сетевых администраторов нет побудительных причин для полного отказа от услуг обычной аналоговой телефонной сети (Plain Old Telephone System, POTS).

Модель новых расширенных услуг появилась в результате стремления преодолеть ограничения базовых сервисов и создать сеть следующего поколения (Next-Generation Network, NGN). Расширенные услуги включают организацию конференций, службу каталогов, унифицированный или усовершенствованный обмен сообщениями и интегрированный голосовой ответ. Такие популярные услуги телефонной сети, как номер 911 и Caller ID, также будут включены в число сервисов NGN.

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

Основополагающим протоколом является H.323, находящийся под юрисдикцией ITU. Разработка этого протокола заняла очень много времени, и он имеет очень сложную структуру. Многие считают, что H.323 будет использоваться главным образом для видео и что ему не суждено стать стандартом де-факто в мире передачи речи и данных. К тому же он пользуется ограниченной поддержкой со стороны поставщиков, за исключением видео и привратников. Однако H.323 идеально подходит для поддержки VoIP с унаследованной инфраструктурой ISDN.

Прогресс сдерживают также неразрешенные вопросы патентов. Такие проблемы, как время установления соединения, по-прежнему не решены. Однако наиболее важным вопросом остается отсутствие межсетевых интерфейсов и механизмов предотвращения перегрузок. Сегодня ITU не поспевает за развитием Internet, и, вероятно, область применения H.323 действительно ограничится видео, и он уступит место протоколу управления шлюзами между разными средами (Media Gateway Control, MeGaGo, также известному как H.248) и протоколу инициирования сеансов (Session Initiation Protocol, SIP).

ПРОТОКОЛЫ УПРАВЛЕНИЯ VOIP

В этом разделе мы рассмотрим некоторые из управляющих протоколов VoIP (в противовес среде передачи). Условно их можно разделить на три основные категории.

Во-первых, это управление устройствами. Оно применяется в ситуациях, когда интеллектуальные (или управляющие) функции не связаны с функциями передачи данных в сети. Ключевой атрибут этого интерфейса — взаимодействие в соответствии с моделью главный/подчиненный. Интеллектуальный компонент является главным и имеет абсолютный контроль над тем, что должно быть сделано. Компонент среды передачи играет подчиненную роль и выполняет все получаемые команды. Во многих ситуациях протокол по типу главный/подчиненный представляется полезным и даже необходимым. Например, шлюзу SS7 для базового пула модемов требуется абсолютный контроль над модемами с возможностью их опроса о текущем состоянии и перевода в исходное состояние по окончании звонка.

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

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

НОВЫЕ ПРОТОКОЛЫ

Протокол управления шлюзами между средами передачи (Media Gateway Control Protocol, MGCP) был предложен группой, теперь именуемой International SoftSwitch Consortium. Эта группа начиналась с Level 3 (в результате приобретения последней Xcom) и Telcordia (BellCore). В середине 1998 года Level 3 создала технический консультативный комитет (Technical Advisory Council, TAC), куда входили около десятка ведущих производителей коммуникационного оборудования, и предложила протокол управления устройствами IP (Internet Protocol Device Control, IPDC). Тем временем Telcordia разработала простой протокол управления шлюзами (Simple Gateway Control Protocol, SGCP). После того как IETF сформировала рабочую группу MeGaGo, протоколы были объединены, в результате чего и появился MGSP.

MGCP был представлен на рассмотрение рабочей группе MeGaGo. Между тем Lucent Technologies предложила третий протокол, под названием протокол управления устройствами среды передачи (Media Device Control Protocol, MDCP), и в результате слияния всех предложений образовался новый, усовершенствованный протокол, названный MeGaGo (он также известен как H.248).

Протокол MeGaGO прекрасно подходит для предоставления комплексных — как базовых, так и расширенных — услуг индивидуальным пользователям и малым компаниям. Его сила — в принципах функционирования протокола. Он создавался исходя из предположения, что клиенты могут поддерживать лишь самые простейшие операции обычной телефонной сети (интеллектуальный клиент, наподобие ПК или телефона, не нужен) и что интеллект сети сосредоточен на АТС. Протокол MeGaGo заменяет собой используемую во многих испытаниях VoIP модель привратников H.323. Он трансформирует внутренние сложные механизмы телефонной сети на границе сети провайдера услуг с помощью множества управляемых шлюзов на телефонной станции на базе IP.

Например, пользователи могут сохранить имеющиеся телефоны или УАТС и тем не менее подключиться к сети следующего поколения или интегрированному коммутатору. Эти коммутаторы поддерживают преобразование речи в данные и подключаются со стороны заказчика к стандартному голосовому оборудованию коммутации каналов. Интегрированный коммутатор преобразует коммутируемые телефонные вызовы в IP и использует MGCP для сигнализации или установления соединения через облако IP.

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

В марте 1999 года на заседании IETF было достигнуто общее техническое соглашение в отношении протокола с учетом основных требований MeGaGo и ITU-T SG16. Это открыло путь к формальному соглашению между IETF и ITU о совместной стандартизации единого протокола. В документах IETF он называется MeGaGo, а в документах ITU — H.GCP. За прошедший год рабочие группы получили множество предложений и дополнений от компаний, так что результат отражает общее мнение отрасли.

На июльском заседании 1999 года была согласована техническая спецификация MeGaGo/H.GCP. В настоящее время протокол в достаточной мере проработан, чтобы его можно было реализовать и протестировать на совместимость. Некоторые компании уже приступили к испытанию опытных реализаций протокола MeGaGo, так что тестирование на совместимость не за горами. Первые же коммерческие продукты должны появиться в начале 2000 года.

Некоторые отраслевые форумы (в частности, International SoftSwitch Consortium, ISC) тем временем взяли на вооружение промежуточные версии протокола (такие, как MGCP 1.5 или SGCP), не дожидаясь окончательного принятия протокола MeGaGo. Теперь ясно, что такие решения могут рассматриваться только в качестве временной меры и что протокол MeGaGo может быть реализован в широких масштабах практически немедленно. Весьма вероятно, что MeGaGo быстро получит распространение, потому что по сравнению с предварительными протоколами он обладает рядом преимуществ. Так, MeGaGo разрабатывался в расчете как на среды с установлением соединения, такие, как Time Division Multiplexing (TDM) и ATM, так и на среды без установления соединения, в частности IP. В результате протокол применим к гораздо более широкому спектру шлюзов между средами передачи. Кроме того, MeGaGo создавался в расчете на поддержку шлюзов как с тысячами портов, так и с одним портом, как у IP-телефона.

Рисунок 2. Модель с простым клиентом на базе протокола управления шлюзами между средами передачи.

Рынок для протокола MeGaGo, т. е. для модели простого клиента (см. Рисунок 2), будут составлять первые реализаторы передачи речи по сетям КТВ. Кабельный модем — достаточно неинтеллектуальное устройство. Оно не содержит коммутатора или большого программного стека: его достаточно установить, и оно будет работать. Операторы КТВ хотели бы иметь ту же самую модель и в случае передачи голоса по кабельной сети.

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

SIP В СРАВНЕНИИ С H.323

Для предоставления нетривиальных и расширенных услуг, таких, как поддерживаемые УАТС, клиент должен быть более интеллектуальным. Это требует более эффективного протокола. Отрасль начинает склоняться в пользу SIP, протокола расширенных услуг при равноправных или распределенных взаимоотношениях. Кроме того, ряд производителей, а также решившие реализовать его операторы поддерживают интеллектуальный протокол на базе SIP для оконечных и городских телефонных станций.

Тестирование и испытание SIP находятся на ранних стадиях, но протокол прекрасно подходит помимо передачи речи для предоставления новых услуг. Основные возможности включают мобильность, новые персональные идентификационные номера (Personal Identification Number, PIN), VPN на базе IP, виртуальные УАТС (иногда называемые IP Centrex или Webex), частные планы нумерации, функции УАТС и сквозной контроль со стороны пользователя за конференциями, переводом звонков, защитой, шифрованием, переадресацией и последовательностью звонков. SIP разрабатывался для интеграции передачи речи в инфраструктуру IP. Он позволяет отделить коммутирующую инфраструктуру от предоставления услуг.

Сравнение SIP с H.323 весьма поучительно. По сути, H.323 — это целый комплекс протоколов, хотя все они часто именуются просто H.323. Изначально спецификация H.323 разрабатывалась в целях поддержки видеоконференций в локальных сетях. Используя одноранговый протокол, интеллектуальные клиенты могли установить соединение с другими интеллектуальными клиентами. Расширения протокола предусматривали введение привратника для мониторинга трафика в локальной сети и разрешения установления соединения только при наличии у сети достаточных ресурсов для его поддержки. В крупных сетях привратник выполнял также функцию «разрешение адреса». Последующие версии H.323 предусматривали Gatekeeper Routed Model, в соответствии с которой привратник должен был принимать активное участие в установлении всех соединений и предоставлении услуг для каждого вызова. При такой модели H.323 больше не является одноранговым протоколом. Шлюз берет на себя многие традиционные интеллектуальные функции централизованного предоставления услуг.

Как H.323, так и SIP имеют своих сторонников, причем оба рассматриваются как ответ на запросы VoIP. Оба имеют свои достоинства и недостатки, по крайней мере, в своем нынешнем виде. Главное преимущество H.323 в том, что протокол уже существует (на самом деле, ему уже несколько лет). Версия 2 уже готова, а над версией 3 ведутся работы. Вследствие того, что H.323 разрабатывался ITU, значительные усилия были потрачены на определение дополнительных голосовых услуг. В настоящее время H.323 определяет множество голосовых услуг, хотя еще большее число ждет своего часа.

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

Наконец, H.323 был изначально определен как одноранговый протокол для локальных сетей, и пока он не имеет межсетевого интерфейса, отличного от межпользовательского (или однорангового), и не обеспечивает контроля за перегрузками. Для надлежащего функционирования телефонных сервисов и соблюдения корпоративных требований необходим четкий межсетевой протокол. Его отсутствие не составляет проблемы в случае частных сетей, голосовых звонков с компьютера на компьютер и даже многих международных звонков. Однако если операторы хотят создать сети для предоставления услуг в масштабах всей страны или для обеспечения соединения между телефонными сетями, то этот вопрос приобретает критическое значение. В последнее время многие провайдеры услуг начали отказываться от H.323 в пользу SIP именно в силу названных причин.

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

SIP отличается от H.323 во многих отношениях. SIP был стандартизован совсем недавно и опубликован в качестве RFC только в этом году. Работа над определением дополнительных голосовых услуг находится пока на ранней стадии. Однако ввиду того, что SIP целиком базируется на протоколах Internet (в частности, HTTP), он открывает гораздо более короткий путь к интеграции голосовых и информационных сервисов. SIP позволяет без труда реализовать такие возможности, как загрузка специфического пользовательского интерфейса на IP-терминал. Кроме того, добавление новых сервисных возможностей и расширение протокола можно осуществлять без угрозы создать проблемы в области совместимости, так как спецификация SIP опирается на принципы Internet.

Наконец, пресловутый вопрос межсетевого интерфейса. Как и H.323, SIP не имеет четко определенного межсетевого интерфейса. Однако рабочая группа MMUSIC в рамках SIP Best Current Practices for Telephony начала работу над совместным использованием SIP и MeGaGo в сетях в целях скорейшего решения этого вопроса. Это должно позволить создать сети, удовлетворяющие нормативным требованиям в отношении межсоединения телефонных сетей и в то же время предоставляющие инфраструктуру, способствующую переходу к распределенной модели оказания услуг на базе SIP.

ИНТЕЛЛЕКТУАЛЬНЫЕ КЛИЕНТЫ

Рисунок 3. Модель с интеллектуальным клиентом на базе протокола инициирования сеансов (SIP).

Модель с интеллектуальными клиентами наилучшим образом подходит для передачи информации в бизнесе и для индивидуальных пользователей/малых компаний (см. Рисунок 3). Эта модель означает, что на предприятии клиент будет иметь необходимый интеллект для поддержки расширенных услуг. Поддержка может осуществляться на уровне телефона с установленным на нем SIP или шлюза расширенных услуг (Enhanced Services Gateway, ESG), причем последний может заменить собой маршрутизаторы, УАТС и коммутаторы локальной сети с установленным на них SIP. Соединением с телефонной станцией может быть любой информационный канал на базе IP с поддержкой необходимого качества обслуживания и классов сервиса.

Поддержка новых сервисов может потребовать как самых незначительных, так и весьма существенных изменений в телефонной среде. В простейшем случае пользователи могут сохранить имеющиеся УАТС или обычные телефоны и установить ESG для преобразования традиционной телефонной сигнализации в сигнализацию на базе SIP для телефонов с поддержкой SIP, трафик которых передается по стандартным кабелям для Ethernet. Самое интересное, что сеть на базе SIP может выглядеть как IP-сервис Centrex, со множеством привлекательных функций, когда пользовательские телефон и ПК функционируют в соответствии с общим набором протоколов и могут как поддерживаться сетью оператора, так и полностью обходиться без нее. Помните, что SIP является одноранговым протоколом. Решение, какие сервисы выбрать и реализовать, остается за архитектором сети.

ЧТО ДАЛЬШЕ?

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

«Расширенные услуги имеют важнейшее значение для сохранения прибыльности общедоступных сетей. Жесткая конкуренция и внедрение передовых технологий передачи ведут к снижению цен на пропускную способность. Как в случае голоса, так и в случае данных стабильный доход может гарантировать только наличие модернизируемых и расширяемых средств и каналов связи вкупе с предложением расширенных услуг (и, естественно, со взиманием платы за них)», — считает Иак Эллиот, вице-президент SoftSwitch Services в Level 3 и соучредитель International SoftSwitch Consortium.

Однако, что касается предоставления расширенных услуг, это легче сказать, чем сделать. В большинстве сетей внедрение новой услуги означает модификацию или замену функционирующих коммутаторов (УАТС) и устройств доступа на новые устройства на базе передачи пакетов — процесс длительный и дорогостоящий. Чтобы услуга была прибыльной, операторы сетей должны иметь возможность реализовывать новые сервисы, не затрагивая коммутирующую инфраструктуру сети. Это означает создание открытой стандартизованной архитектуры на базе соответствующих протоколов, таких, как SIP, аналогично модели, принятой в Internet. В результате пользователи получат возможность использовать новые голосовые сервисы, предлагаемые провайдерами, и обращаться к новым сторонним услугам с помощью технологий наподобие апплетов Java.

Рисунок 4. Архитектура уровня новых расширенных услуг.

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

К счастью, крупнейшие производители (Lucent, Cisco, Nortel, Ericsson, 3Com, UniSphere и т. д.) поддерживают SIP. Ряд новых игроков (Convergent, Sonus, Oresis, Taqua, TransMedia, Castle, Pingtel, Merlot и др.) также поддерживают протокол на базе SIP. Одни разработчики, как BroadSoft, создают комплекты программного обеспечения для создания и предоставления услуг, с помощью которых новые услуги можно внедрить за дни, а не за годы, а другие разработчики, как Vovida Networks, предоставляют бесплатное программное обеспечение MGCP и SIP всем желающим.

Отделение сервисного уровня от сетевой инфраструктуры дает ряд существенных преимуществ (см. Рисунок 4). Новые услуги можно будет вводить без каких-либо изменений в сетевых устройствах, а провайдеры услуг будут в меньшей мере зависеть от производителей оборудования в деле предоставления услуг. Кроме того, поддержка услуг будет реализована одинаково в оборудовании разных производителей и в сетях на базе разных технологий. Более того, введенные услуги останутся неизменными при изменении сетевой технологии. Наконец, время и стоимость создания и поддержания новых услуг радикально уменьшатся.

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

Тим Краски — основатель и главный партнер консалтингового агентства Mentor Group. С ним можно связаться по адресу: tim@mentorgp.com. Джим МакИчерн — директор по архитектуре в группе IP-сервисов и продуктов на базе правил в Nortel Networks. С ним можно связаться по адресу: jmceach@nortelnetworks.com.

Ресурсы Internet

Рабочая группа MeGaGo готовит информационный RFC, где будет подробно описаны архитектура и требования к управлению шлюзами между средами передачи с помощью внешних управляющих элементов, таких, как контроллеры шлюзов. Шлюз между средами передачи — это сетевой компонент, осуществляющий преобразование информации, передаваемой по телефонным каналам, в пакеты данных, передаваемые по Internet и другим сетям IP. Адрес рабочей группы в Internet — http://www.ietf.org/html.charters/megago-charter.html.

Рабочая группа MeGaGo занимается определением архитектуры и протоколов, относящихся к Media Gateway Control Protocol (MGCP), Simple Gateway Control Protocol (SGCP), Internet Protocol Device Control (IPDC) и др. Документ с описанием архитектуры вполне удовлетворителен, во всяком случае для проекта стандарта Internet. Группа PacketCable опубликовала вариант MGCP на своем узле Web по адресу: http://www.packetcable.com.

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

Продукты MGCP/MEGAGO Voice-over-IP (VoIP) Gateway Solution компании Hughes Software Systems можно найти на http://www.hssworld.com/products/ next_generation_networks/signallingVoIPgateway/ mgcpVoIP/signallinggateway.htm.

Как утверждается в статье Network Computing, удовлетворительные с точки зрения коммерческого применения услуги VoIP еще не появились. Текст статьи можно найти на http://www.networkcomputing.com/1005/1005f1.html,.

Узел International SoftSwitch Consortium (ISC) расположен на http://www.softswitch.org. Там можно найти общую информацию и сведения о компаниях.

Полезная информация имеется также на узле Web компании Telcordia по адресу: http://www.bellcore.com/newsroom/knowledgebase/.