Пресса о нас
04.05.2006

ENUM нужна ли России альтернативная нумерация?

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

Первые попытки создания всемирного справочника, обеспечивающего «универсальный номер абонента» предпринимались в начале 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-телефонии мог позвонить другому абоненту 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 операторов России, не оставляя им шансов на выживание.

Возврат к списку