Comments 22
Побольше бы такого материала!
Интересно…
Еще бы несколько примеров, для чего обычно используется функционал SIP-прокси в реальной, так сказать, жизни… :)
Еще бы несколько примеров, для чего обычно используется функционал SIP-прокси в реальной, так сказать, жизни… :)
Спасибо, читал. :)
Я предпочитаю говорить «SIP-сервер» или «SIP-коммутатор», т.к. в чистом виде SIP-прокси — это совсем простой компонент. А OpenSIPS — сложный (в смысле, много чего умеет).
Что касается использования в реальной жизни — тема слишком обширная.
К примеру, как «в реальной жизни» используется веб-сервер (например Nginx)?
Ну, так же и SIP-сервер (напрмер OpenSIPS) — ооочень по разному :)
Я думаю, интереснее посмотреть, кто и как его использует. Например, мы в TipMeet используем OpenSIPS в качестве «умного» коммутатора аудио-видео вызовов.
Кто-то, наоборот, в качестве не особо интеллектуального балансировщика SIP-сессий перед Asterisk или FreeSwitch.
Что касается использования в реальной жизни — тема слишком обширная.
К примеру, как «в реальной жизни» используется веб-сервер (например Nginx)?
Ну, так же и SIP-сервер (напрмер OpenSIPS) — ооочень по разному :)
Я думаю, интереснее посмотреть, кто и как его использует. Например, мы в TipMeet используем OpenSIPS в качестве «умного» коммутатора аудио-видео вызовов.
Кто-то, наоборот, в качестве не особо интеллектуального балансировщика SIP-сессий перед Asterisk или FreeSwitch.
Когда-то на практике пришлось связывать OCS с VOIP-шлюзом, работающим по UDP. Как раз для этого применил OpenSIPS.
Слишком сложно и непонятно описано. Разработчики неторопливы — функционал повторят kamailio — ранний форк openSIPS. Но новость не может не радовать.
Это просто из за того что тема сложная, сейчас конфиг файлы это жесть. Хоть и документация есть но реально чтоб начинать что то понимать надо ну месяцев 6.
Да не правда. Достаточно одного, если целенаправленно этим заняться.
Согласен, OpenSIPS осваивается не просто. Справочная документация довольно полная, но её недостаточно для старта «с нуля» — не понятно, что есть что и с чего начать.
Но сейчас, к счастью, есть вебинары (уже прошедшие есть в записи) и книга Building Telephony Systems with OpenSIPS 1.6.
Но сейчас, к счастью, есть вебинары (уже прошедшие есть в записи) и книга Building Telephony Systems with OpenSIPS 1.6.
Неторопливость развития как раз и объясняется старой архитектурой — она не позволяет развивать систему «правильно».
Например, из-за устаревших решений в ядре системы, не получается вынести логику
приложения из основного конфига во внешние приложения на языках высокого уровня.
Из-за этого понаделали отдельных модулей, которые решают мелкие частные задачи «в лоб».
Это как если бы вместо общего решения «программа калькулятор» понаделали бы отдельных программ, типа
«программа для сложения чисел» или «программа умножения целых чисел на 5».
Например, из-за устаревших решений в ядре системы, не получается вынести логику
приложения из основного конфига во внешние приложения на языках высокого уровня.
Из-за этого понаделали отдельных модулей, которые решают мелкие частные задачи «в лоб».
Это как если бы вместо общего решения «программа калькулятор» понаделали бы отдельных программ, типа
«программа для сложения чисел» или «программа умножения целых чисел на 5».
Да, иметь возможность написания приложений хотя бы на питоне, это действительно будет прорыв. Сразу снимается множество проблем расширяемости. Ещё бы возможность перехватывать медиа-потоки в приложениях и станет совсем хорошо.
Я вообще считаю, что конфигурация программы в императивном стиле — это идиотизм.
Даже страшно представить, как уродливо бы развивался веб, если бы вместо простого CGI в первых веб-серверах начали бы развивать какие-то свои чудо-конфиги с доступом в базу данных и программной логикой.
К сожалению, в «OpenSIPS 2.0 Design» этим же душком тянет…
Доступ к базам данных хотят оставить в самом сервере. Это, скорее всего, приведет к тому, что какую-то core-логику завяжут на какие-то таблички в SQL БД…
Даже страшно представить, как уродливо бы развивался веб, если бы вместо простого CGI в первых веб-серверах начали бы развивать какие-то свои чудо-конфиги с доступом в базу данных и программной логикой.
К сожалению, в «OpenSIPS 2.0 Design» этим же душком тянет…
Доступ к базам данных хотят оставить в самом сервере. Это, скорее всего, приведет к тому, что какую-то core-логику завяжут на какие-то таблички в SQL БД…
Рад, что SIPS жив =) И доганяет по функционалу Kamailio.
А теперь о непонятностях:
1. Для чего Presence (кстати, рфц3261 его не описывает, это расширение SIP 2.0) включен в ядро? А потом еще и в Routing Engine?
2. Почему поддержка NAT включается в обработку после анализа транзакции? (Хотя тут могу допустить, что сделано для отбрасывания несуществующих транзакций до анализа NAT)
3. Для чего доступ к БД на уровне анализа диалогов и ниже? Я думаю памяти вполне бы хватило. Оверхед sql операций привысит, ИМХО, выигрыши от прочих решений.
4. Как по мне, ядро должно все-таки включать минимальный функционал. Доступ к БД и прочие «тяжелые» рюшки лучше «поднять выше».
А теперь о непонятностях:
1. Для чего Presence (кстати, рфц3261 его не описывает, это расширение SIP 2.0) включен в ядро? А потом еще и в Routing Engine?
2. Почему поддержка NAT включается в обработку после анализа транзакции? (Хотя тут могу допустить, что сделано для отбрасывания несуществующих транзакций до анализа NAT)
3. Для чего доступ к БД на уровне анализа диалогов и ниже? Я думаю памяти вполне бы хватило. Оверхед sql операций привысит, ИМХО, выигрыши от прочих решений.
4. Как по мне, ядро должно все-таки включать минимальный функционал. Доступ к БД и прочие «тяжелые» рюшки лучше «поднять выше».
Sign up to leave a comment.
Будущий дизайн OpenSIPS