Илья Федорушкин
Руководитель направления VoIP ОАО «РТКомм.РУ»

Первые попытки создания всемирного справочника, обеспечивающего «универсальный номер абонента», были предприняты еще в начале 90-х при разработке протокола X.500, однако из всех возможных функций востребованным оказался только LDAP. С тех пор появилось множество сервисов и терминальных устройств (аппаратных и программных), и проблема создания универсальной системы идентификации стала острее. IETS (Internet Engineering Task Force) для этих целей разработал систему ENUM, которая стала попыткой совместить ставшие уже привычными людям телефонные номера и адреса из мира Интернета (компьютеров). Как показала мировая практика, ENUM стал наиболее применимой в жизни и на настоящий момент самой распространенной в мире единой системой нумерации.

ENUM (tElephone NUmber Mapping) — это сетевой протокол, определяющий выбор маршрутов и преференций для связи с различными устройствами, принадлежащими одному абоненту (пользователю телефонного номера в международном формате E.164). То есть номеру в формате E.164 (международный формат телефонных номеров, определяемый в рекомендации E.164 ITU), может быть однозначно поставлено в соответствие комплексное доменное имя в узкоспециализированном домене сети Интернет (e164.arpa).

Целью работ IETS было создание основанной на системе DNS архитектуры и протоколов, устанавливающих соответствие между стандартным телефонным номером и ресурсами, которые используются для установления контакта с абонентом этого номера. Сам протокол первоначально был описан в документе «E.164 number and DNS» (RFC 2916), затем дополнен и исправлен (RFC 3761). Одним из инициаторов разработки протокола стал шведский инженер из компании Cisco Systems Патрик Фалстром. Синтаксис Uniform Resource Identifiers (URIs) определен в RFC 2396 (1998).

Протокол ENUM определяет порядок использования записей Naming Authority Pointer (RFC 2915) для определения доступных путей и сервисов с целью установления контакта с определенным узлом в Интернете. То есть результатом ENUM-запроса является список записей в DNS NAPTR, которые могут быть использованы для контакта с одним из ресурсов (например, URI), связанных с этим номером.

Сегодня для того чтобы один абонент IP-телефонии мог позвонить другому, он должен набрать его телефонный номер в формате E.164. Вызов выйдет в сеть ТфОП, затем попадет в VoIP-сеть оператора, к которому подключен вызываемый абонент, — и далее на терминал абонента. У такой схемы следующие минусы:

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

Давайте рассмотрим ENUM применительно к оптимизации осуществления вызовов через сети SIP-телефонии:

берем номер абонента в формате E.164 — +7 495 9800170;

преобразуем его в ENUM-формат — 0.7.1.0.0.8.9.5.9.4.7.e164.arpa;
запрашиваем DNS;

получаем URI — sip:i.fedorushkin@ss.rtcomm.ru.

При использовании ENUM абонент может знать только Е.164-номер вызываемого абонента, но при этом его вызов проходит напрямую между его VoIP-терминалом и VoIP-терминалом вызываемого абонента.

Требуется подробная техническая и организационная проработка вопроса реализации ENUM в России, но в первом приближении это может выглядеть следующим образом. На территории России устанавливается сервер привязки (наподобие DNS-сервера). Клиент оператора 1 совершает звонок на VoIP-номер. Коммутатор оператора 1 проводит проверку «свой — чужой». Если вызываемый номер принадлежит сети оператора 1 (свой), то он производит переключение вызова. Если нет (чужой) — запрашивает сервер привязки магистрального оператора на выдачу IP-адреса коммутатора, к которому приписан вызываемый номер. Получив IP-адрес коммутатора оператора 2, он производит переключение вызова на него. Коммутатор оператора 2 переключает вызов на номер в его сети.

Немаловажным фактором является проработка вопросов конвертации протоколов SIP-H.323 и выделения магистрального ресурса (MPLS VoIP VPN) для пропуска трафика по сетям магистральных операторов между VoIP-абонентами для обеспечения качественной связи.

Необходимо также всесторонне изучить вопрос привязки получившейся VoIP-сети к ТфОП легальными способами — для этого нужен открытый диалог и всесторонняя поддержка проекта Министерством информатизации и связи РФ. Это вполне возможно, потому что операторы связи в таком случае смогут реализовать услуги IP-телефонии в рамках своих лицензий, а также построить легальные отношения этой VoIP-сети с сетью ТфОП, что и требуется сделать в рамках действующего законодательства. Это произошло и происходит в большинстве развитых стран, когда для доступа к глобальной VoIP-сети с поддержкой ENUM министерства этих стран выделяют отдельный код в ТфОП, четко разграничивая услуги телефонии и VoIP. А теперь решать вам — нужна ли России подобная схема развития услуг IP-телефонии, или VoIP-операторы будут продолжать настаивать на том, что принятые законодательные акты парализуют их деятельность в России, не оставляя им шансов на выживание.

Источник