Я писал недавно, что месяц назад у нас в гостях был Бруно Кох, эксперт по e-invocing из Швейцарии. Выяснилось, что несмотря на сотни операторов e-inv в Европе и десятки операторов устроивших между собой связность, нет единого стандарта адресации абонентов.
Например, есть такой стандарт:
Индекс: 121614
Страна: Россия
Регион: Москва
Город: Москва
Улица: Крылатская
Дом: 17 корпус 1
Наименование получателя: ООО "Майкрософт Рус"
А для отправки юридически значимых документов через специального оператора такого формата, однозначно идентифицирующего получателя - нет. То есть, там надо знать название компании-получателя и искать его в специальном каталоге. А если это еще и абонент другого оператора, то еще надо знать название этого оператора и так далее...
Я предложил Бруно использовать для адресации старый-добрый email, так как в инфраструктуре электронной почты есть все, что нужно для решения этой проблемы. Там есть домены (организация-получатель), пользователи (имя до @), есть MX-запись в DNS, указывающая на сервер получателя, порт по умолчанию (25) и показатель preference, который может использоваться для балансирования нагрузки или указания бэкапных серверов.
На примере домена kip.ru:
$ host -t mx kip.ru
kip.ru mail is handled by 10 mail.kip.ru.
kip.ru mail is handled by 20 kip.ru.
Почта для домена kip.ru обрабатывается сервером mail.kip.ru с высшим приоритером (10). Исходящий сервер, который хочет отправить почту пользователю jkhdsfs@kip.ru должен открыть соединение не сервер mail.kip.ru на стандартный для протокола SMTP порт 25 и там почту для домена kip.ru примут!
По аналогии работает SIP-телефония. Там тоже есть сервис, по сути никакого отношения к email не имеющий, в котором абоненты имеют адреса, очень похожие на email. Вот как это там работает!
Есть домен пользователя. Обычный интернет-домен. Пусть это будет например amby.ru.
$ host -t SRV _sip._tcp.example.com_sip._tcp.amby.ru has SRV record 10 0 5060 dd.cport.ru.
В SIP используются не MX, а SRV записи в DNS, о работе которых можно почитать тут. Вообще, SRV это универсальный механизм, заложенный в DNS, который позволяет адресовать любых сервисы через интернет, а как конкретно это работает для SIP расписано здесь.
(Вообще, в SRV можно записать все что угодно, включая например требования к национальности оператора сервера-отправителя - это легко реализуется :)
Итак, строчка выше означает, что для того, чтобы соединится с SIP-сервером для домена amby.ru по протоколу TCP (там еще есть отдельная адресация для UDP) надо отправиться на сервер dd.cport.ru на порт 5060. Вот и все - мы нашли физический хост для конкретного сервиса для конкретного юзера!
То же самое на базе SRV-записей можно было бы сделать и для e-invoicing. Например, если вы хотите отпавить юридически значимый invoice в компанию А, вам надо спросить у них их адрес. Вы с ними уже работаете и вам не составит труда это сделать. Они скажут, что их адрес например e-invocing@kfdjshskjhdfs.ru и далее надо этот адрес использовать при создании "отправления" в интерфейсе своего оператора e-invoicing. Все просто.
Потом система оператора через SRV-запись для домена kfdjshskjhdfs.ru поймет делали доставки и расскажет о ньюансах передачи, если такие есть. Например, это сервис у другого оператора и доставка туда стоит дороже. Или что этот адрес не пользуется сервисами e-invoicing потому что в DNS нет нужной SRV-записи.
Вообще, все это очень напоминает email и возникает вопрос, а почему бы не использовать действительно всю инфраструктуру email и не создавать путаницы. Хороший вопрос. Email создан в 1970-х и если бы его придумывали сейчас сегодняшние инженеры и архитекторы, он был бы совсем другим: спама не было бы, письма не терялись бы, было бы больше полезных сервисов прямо в протоколе и так далее.
Ребята, которые занимаются e-invoicing хотят гарантированной доставки и предсказуемости работы системы в целом, хотят архивации сообщений и юридической значимости, хотят сервисов электронных архивив с периодической "перештамповкой" ЭЦП (сертификат экспайрится!) и прочее, прочее, прочее...
Но для адресации вполне можно использовать обычный DNS, как это уже делает масса сервисов. Это проверено временем и массой приложений включая email, это дешево и безопасно.
Comments