Pull to refresh

Comments 5

Когда то FusionPBX генерировала конфиги из того что она хранит в базе и была возможность посмотреть на то, что получалось на выходе. Было удобство внесения изменений и контроль за конфигурацией. В последних версиях конфигурация вливается в Freeswitch "на лету" и не всегда понятна логика сгенерированного конфига(ну или ее долго выцарапывать из консоли). Дебаг такого решения то еще занятие по сравнению с человекочитаемым XML.

Есть доля истины в ваших словах). Но лично для меня так сложилось, что ковырнув конфиг, раскиданный по таблицам, именованным по выполняемому функционалу, картинка в голове сложилась быстрее и воспринимается более слитной. При этом и понимание сделанных ранее конфигов в XML улучшилось, нашел косяки. И в целом, база данных лучше располагает к массовым правкам благодаря SQL-запросам. Мне пока что нравится больше.
И коллегам, которые на подхвате, и которые по сравнению со мной много дальше от консоли и XML, веб-морда заходит лучше. В свете необходимости делегировать им админские функции это несомненный плюс.
Справедливости ради надо сказать что каждый начинал так свою историю покорения SIP. Сталкивался с теми же проблемами, наступал на те же грабли.

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

P.S. Борьба SIP с NAT-ом перестает быть борьбой ровно после того как придет понимание как SIP работает с NAT.

А где можно ознакомиться с данным знанием?
так как понимание проблемы лежит на уровне SIP в случае сигнализации и SDP в случае медиа:
я бы предложил начать с
RFC3261 чтобы понять какие поля ответственны за маршрутизацию траффика
и продолжить
RFC6314 — тут practices по NAT
Ну и остальное с опытом придет непременно)

Если у меня дойдут руки, то я все же напишу статью по этому поводу, так как давно хотел.
Но не факт что это будет очень скоро.
Sign up to leave a comment.

Articles