Текст набрали с вывихом руки? Без абзацев можно еще и вывих глаза получить )))

тут увидел проект github.com/Thomaash/me, сразу про ваши сети подумал ))

мое понятие network diagram шире )) все диаграммы вокруг не столько сетей, сколько вокруг сервисов, ПО, данных
у вас классный пример того, как можно документировать именно сети

Могу и про graphviz написать, т.к. рассматривал его до того как писать свой блекджек. Но если я где-то не прав — поправьте.
а) graphviz использует свою нотацию, которая достаточно мудрая, т.е. гибкая и местами сложная.
б) проект непонятно в каком состоянии — на сайте картинки не отображаются, доступ к доке на гитлабе закрыт. viz-js — веб-версия graphviz на гитхабе в рид-онли.
в) viz-js рекомендует использовать dagre.js
а вот dagre.js — интересная штука, хотя и не совсем то

у dagre.js интересный синтаксис

g.setNode("kspacey",    { label: "Kevin Spacey",  width: 144, height: 100 });
g.setEdge("kspacey",   "swilliams");

т.е. если бы не мое желание структуры, то можно было сделать подобное API

более того dagre.js использует graphlib — это графовый движок, вот в целом он меня устраивает, но он не рисует картинки в браузере

О, да, я его видел, забыл добавить в свой список )) Думаю, он вдохновил Raoul Meyer написать github.com/RaoulMeyer/diagram-as-code. К сожалению, он на python и более сервер-сайд решение.

а вы пользуетесь whatsapp через twilio?

Прикольно. Мог бы начать использовать, но нет проекта на php. Вот если бы вы делали как промежуточное звено со своим API (супер, если в openapi/swagger) да еще и в контейнере со всеми php версиями и зависимостями. Тогда использование вашего проекта как proxy-instagram-api очень привлекательно. Плюс безопасность: логин-пароль от инстаграм-аккаунта (в том числе корпоративного) лежит где-то в сервисе, а мои прочие сервисы просто по необходимости и постить могут или комментарии читать.

Хотя стоп, это уже было github.com/whizzzkid/instagram-proxy-api/issues/28

«Кто сдает продукт вторичный, тот снабжается отлично» (с) Москва 2042 В.Войнович

так это Иван Бегтин там размещает, расходимся ))

не хватает фотографий, Мирного, быта, окрестностей, там ведь наверняка красиво и местами технологично ))

А здесь нет унификации )) По мне пусть любой из вендоров сделает такую возможность, и я для его телефонов напишу приложения. И одеяло будет на его стороне.
По поводу проприетарности, тоже плавали-знаем, в итоге всем нашлась ниша и клиент — кто-то выбирает вендорные решения, а кто-то строит на астериске.

любой endpoint OpenAPI вы curl'ом легко проверите, в браузере все get'ы проверите, перешлете, обсудите, а SOAP, угу, wsdl-browser сначала найди норм

тут стандартная схема: будь проще и люди к тебе потянутся ))

Вы правы, похож. Но проще, и потому выбирают сначала OpenAPI, а не SOAP.

Первый абзац в разделе «Архитектура решения» рассказывает, что будет нелегко ))

Возможно, я не выразил ясно мысль в статье, но еще раз попробую: решений как сделать управление телефоном полно, может быть есть проще? например, через вебсокеты гонять json?

реализовать управление через tr-069 с cwmp да на soap я, пожалуй, смогу, но куча народу нет. а могли бы пилить свои программы на javascript'е и покупать телефоны в офисы и звонить, и кофеварками с жалюзями управлять.

а может и не надо чтоб было просто никому?

Посмотрел описание Avaya Dagnostic Server, да, выглядит функционально. Интересно как внутри это работает.

Action URI у каждого вендора в отдельной manual pdf описан. Какие реализовать параметры, действия определяется фантазией вендора. Спецификаций не встречал. И реализуется, конечно, на усмотрение вендора, хотя в той или иной мере, наверное, у всех есть.

Может быть и стоит посмотреть. А вы смотрели TR-069? А пробовали с его помощью выполнять процедуры на устройствах? удаленную диагностику?

Всегда полагал, что автопровижн задуман как раз чтобы убрать все эти admin:admin, а то через админку телефона все кому не лень ходят ))

Прикольно, а зачем? ))

Есть util.debuglog() nodejs.org/api/util.html#util_util_debuglog_section

добавлю к этому комментарию, что скрипт можно не разбивать на разные файлы, а просто в скрипте сделать комментарии, поясняющие зачем нужны команды в данной секции. так будет смотреться более целостно и читабельно, будет видна последовательность действий.