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

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

Телефонный номер… в DNS

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

Современные системы унифицированных коммуникаций (Unified Communications) решают проблему интеграции сервисов и переадресации обращений (не обязательно телефонных) в коммуникационный канал, который в данный момент является для абонента предпочтительным. Да и сами вызовы благодаря IP-технологиям инициируются парой щелчков мыши. Однако такие возможности доступны в основном пользователям корпоративных коммуникационных систем и приложений. А что делать физическому лицу?

Ответом на этот вопрос стала технология универсального отображения телефонных номеров ENUM (tElephone NUmber Mapping), разработанная консорциумом IETF. Она представляет собой набор протоколов для интеграции привычной системы телефонной нумерации E.164, рекомендованной Международным союзом электросвязи, и системы доменной адресации Internet. Другими словами, ENUM можно рассматривать как механизм маршрутизации вызовов из телефонной сети, который отображает предпочтения абонента и обеспечивает установление связи с разными коммуникационными устройствами, принадлежащими абоненту с данным телефонным номером. В то же время маршрутизация в системе ENUM отличается от маршрутизации в сетях VoIP, основанной на протоколах SIP, H.323 или IAX. Появление и начавшееся внедрение технологии ENUM является еще одним проявлением конвергенции ТфОП и IP-сетей.

Спецификация основного протокола ENUM содержится в документе IETF RFC 3761, а отдельные компоненты данной технологии описаны в RFC 2168, RFC 2396, RFC 2915 и RFC 3403. В основе ENUM — простой алгоритм преобразования 12-значного телефонного номера (включая код страны) в адрес DNS-домена, именуемый «универсальным идентификатором ресурса» (Unified Resource Identifier, URI). Указанный номер интерпретируется DNS-сервером как адрес уникального ENUM-домена.

В соответствии с рекомендацией Internet Architecture Board (IAB) на DNS-дереве все ENUM-домены располагаются в специальном домене второго уровня e164.arpa. ENUM-домены следующих уровней строятся по иерархическому принципу в соответствии с подходом к телефонной нумерации — от кода страны к коду региона, а затем к телефонному номеру. Но поскольку в телефонной нумерации эта иерархия соответствует записи цифр слева направо, а в Internet принят обратный порядок (название домена высшего уровня фигурирует последним), преобразование включает в себя инверсию порядка следования цифр. Еще одно правило связано с тем, что коды стран, регионов и номера абонентов могут иметь разные длины. Для стандартизации схемы DNS-адресации в домене ENUM каждая цифра телефонного номера соответствует своему уровню иерархии.

Таким образом, преобразование сводится к следующему: из записи телефонного номера выкидываются все ненужные символы (скобки, пробелы, дефисы, начальный символ «+»), сам номер записывается справа налево, затем все соседствующие цифры разделяются точками, а справа к результату добавляется «.e164.arpa». Например, телефон нашей редакции +7(495)253-9229 будет преобразован в уникальный ENUM-домен 9.2.2.9.3.5.2.5.9.4.7.e164.arpa.

Все дело в номерах

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

Информация об адресах, сопоставленных с ENUM-номером, хранится на DNS-серверах. Каждому URI ставятся в соответствие несколько записей NAPTR (Naming Authority Pointer Resource Records) c указателями на конкретные коммуникационные сервисы и соответствующие им идентификаторы абонента — по одной записи на каждый сервис.

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

Если исходящий вызов делается из IP-сети, преобразование телефонного номера в URI выполняет программа-агент ENUM, установленная на стороне звонящего. Последующие процедуры выполняются без изменений. Если вызываемый абонент не зарегистрирован в системе ENUM, вызов совершается по ТфОП обычным образом. Преобразование телефонного номера и поиск записей NAPTR в базе данных DNS выполняются прозрачно для абонентов.

Чтобы описанная схема была работоспособна, помимо собственно абонентов в ней должны участвовать еще несколько сторон. Одна из них — регистратор, который обеспечивает управление контактной информацией абонента, общедоступной в Internet. Регистратор становится своеобразным агентом конечных абонентов, и на эту роль подходят как операторы телефонной связи, так и провайдеры услуг VoIP. Другой участник — держатель реестра национальной зоны ENUM, отвечающий за корректность переадресации вызовов к серверам регистраторов, на которых хранится контактная информация абонентов. Наконец, немаловажная роль принадлежит национальной администрации связи, которая регулирует использование национальной зоны ENUM, назначает держателя реестра, определяет порядок его взаимодействия с операторами и регистраторами.

Варианты реализации

Предложены два сценария реализации схемы ENUM, каждый из которых имеет своих сторонников и противников.

Общедоступная, или пользовательская, архитектура (Public ENUM, или User ENUM) непосредственно основана на технологии, описанной в RFC 3761. Предполагается, что функциональность ENUM разные провайдеры предоставляют независимо друг от друга. В этой модели данные ENUM являются публичными, т.е. доступны любому, кто знает ENUM-номер вызываемого абонента. Полный контроль над набором идентификаторов, соответствующих разным сервисам, остается за абонентом. Существенно, что применение функциональности ENUM опционально не только для вызываемого, но и для вызывающего абонента: никто не запрещает ему сделать вызов по ТфОП.

