так как понимание проблемы лежит на уровне SIP в случае сигнализации и SDP в случае медиа:
я бы предложил начать с
RFC3261 чтобы понять какие поля ответственны за маршрутизацию траффика
и продолжить
RFC6314 — тут practices по NAT
Ну и остальное с опытом придет непременно)
Если у меня дойдут руки, то я все же напишу статью по этому поводу, так как давно хотел.
Но не факт что это будет очень скоро.
Справедливости ради надо сказать что каждый начинал так свою историю покорения SIP. Сталкивался с теми же проблемами, наступал на те же грабли.
Если резюмировать вашу статью, то можно сделать выводы, что основная масса проблем идет от незнания как работает SIP, а не от наличия или отсутствия WEB интерфейса управления. Но это дело наживное.
P.S. Борьба SIP с NAT-ом перестает быть борьбой ровно после того как придет понимание как SIP работает с NAT.
Самые главные ошибки построения сервисов на базе webRTC в том, что:
1 Каждый второй строит свой велосипед на уровне сигнализации, в итоге получая проприетарщину, котороая к тому же не работает.
2 Каждый второй не понимает как работает медиа и что вообще написано в SDP и не пытается понять.
Ну это — если не считать публичных STUN/TURN/ICE Серверов в продакшнах.
Не вижу плюсов ни у FreePBX ни у FusionPBX.
Что одно, что второе — нелогичная связка кривых вебстраниц.
Касаемо интеграции с CRM — не сложно не когда мало-мальски понимаешь в чем интеграция, а когда документация к интегрируемому продукту присутствует нормальном структурированном виде.
Что Asterisk, что FreeSWITCH — с гуем и логикой построения гуя беда у обоих.
А касательно легкости и понятности:
Через пару лет а может и раньше вам скорее всего надо будет интегрироваться с CRM и т. п. — начальство жеж захочет смотреть в новый век когда то,
Вот тогда напишите статью о том как вы искали документацию по FS и что нашли а что нет.
Так API планируется?
Ну к примеру у меня кластер из АТС.
Я бы не прочь иметь обертку для статистики которой я смог бы поставить свои данные со своей АТС, чтобы она их проанализировала и отрисовала (не хочу например писать свой frontend и аналитику, готов на облако, но не хочу свою АТС в облако загонять)
Он не выступает как эксперт. Он указал Вам — компании которая занимается интеграцией систем безопасности на очевидные проблемы с безопасностью, которые дискредитируют Вашу же компанию.
Если быть честными самими с собой разве — он не прав?
Я бы, если бы лично не знал автора статьи и его профессиональный уровень и будучи потенциальным клиентом не рискнул бы связываться с такой компанией увидя такой просчет.
Это действительно дыра и лучшим решением было бы закрыть ее в кратчайшие сроки, а проблему признать, чем пытаться переключить внимание на чужие проблемы и уж тем более переходить на личности.
Правильно ли я понимаю что Splunk можно прикрутить к любой БД для аналитики данных?
И как на счет встраивоемости дашборда как виджета в существующие проекты?
Asterisk, Kamailio, Freeswitch Используют lua Как встраиваемый язык.
moonscript — сомнительно. Есть как плюсы так и минусы
Бессмысленный он получается.
Все там можно. просто надо будет нырнуть в его АПИ.
я бы предложил начать с
RFC3261 чтобы понять какие поля ответственны за маршрутизацию траффика
и продолжить
RFC6314 — тут practices по NAT
Ну и остальное с опытом придет непременно)
Если у меня дойдут руки, то я все же напишу статью по этому поводу, так как давно хотел.
Но не факт что это будет очень скоро.
Если резюмировать вашу статью, то можно сделать выводы, что основная масса проблем идет от незнания как работает SIP, а не от наличия или отсутствия WEB интерфейса управления. Но это дело наживное.
P.S. Борьба SIP с NAT-ом перестает быть борьбой ровно после того как придет понимание как SIP работает с NAT.
1 Каждый второй строит свой велосипед на уровне сигнализации, в итоге получая проприетарщину, котороая к тому же не работает.
2 Каждый второй не понимает как работает медиа и что вообще написано в SDP и не пытается понять.
Ну это — если не считать публичных STUN/TURN/ICE Серверов в продакшнах.
Что одно, что второе — нелогичная связка кривых вебстраниц.
Касаемо интеграции с CRM — не сложно не когда мало-мальски понимаешь в чем интеграция, а когда документация к интегрируемому продукту присутствует нормальном структурированном виде.
А касательно легкости и понятности:
Через пару лет а может и раньше вам скорее всего надо будет интегрироваться с CRM и т. п. — начальство жеж захочет смотреть в новый век когда то,
Вот тогда напишите статью о том как вы искали документацию по FS и что нашли а что нет.
Дело именно в Астериске — его WebRTC к продакшну не готов.
Астериск даже в 13 версии очень так себе работает через этот транспорт. Не продакшн.
Ну к примеру у меня кластер из АТС.
Я бы не прочь иметь обертку для статистики которой я смог бы поставить свои данные со своей АТС, чтобы она их проанализировала и отрисовала (не хочу например писать свой frontend и аналитику, готов на облако, но не хочу свою АТС в облако загонять)
А чего бы ему не уметь?
Вот как раз размышлял на тпму внедрения блокчейна в VoIP вечерами перед сном, а тут вы уже все сделали...
По налогам еще хотелось бы услышать. Ведь 2000 евро это на руки, а сколько это до налогов?
Если быть честными самими с собой разве — он не прав?
Я бы, если бы лично не знал автора статьи и его профессиональный уровень и будучи потенциальным клиентом не рискнул бы связываться с такой компанией увидя такой просчет.
Это действительно дыра и лучшим решением было бы закрыть ее в кратчайшие сроки, а проблему признать, чем пытаться переключить внимание на чужие проблемы и уж тем более переходить на личности.
Фу таким быть.
И как на счет встраивоемости дашборда как виджета в существующие проекты?