То есть ещё и opus и vpx поддержка , но надо дописывать свой RTX ( как минимум reader для приема ), что не сложно, но чуть добавляет проблем.
Вообще хотелось бы нормального биндинга libav. Есть вот этот но он субъективно не очень удобный для написания на go. Хотя работа проделана там неплохая.
Количество минут в день говорит только о размере сервиса и его общей нагрузке. Просто чтобы указать что это не 2.5 звонков в день. конкретные цифры говорить не буду. И права не имею и в целом это не будет каким либо показателем. Мы же сравниваем производительность pjsip c chan_sip при одинаковой нагрузке на экземпляр поэтому размер кластера не имеет значения. Но если сильно интересно то это несколько десятков машин around the globe.
Характеристики машин разные в зависимости от локаций серверов и потребностей. В целом это 4 ядра и от 8 до 16 гб оперативки на машину.
Кластер так же динамический и умеет скалировться предиктивно исходя из прогнозируемой пиковой нагрузки. Ну я думаю это очевидно что никто в своем уме и здравой памяти не будет держать инфраструктуру под предельной нагрузкой.
После перехода на pjsip нам нужно чуть меньше экземпляров машин чтобы обслуживать тот же поток траффика.
В конкретно этом проекте пир всего один на машину и он ip2ip trunk до proxy/registrar
Чукча не читатель, чукча писатель… Ещё раз, напишу по другому.
Вы пишите одно, а оказывается подразумеваете другое. Я не должен угадывать, что у вас там в голове и что вы имели ввиду. Сразу написали бы нормально и вопросов не было бы.
Юзать такие LVM, ради многопоточности, спорное решение.
Вот уж действительно. Наверное именно поэтому nginx ставят перед кластером nodejs, а не наоборот, исключительно чтобы укратить nodejs, а то ну слишком быстрый он. Именно поэтому kamailio c его fork на старте положить та ещё проблема. Все потому, что решения - полное г*но и спорные.
Openresty/Nginx, HAproxy да и Kamailio не дают сохранения состояния(разделение контекста/окружения между двумя параллельными вызовами) и общий доступ
Да и пусть не дают. А собственно почему это такой краеугольный камень? Каждый сопроцесс изолирован, получает задачу от роутера процессов. Да, стартует дольше и подключает либы каждый сам, да не шарит контекст, но все это решается или локализацией данных или прокидыванием через внешние источники типа shmem/redis/htable. Статику вычитываем при изменениии кэшируем. Done. Более того, это ещё ещё читать потом проще, нежели искать - а что тут контекстное, а что не контекстное.
Если данные динамические - пишем и читаем постоянно. Тут даже вас процитирую.
При разработке ни одной ноги не пострадало
И заодно отвечу: значит не требуются пока задачи по масштабированию. А тут как раз понадобится что то "с хреновой и слишком дорогой архитектурой" типа haproxy или какого нибудь другого прокси. Ведь окажется что вы утыкаетесь в производительность однопоточного сервиса гораздо раньше чем хотели бы этого. И станет ваш однопоточный сервис просто библиотекой многопоточного сервиса...
Ещё раз — передача контекста выполнения в многопоточном приложении, в определенный момент, под нагрузкой, становится слишком дорогим и по*еру сколько у вас ядер.
Действительно. Не буду тут писать ещё раз пример с openresty и kamailio.
Вы зачем-то так сильно завязываеьесь на контекст в своей аргументации что забываете о том, что им можно и не оперировать, особенно с таких прикладных задачах как ваша...
Что там существенно поменялось/упростилось.
Под копотом - ничего, но вы же аргументировали изначально это тем , что это долго и сложно:
Пока условный Вы будете возится с IPC, консистентностью и синхронизацией разделяемых данных в многопотоке, условный я будет просто обрабатывать звонки.
А теперь вдруг переобулись в то, что это неэффективно оказывается, что это просто блажь с которой вообще непонятно зачем возились и до сих пор возятся, а проекты, построенные на этих принципах как работали быстрее так и работают.
Вы скажете- это древнее г-но мамонта, которое уже никто не использует, но вдруг неожиданно мы видим JANUS sfu проект который написан в 21 веке и является одной из самых популярных и быстрых SFU которая использует preFork. Medooze: pthreads, mediasoup: pthreads. Посмотрим на тесты: https://webrtchacks.com/sfu-load-testing/...
Дальше сами...
Какой то бесконечно бессмысленный спор получается. Думаю, я на этой ноте оставлю вас на едине с собой. Побуду со своей кашей и стереотипов в голове наедине.
Вы очень много объективности отдаёте своей субъективности. Я не говорил о фиче вызова в очереди всех зарегистрированных. Я как раз говорю об обратном: использовать встроенную возможность протокола. И да, добавление механизмов это гибкость. Обычно гибкость называют херью когда не умеют ею пользоваться.
16-й, я вас умоляю, видимо ваш "большой прод" большой только по вашим меркам.
Вы можете думать как вам угодно,
По цифрам: есть сервис где н несколько миллионов минут в день тут регистрации вынесены на proxy registrar.
Тип трафика: что именно интересует? Транспорт? TCP/UDP.
Есть танзит" и не "не транзит". RTP через asterisk. ARI как интерфейс взаимодействия с окружением.
Есть проекты где pjsip работает и как registrar. Там объёма трафика поменьше, - но нагруженность в целом не очень меньше: там больше сервисов задействовано Последний раз pjsip именно "тек" на 12 версии. У него есть болячки конечно, но не в утечке памяти они уже.
15 и 16 астериски в большом проде на pjsip отрабатывают вполне спокойно нагрузку, большую чем в chan_sip. Не в разы, но проценто это 12-15% прироста стабильно. Работает годами, не течёт. Я не спорю что у него есть проблемы, но их не меньше чем у chan_sip. Зато решать проще. Код понятнее, и в целом лучше. Да и не приходится таскаться с пачами. Залил а mainstream и его быстро приняли.
Отдельная функция PJSIP_DIAL_CONTACTS добавляет гибкости при реализации. Может у меня своя реализация DND которая на сервере, потому что нет её на окорочка в моем офисе, или я хочу её специфично отрабатывать, например, а может я очереди имплементировал через call forking? Не вижу в ней проблемы. Ну точнее она субъективна.
Такие вещи, как в посте, реализовываются при таком подходе вообще прозрачно и без каких нибудь умственных страданий
Пока условный Вы будете возится с IPC, консистентностью и синхронизацией разделяемых данных в многопотоке, условный я будет просто обрабатывать звонки.
Мир не стоит на месте. С потоками давно уже все проще чем вы представляете. Особенно с подобными вашим задачам.
Ну и я не агитирую писать исключительно на форках/мультитредах. Я о другом: при всей моей любви к Lua брать его именно чистую имплементацию без обёртки в LVM менеджера - спорное решение хотя бы потому, что вы задействуете только 1 ядро вашего сервера. Такова изначальная природа Lua. Это встраиваемый язык.
Если уж сильно хочется Lua: напишите свой менеджер LVM тогжа уж или используйте OpenResty, что там ещё... HАproxy? Да можно даже камаилио использовать через evapi в качестве сервера TCP приложений и нормального LVM manager. Ну и если не ограничены в языках: есть Go с его Goroutines. Он быстро учится и легко пишется.
Сегодня у вас 1 астериск, завтра 10. Сегодня у вас все на одном сервере крутится, завтра приложение уйдёт в условный k8s.
Вы же за развитие и за продуманную архитектуру сервисов, пишите умные вещи и неплохие статьи, а стреляйте себе в ногу уже в самом начале... я думаю далее этот диалог ( именно касаемо lua ) если уж сильно хочется можно продолжить на asterconf.ru: обсуждение одного поста в другом мне кажется неправильным с точки зрения этого рессурса ( раз уж я это начал, я это и постараюсь завершить) Ну или можете в ваш следующий ответ касаемо lua линкануть с этим диалогом и продолжим под правильным постом.
Я не считаю это не нормальным осмысленность в понимании того, чем сервис занимается и продумыванием архитектуры взаимодействия сервисов между собой, но я считаю, что проблемы нужно искать там, где они есть, а не придумывать и высказывать их из пальца.
Касаемо того, что я не слишком понял вас: сорян, как у вас написано- так и понял. "Такие вещи как в посте" реализуются вполне в диалплане без дополнительных сервисов. Это вполне простая работа.
Ваше предложение касаемо улучшения диалплана вполне обосновано, но "агитировать" выводить подобные вещи во внешний сервис когда обработка вполне базовая и делается 3-мя строками диалплана через стандартные команды набора - не находите, что это overkill?
Какой бонус от этого? Это не распределенная задача, здесь нет обработки 3-м сервисом доп данных. Подменить callerid на правильный и отключить CDR вполне себе задача астериска которая отлично делается "изнутри" . Зачем это делать через AGI/AMI/ARI? Какой от этого профит? Зачем тут привязывать эту "агитацию"?
Я повстречал и тех кто все лепит в диалплан, и тех кто ВСЕ выносит из диалплана просто потому, что не понимает как это работает. И именно поэтому у меня нет проблем с интерфейсами и API различных систем. Я знаю и умею их применять тогда когда то или иное API нужно.
И да, ваш пост я читал. Америку лично мне вы не открыли.
Ну и раз уж речь зашла: использовать однопоточный Lua как external сервис приложений ( вы же знаете что корутина блокирует выполнение других задач ) - сомнительная идея.
Я агитирую за здравый смысл. Мир не ограничивается двумя цветами. Не все проекты готовы на миграцию на новое АПИ финансово и это нормально. А еще нормально это понимать.
Если есть наработанная кодовая база на dialplan + AMI и она работает зачем все бросать и перепиливать все под чистую на ARI если этого не требует сервис?
Менять подход нужно тогда когда он перестает работать и когда с используемыми методами framework начинается борьба. А просто прийти и сказать со стороны "у вас тут все неправильно, вам нужно все начать сначала и написать с нуля" - не прагматичный подход.
Хорошо быть героем - приходишь в проект где уже все построено и такой- давайте все перепишем! А задуматься над тем насколько это выгодно финансово для проекта- вложить кучу человекочасов в то чтобы никто из клиентов ничего не заметил - это конечно не царское дело.
Ну так это все равно о посылке исходящего трафика и данная пробема не определяет будет ли использован simulcast или SVC, или не будет. Она не определяет даже какой тип сервера может быть использован. Это просто проблема масштабируемости и доступности сервиса.
Это же отправитель шлет несколько потоков, а получатели только принимают их, а значит даже если вам не хватает ширины канала для получателей, это абстрактно ль наличия этих технологий на сервере и никак не влияет на принятие решения об архитектуре решения в целом.
Вы тогда подправьте статью пожалуйста, сказав о том, что ваше ПО так работает и умеет переключаться в режим demux. Вы ведь пишите статью о WebRTC к которому этот стандарт более не применим (по крайней мере на клиентской части ) и вводит читателя в заблуждение.
RTP с RTCP для webrtc давно уже в mux умеют. Поэтому rtp может отдаваться по любому порту, хоть четному, хоть нечетному. Поэтому для webrtc доступно 999. Более того если сервер не умеет в mux то webrtc браузера не будет с таким сервером работать.
Потому что ограничения провайдера на сетевом уровне не влияют на то какая архитектура сервиса будет выбрана. Вряд ли вы решите отказаться от SFU если у вас провайдер лимитирует полосу приёма или отправки. Скорее найдёте правильного провайдера под ваш сервис.
Вы говорите об архитектурах систем видеоконференций, но simulcast и SVC не являются архитнктурными решениями. Они вообще к архитектуре никак не относятся.
Задача нужная и интересная. Сам занимаюсь сейчас написанием rtp2media на go. Не hls но в целом направление то же.
Есть Pion с его webm, ivf, ogg readers и writers.
То есть ещё и opus и vpx поддержка , но надо дописывать свой RTX ( как минимум reader для приема ), что не сложно, но чуть добавляет проблем.
Вообще хотелось бы нормального биндинга libav. Есть вот этот но он субъективно не очень удобный для написания на go. Хотя работа проделана там неплохая.
При желании легко гуглится где я работаю.
Сделайте нагрузочный тест и сравните.
Количество минут в день говорит только о размере сервиса и его общей нагрузке. Просто чтобы указать что это не 2.5 звонков в день. конкретные цифры говорить не буду. И права не имею и в целом это не будет каким либо показателем.
Мы же сравниваем производительность pjsip c chan_sip при одинаковой нагрузке на экземпляр поэтому размер кластера не имеет значения. Но если сильно интересно то это несколько десятков машин around the globe.
Характеристики машин разные в зависимости от локаций серверов и потребностей. В целом это 4 ядра и от 8 до 16 гб оперативки на машину.
Кластер так же динамический и умеет скалировться предиктивно исходя из прогнозируемой пиковой нагрузки. Ну я думаю это очевидно что никто в своем уме и здравой памяти не будет держать инфраструктуру под предельной нагрузкой.
После перехода на pjsip нам нужно чуть меньше экземпляров машин чтобы обслуживать тот же поток траффика.
В конкретно этом проекте пир всего один на машину и он ip2ip trunk до proxy/registrar
del
Так я не говорил про один сервер. Вопрос был в объёме трафика а не в количестве серверов. Конечно же это кластер.
Прокси регистрар - это kamailio. Asterisk это b2bua. Он не может быть прокси по определению.
Да некому больше)
Вы пишите одно, а оказывается подразумеваете другое. Я не должен угадывать, что у вас там в голове и что вы имели ввиду. Сразу написали бы нормально и вопросов не было бы.
Вот уж действительно. Наверное именно поэтому nginx ставят перед кластером nodejs, а не наоборот, исключительно чтобы укратить nodejs, а то ну слишком быстрый он. Именно поэтому kamailio c его fork на старте положить та ещё проблема. Все потому, что решения - полное г*но и спорные.
Да и пусть не дают. А собственно почему это такой краеугольный камень? Каждый сопроцесс изолирован, получает задачу от роутера процессов. Да, стартует дольше и подключает либы каждый сам, да не шарит контекст, но все это решается или локализацией данных или прокидыванием через внешние источники типа shmem/redis/htable. Статику вычитываем при изменениии кэшируем. Done. Более того, это ещё ещё читать потом проще, нежели искать - а что тут контекстное, а что не контекстное.
Если данные динамические - пишем и читаем постоянно. Тут даже вас процитирую.
И заодно отвечу: значит не требуются пока задачи по масштабированию. А тут как раз понадобится что то "с хреновой и слишком дорогой архитектурой" типа haproxy или какого нибудь другого прокси. Ведь окажется что вы утыкаетесь в производительность однопоточного сервиса гораздо раньше чем хотели бы этого. И станет ваш однопоточный сервис просто библиотекой многопоточного сервиса...
Действительно. Не буду тут писать ещё раз пример с openresty и kamailio.
Вы зачем-то так сильно завязываеьесь на контекст в своей аргументации что забываете о том, что им можно и не оперировать, особенно с таких прикладных задачах как ваша...
Под копотом - ничего, но вы же аргументировали изначально это тем , что это долго и сложно:
А теперь вдруг переобулись в то, что это неэффективно оказывается, что это просто блажь с которой вообще непонятно зачем возились и до сих пор возятся, а проекты, построенные на этих принципах как работали быстрее так и работают.
Вы скажете- это древнее г-но мамонта, которое уже никто не использует, но вдруг неожиданно мы видим JANUS sfu проект который написан в 21 веке и является одной из самых популярных и быстрых SFU которая использует preFork. Medooze: pthreads, mediasoup: pthreads. Посмотрим на тесты: https://webrtchacks.com/sfu-load-testing/...
Дальше сами...
Какой то бесконечно бессмысленный спор получается. Думаю, я на этой ноте оставлю вас на едине с собой. Побуду со своей кашей и стереотипов в голове наедине.
Вы очень много объективности отдаёте своей субъективности. Я не говорил о фиче вызова в очереди всех зарегистрированных. Я как раз говорю об обратном: использовать встроенную возможность протокола. И да, добавление механизмов это гибкость. Обычно гибкость называют херью когда не умеют ею пользоваться.
Вы можете думать как вам угодно,
По цифрам: есть сервис где н несколько миллионов минут в день тут регистрации вынесены на proxy registrar.
Тип трафика: что именно интересует? Транспорт? TCP/UDP.
Есть танзит" и не "не транзит". RTP через asterisk. ARI как интерфейс взаимодействия с окружением.
Есть проекты где pjsip работает и как registrar. Там объёма трафика поменьше, - но нагруженность в целом не очень меньше: там больше сервисов задействовано Последний раз pjsip именно "тек" на 12 версии. У него есть болячки конечно, но не в утечке памяти они уже.
15 и 16 астериски в большом проде на pjsip отрабатывают вполне спокойно нагрузку, большую чем в chan_sip. Не в разы, но проценто это 12-15% прироста стабильно. Работает годами, не течёт. Я не спорю что у него есть проблемы, но их не меньше чем у chan_sip. Зато решать проще. Код понятнее, и в целом лучше. Да и не приходится таскаться с пачами. Залил а mainstream и его быстро приняли.
Отдельная функция PJSIP_DIAL_CONTACTS добавляет гибкости при реализации. Может у меня своя реализация DND которая на сервере, потому что нет её на окорочка в моем офисе, или я хочу её специфично отрабатывать, например, а может я очереди имплементировал через call forking? Не вижу в ней проблемы. Ну точнее она субъективна.
Оставим вашу впечатлительность с вами на едине.
Я понял так как написали:
Мир не стоит на месте. С потоками давно уже все проще чем вы представляете. Особенно с подобными вашим задачам.
Ну и я не агитирую писать исключительно на форках/мультитредах. Я о другом: при всей моей любви к Lua брать его именно чистую имплементацию без обёртки в LVM менеджера - спорное решение хотя бы потому, что вы задействуете только 1 ядро вашего сервера. Такова изначальная природа Lua. Это встраиваемый язык.
Если уж сильно хочется Lua: напишите свой менеджер LVM тогжа уж или используйте OpenResty, что там ещё... HАproxy? Да можно даже камаилио использовать через evapi в качестве сервера TCP приложений и нормального LVM manager. Ну и если не ограничены в языках: есть Go с его Goroutines. Он быстро учится и легко пишется.
Сегодня у вас 1 астериск, завтра 10. Сегодня у вас все на одном сервере крутится, завтра приложение уйдёт в условный k8s.
Вы же за развитие и за продуманную архитектуру сервисов, пишите умные вещи и неплохие статьи, а стреляйте себе в ногу уже в самом начале... я думаю далее этот диалог ( именно касаемо lua ) если уж сильно хочется можно продолжить на asterconf.ru: обсуждение одного поста в другом мне кажется неправильным с точки зрения этого рессурса ( раз уж я это начал, я это и постараюсь завершить) Ну или можете в ваш следующий ответ касаемо lua линкануть с этим диалогом и продолжим под правильным постом.
Я не считаю это не нормальным осмысленность в понимании того, чем сервис занимается и продумыванием архитектуры взаимодействия сервисов между собой, но я считаю, что проблемы нужно искать там, где они есть, а не придумывать и высказывать их из пальца.
Касаемо того, что я не слишком понял вас: сорян, как у вас написано- так и понял. "Такие вещи как в посте" реализуются вполне в диалплане без дополнительных сервисов. Это вполне простая работа.
Ваше предложение касаемо улучшения диалплана вполне обосновано, но "агитировать" выводить подобные вещи во внешний сервис когда обработка вполне базовая и делается 3-мя строками диалплана через стандартные команды набора - не находите, что это overkill?
Какой бонус от этого? Это не распределенная задача, здесь нет обработки 3-м сервисом доп данных. Подменить callerid на правильный и отключить CDR вполне себе задача астериска которая отлично делается "изнутри" . Зачем это делать через AGI/AMI/ARI? Какой от этого профит? Зачем тут привязывать эту "агитацию"?
Я повстречал и тех кто все лепит в диалплан, и тех кто ВСЕ выносит из диалплана просто потому, что не понимает как это работает. И именно поэтому у меня нет проблем с интерфейсами и API различных систем. Я знаю и умею их применять тогда когда то или иное API нужно.
И да, ваш пост я читал. Америку лично мне вы не открыли.
Ну и раз уж речь зашла: использовать однопоточный Lua как external сервис приложений ( вы же знаете что корутина блокирует выполнение других задач ) - сомнительная идея.
Я агитирую за здравый смысл. Мир не ограничивается двумя цветами.
Не все проекты готовы на миграцию на новое АПИ финансово и это нормально.
А еще нормально это понимать.
Если есть наработанная кодовая база на dialplan + AMI и она работает зачем все бросать и перепиливать все под чистую на ARI если этого не требует сервис?
Менять подход нужно тогда когда он перестает работать и когда с используемыми методами framework начинается борьба. А просто прийти и сказать со стороны "у вас тут все неправильно, вам нужно все начать сначала и написать с нуля" - не прагматичный подход.
Судя по всему вы знаете как я ожидаю/хочу
Собственно давайте в конкретику лучше:
Куда не туда вас ведет PJSIP и какие не такие пути он вам дает?
Чем PJSIP плох?
Хорошо быть героем - приходишь в проект где уже все построено и такой- давайте все перепишем! А задуматься над тем насколько это выгодно финансово для проекта- вложить кучу человекочасов в то чтобы никто из клиентов ничего не заметил - это конечно не царское дело.
Ну так это все равно о посылке исходящего трафика и данная пробема не определяет будет ли использован simulcast или SVC, или не будет. Она не определяет даже какой тип сервера может быть использован. Это просто проблема масштабируемости и доступности сервиса.
Это же отправитель шлет несколько потоков, а получатели только принимают их, а значит даже если вам не хватает ширины канала для получателей, это абстрактно ль наличия этих технологий на сервере и никак не влияет на принятие решения об архитектуре решения в целом.
Вы тогда подправьте статью пожалуйста, сказав о том, что ваше ПО так работает и умеет переключаться в режим demux. Вы ведь пишите статью о WebRTC к которому этот стандарт более не применим (по крайней мере на клиентской части ) и вводит читателя в заблуждение.
RTP с RTCP для webrtc давно уже в mux умеют. Поэтому rtp может отдаваться по любому порту, хоть четному, хоть нечетному. Поэтому для webrtc доступно 999. Более того если сервер не умеет в mux то webrtc браузера не будет с таким сервером работать.
Потому что ограничения провайдера на сетевом уровне не влияют на то какая архитектура сервиса будет выбрана. Вряд ли вы решите отказаться от SFU если у вас провайдер лимитирует полосу приёма или отправки. Скорее найдёте правильного провайдера под ваш сервис.
Вы говорите об архитектурах систем видеоконференций, но simulcast и SVC не являются архитнктурными решениями. Они вообще к архитектуре никак не относятся.