Частная архитектура (Private ENUM), называемая также инфраструктурной, предполагает, что использование сервисов контролируют операторы. Если они предоставляют услуги на базе IP-инфраструктуры, то полагаться на выбор технологии абонентами (IP или ТфОП) не приходится: оператор должен располагать независимым механизмом маршрутизации при поиске точек входа в собственную сеть. В архитектуре Private ENUM информация об идентификаторах абонента в разных сервисах доступна только провайдерам IP-услуг, которые могут предоставлять ее даже не всем собственным абонентам. Функциональность ENUM может быть реализована в системе, полностью автономной от инфраструктуры Public ENUM.

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

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

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

Ключ на старт

В прошлом году несколько крупных операторов, в том числе европейские British Telecom, KPN Telecom и Deutsche Telecom, заявили о намерении в пятилетний срок полностью перевести свои сети на протокол IP. Эти планы следует расценивать как хороший знак с точки зрения использования технологии ENUM.

Развертывание первых тестовых зоны ENUM началось около двух лет назад. Они появились в США, Японии, Германии, Великобритании и в десятке других государств. В США результаты двухлетнего тестирования признаны успешными, и на их основе принято решение о предоставлении полноценных услуг ENUM в общедоступной архитектуре. Промышленная эксплуатация национальных систем ENUM уже осуществляется в Австрии, Румынии и Польше, а всего права регистрации национальных зон ENUM делегированы 17 странам.

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

Отдельные эксперты считают, что активное внедрение операторами протоколов ENUM начнется лишь тогда, когда уровень проникновения технологии VoIP превысит 10%. Судя по динамике, в ряде стран данный рубеж будет достигнут уже в следующем году, но если не случится чуда, Россия в число этих государств войдет не скоро.

И нам ENUM!

Перспективы появления системы ENUM в России пока довольно туманны. Как сообщил в ноябре 2007 года на 12-й конференции по IP-телефонии и IP-коммуникациям Аркадий Кремер, председатель исполкома Ассоциации документальной электросвязи (АДЭ), Мининформсвязи поручило АДЭ развернуть в нашей стране опытную зону ENUM с привлечением операторов связи и других заинтересованных сторон. Цель очевидна — проверить функционирование этой технологии и изучить возможные модели ее внедрения в России.

С осени 2007 года АДЭ провела несколько совещаний рабочей группы ENUM, на которых обсуждалось создание опытной зоны ENUM. Совместно с ЦНИИС был подготовлен проект технического задания на развертывание такой зоны, который впоследствии был направлен на утверждение в Мининформсвязи. После утверждения техзадания регулятором в начале текущего года был составлен конкретный план работ по созданию опытной зоны. Наконец, сама зона (www.enum-test.ru) открыта в апреле 2008 года. Как отмечается на указанном сайте, целью тестового сервиса является предоставление операторам телефонной связи, VoIP, сервис-провайдерам и их абонентам площадки для тестирования вариантов использования технологии ENUM. В рамках опытной зоны есть два варианта:

  • оператор фиксированной или мобильной телефонной связи может устанавливать соответствия между абонентскими телефонными номерами и их SIP URI;
  • оператор VoIP может переадресовывать исходящие вызовы от пользователей VoIP в телефонную сеть.

Казалось бы, лед тронулся, но бурной активности операторов в использовании ресурса пока не замечено. Выборы президента и последовавшие перестановки в правительстве на несколько месяцев остановили деятельность отраслевого министерства по созданию регуляторной базы для сервиса ENUM. Неожиданное препятствие возникло и на международном уровне. Как известно, международную зону нумерации «+7» наша страна делит с Казахстаном. По словам Игоря Масленникова, директора по развитию бизнеса компании «МФИ Софт», наш южный сосед отказался использовать совместно с Россией единый домен третьего уровня 7.e164.arpa в сервисе ENUM. В результате Международному союзу электросвязи пришлось выделить для России и Казахстана специальные домены следующего уровня. Нашей стране досталось четыре таких домена (из десяти теоретически возможных), Казахстану — два, а остальные зарезервированы.

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

Все еще не определены схемы взаимодействия операторов связи с регистраторами. Игорь Масленников полагает, что выбор предстоит сделать из двух основных сценариев. В первом случае ведущие операторы телефонной связи (МГТС, МРК, «большая тройка» сотовых операторов) получают статус главных регистраторов в российской зоне ENUM, а остальные компании (прочие операторы, ASP, корпоративные клиенты) работают через них. Второй сценарий тоже подразумевает иерархическую схему, но она больше напоминает систему доменных имен: регистраторами первого уровня не обязательно должны быть компании с наибольшей абонентской базой.

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

И все-таки первые шаги уже сделаны.

Далеко, как до ENUM

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

Как вы оцениваете перспективы внедрения ENUM в России? и представляет ли интерес это направление для бизнеса вашей компании?

Андрей Касьяненко, генеральный директор телекоммуникационной компании «Караван»

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

Дмитрий Гуркин, советник генерального директора «Синтерры» по новым технологиям

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

Какую из двух основных моделей, User ENUM или Infrastructure ENUM, вы считаете предпочтительной? Не кажутся ли страхи по поводу угроз безопасности в модели User ENUM преувеличенными?

Андрей Касьяненко: Наша компания не проводила тщательного анализа этих моделей и не имеет четко выраженной позиции по данным вопросам.

Дмитрий Гуркин: Обе модели имеют системные недостатки, которые делают их практически нереализуемыми. Правда, в модели I-ENUM больше здравого смысла, поскольку она родилась путем эволюции модели User ENUM. Страхи по поводу безопасности, по моему мнению, действительно преувеличены, ведь они ничего не значат по сравнению с ущербностью самой модели ENUM.