Так при использовании RabbitMQ, audit log также можно реализовать на уровне микросервиса при помощи паттерна EventSourcing. И Вы также можете «перепроиграть» события.
Вы пишите так, что можно подумать, что SSH это OpenSSH дистрибутив и CLI утилиты к нему.
В то время, как на самом деле, SSH это стандартизированный IETF протокол, описанный в RFC 4251 (и дополнительных), а OpenSSH это просто одна из имплементаций протокола.
Т.е. у вас все смешалось в кучу: протокол, одна из рабочих реализаций протокола (OpenSSH), аргументы командной строки для CLI утилиты из дистрибутива OpenSSH (хотя вы же прекрасно понимаете, что в других версиях ПО от других «вендоров» в CLI утилитах могут быть (и будут) реализованы совсем другие ключи командной строки) и пр.
Пишите ясней и не смешивайте кегли, вафли и драже в одной тарелке.
У Вас, кстати, как с первым пунктом? Есть что-то похожее, что-бы разместить на страничке и сразу открывать контакт в мессенджере?
Вы и сейчас можете разместить обычную ссылку с SIP URI (например sip:igor.belyakov@sysadmins.net) и тогда, при клике по ссылке откроется установленный SIP-клиент по-умолчанию и позвонит на sip:igor.belyakov@sysadmins.net, и при этом, регистрация на какой-либо АТС не нужна (благодаря талантливейшим людям из IETF – см. RFC3263).
При должном распространении технологии, как вариант, можно регистрировать индивидуальный частный домен, и уже на него вешать DNS записи, которые будут ссылаться куда требуется.
SCTP – это отличный транспорт для SIP. SCTP лишен многих недостатков TCP и включает в себя лучшее из TCP и UDP. Кроме того, в нем есть поддержка multi-homing.
NAT-boxes нужно делать mapping IP:port для сессий SCTP. Большинство делать это не умеет, т.к. понимает только UDP и TCP.
Но сама совокупность цифр не несет НИКАКОЙ полезной информации, несет пояснение БУКВАМИ.
Т.е. например что такое 1 212 75648654?
Это вам о чем-то говорит? Вряд ли.
Не представляю, как можно переучить олдскульное население, которое SMS то с большим трудом научилось писать. Цифры – наверное, самое простое, что можно было бы придумать. Чем глобальнее продукт, тем более простым для end-user он должен быть.
Ну и как быть с организациями с кучей народу, где однофамильцы часто и имена и, даже, инициалы совпадают? Как им придумывать логин сотруднику? zloy-sheff тут не прокатит. Полность писать Ф_И_О_год? Александр-сто-первый? Igor1979? Это бред!
Нужно помимо user part добавить еще @ и domain part. Например: zloy-sheff@rogakopyta.su или alex.boss@megacorp.com.
Все просто находится по дополнительной информации в поиске, как в общем и происходит в Скайпе, ФБ и т.д., где куча однофамильцев.
На самом деле для этого существуют NAPTR и SRV DNS записи.
А проблема, которую индустрии придется решить, это унифицированный протокол для связи (или набор протоколов, с возможностью простой конвертации сообщений из одного в другой, как SIMPLE<––>CPIM<––>XMPP). И, кстати, SIP является весьма привлекательным кандидатом.
Все же у нас тут про L7 протокол идет речь. С SIGTRAN пока не знаком и, насколько я понимаю, у SIP могут быть преимущества, благодаря возможностям SIP-proxy по гибкой маршрутизации сообщений (и, вероятно, возможностям load-balancing). Если говорить, про SIGTRAN, то там SCTP и IP-адрес одного из end-points должен быть хорошо известен другому. И вопрос, что там с «мобильностью» первого end-point и что с возможностями по load-balancing.
Речь не о SS7, а о телефонной сети, которой уже более 100 лет и которая зародилась задолго до появления IP. Кроме того, помимо телефонной сети, наверняка есть еще масса других, узкоспециализированных глобальных сетей, в которых вообще совсем другой мир, не похожий на IP (но при этом, вероятно, пакетный).
Keep calm and call your lawyer.
Позвольте внести каплю критики для Вашей статьи.
Вы пишите так, что можно подумать, что SSH это OpenSSH дистрибутив и CLI утилиты к нему.
В то время, как на самом деле, SSH это стандартизированный IETF протокол, описанный в RFC 4251 (и дополнительных), а OpenSSH это просто одна из имплементаций протокола.
Т.е. у вас все смешалось в кучу: протокол, одна из рабочих реализаций протокола (OpenSSH), аргументы командной строки для CLI утилиты из дистрибутива OpenSSH (хотя вы же прекрасно понимаете, что в других версиях ПО от других «вендоров» в CLI утилитах могут быть (и будут) реализованы совсем другие ключи командной строки) и пр.
Пишите ясней и не смешивайте кегли, вафли и драже в одной тарелке.
Стандарт ITU-T X.500 как раз об этом.
Один из открытых вопросов остается вопрос адресного спама.
a.popova@accounting.firma.ru
a.popova@kuhonka.firma.ru
a.popova@sales.spb.firma.ru
a.popova@headoffice.firma.co.uk
(если еще точнее, то NAPT)
NAT-boxes нужно делать mapping IP:port для сессий SCTP. Большинство делать это не умеет, т.к. понимает только UDP и TCP.
Нужно помимо user part добавить еще @ и domain part. Например: zloy-sheff@rogakopyta.su или alex.boss@megacorp.com.
На самом деле для этого существуют NAPTR и SRV DNS записи.
А проблема, которую индустрии придется решить, это унифицированный протокол для связи (или набор протоколов, с возможностью простой конвертации сообщений из одного в другой, как SIMPLE<––>CPIM<––>XMPP). И, кстати, SIP является весьма привлекательным кандидатом.