System может плохо отрабатывать на больших нагрузках + можно уменьшить количество скриптов если использовать базу данных как хранилище недоставленных сообщений ( например sqlite или odbc ). Тогда останется только один скрипт, который будет по крону ходить в бд и формировать call file, или даже сразу вызывать originate на context через cli.
Потому что вы заявляетесь как "Больше чем Zoom", а в статье описано стандартное коробочное и довольно консервативное решение. Не понятно чем вы "больше чем Zoom".
Чтобы быть хотя бы равным условному Zoom - сервис должен уметь собираться в смешанное решение которое умеет расширяться и предоставляет дополнительные сервисы помимо базовой связи, что не возможно без работы ядра системы именно как SFU, так как это самый эффективный способ расширения. MCU в таких сервисах выступает как Gateway для конечных пользователей которые подсоединяются с девайсов не поддерживающих multiple media streams.
Я понимаю что оно ориентировано на большой бизнес и госсектор, а так же покупку/настройку уже имеющихся необходимых SIP/H.323 клиентов под него, но по функционалу и возможностям расширения исходя из того что написано в статье даже сравнивать это решение с Zoom и подобным сервисам пока рано.
Рынок сжимается не потому что облака, а потому что webrtc и новые подходы, а так же ПО, которое умеет эти новые подходы. Это развязывает руки строить свои приложения и на клиентской стороне рендерить сетку и не нагружать этим сервер. Ну и сами сервера за счёт этого становятся куда более расширяемыми горизонтально.
Каналы пользователей можно не грузить ненужным трафиком если использовать правильные подходы и технологии ( simulcast, svc, speaker detection, framerate adjusting и тд ). SFU подход дешевле выходит. Кроме того на MCU дефакто почти невозможно построить распределенную систему виеоконференц связи особенно если сервис рамазан по различным географическим точкам и собеседники находятся на разных концах этих точек.
Так что это не оправдание использованию MCU ( по крайней мере для видео ). Поэтому стоит очтановиться на "не для продакшн пока".
Все верно, но давайте не забывать, что архивация и разархивация забирают ресурсы, и синтез текста текста в голос тоже. Все это при работе на конечном устройстве пользователя например в конференции между несколькими людьми пока что занимает больше времени и ресурсов чем кодирование и декодирование голосового сигнала
Хотя справедливости ради: подход с пересылкой метаданных и последующей их интерпретации несомненно имеет сильно больше преимуществ нежели пересылка реальных кодированных данных. Достаточно посмотреть на последние эксперbменты с видео кодеками от nVidea https://www.youtube.com/watch?v=NqmMnjJ6GEg&t=2s
Касаемо - где использовать такой низкий битрейт: В видео конференциях например Тут практически всегда довольно остро стоит вопрос доступной полосы ее стараются уменьшить за счет всего что только можно
Достаточно посмотреть на техники применяемые тем же google meets: - деградирование фреймрейта и битрейта картинки участников конференции (Вплоть до отключения их видео ) ради улучшения качества screen sharing например - урезание количества каналов приемника аудио связи и тд И это все ради повышения качества картинки
Высвободить несколько десятков кбит/с в голосе - тоже идет в расчет
но если говорить о НЕ RTC то такой подход может оправдан.
Тут важно понять не приблизимся ли мы в итоге к тому же количеству информации в итоге что несет в себе media payload. И если да то тогда нет особого смысла в таком подходе.
Если низкий битрейт сопряжен с потерями сигнала то потери при передаче текстовых данных не дадут их восстановить. С голосом проще - даже если часть данных не долетит, то ее вполне можно проиграть и понять.
Например пресловутый hello world:
Если мы его отправим некоторое и при этом потеряем скажем O в слове hello и L в world то при синтезе получим условно hell word что в целом поменяет контекст.
При передаче голосового сигнала контекст может быть более понятен из-за интонационного окраса и соответсвенно даже при относительно большой потере данных ( до 7%) - суть сообщения читается без особых проблем.
Ну, мне видео не монтировать и фото не ретушировать, а код писать да кино посмотреть - глаз не ломает. Вот сейчас смотрю то в Мак то в Lenovo и как-то в Lenovo нормально смотрится. Мб они и унылые по спекам, но мне хватает. Свои 700 EU он отрабатывает на 146%.
Это конечно субъективно, но мне как программисту FHD за глаза. Это было релевантно и для 13 для 15(16). У меня на маке разрешение сильно больше, но мне не менее комфортно работать от этого за 15 дюймовым Lenovo с FHD
Про пространство - я не про количество виртуальных рабочих столов. Их мне что на винде хватало что на Linux хватает. Это не killer feature макбуков Про пространство я говорю - именно о пространстве на экране Та же IDE сильно удобнее выглядит на 15 дюймовом дисплее нежели на 13. При работе в VSCode например сильно видна разница.
Про спину - Вы в командировки с собой монитор не повезете да и не всегда есть возможность его использовать. При этом 15 сильно выигрывает в фокусном расстоянии. Хотя казалось бы - да. Пара сантиметров. Да и потом в чем плюс 13 сейчас? 15 дюймовые ноуты весят 1.5 кило в среднем. 200-300 грамм разницы по-моему не такая уж большая цена за комфорт.
Проблема 13 не в плохих дисплеях- проблема в размере экрана. Зрение садится только в путь, горбишься, так как постоянно машинально приближаешься к ноутбуку на более близкое расстояние. Да и пространства для работы мало.
Именно эти факторы и заставили меня пересесть на 15. Спина больше не устаёт. Сижу за ним теперь на нормальном расстоянии.
К вопросу о релевантности соотношения цена- качество:
У меня рабочий - mac 16 2020 года, свой же - скромный thinkpad 15 серии Е ( 700 EU ) на котором стоит Linux. И при выборе - на чем же удобнее печатать ( да и работать ) - я выбираю thinkpad. При чем он на столько удобный что я даже выносную клаву себе купил trackpad ( такая же как на ноуте ) просто потому что она очень удобная и приятная. Гораздо лучше маковской ( которая у меня к слову тоже есть. Выдали на работе. Лежит пылится ).
У него хорошая батарея которая на Linux до 5 часов держит ( не так дрова оптимизированы как под Windows, ну или я их недонастроил )
Весит он 1.7 кило на сколько я помню.
Корпус - пластик, да. Но не сказать что он плохого качества.
До этого пользовался hp probook 13 ( 2,3,4 поколения были в семье ). Тоже хорошие ноутбуки, при этом в разы дешевле аналогов по железу и держат до 8 часов на Windows. Слез потому чтт 15 от lenovo оказалась и меньше и дешевле.
Так что при правильном выборе ноута - можно сильно подрезать ценник и все ещё иметь крайне удобный инструмент для работы.
HTTP со времен 1.1 по дефолту использует постоянный коннект. HTTP/2.0 игнорирует заголовок Connection. Браузеры максимально держат соединение до сервиса.
Ну и неожиданно websocket это обычный tcp. Так что технически нет разнице в транспорте для http и ws.
У http было одно преимущество перед ws - это реализация на его уровне досылки HTTP сообщений при переустановлении соединения. Чистый ws это просто транспорт и в нем нет этого из коробки. Но во всяких прикладных настройках типа socket.io это уже давно реализовано.
Как интересно наблюдать за тем как Web разработчики открывают для себя транспортные протоколы и идеологии толстых и тонких клиентов спустя десятки лет после их создания...
Все это хорошо если только не одно но: наниматели ищут по стэку. И им не видно что такой full stack может все - и в VoIP и в Web и в IoT. Им нужен тот кто умеет или одно или другое.
Даже работая в офисе все переписки ведёшь в чате. Вот так вот подойти к кому-то и что-то спросить стало уже архаизмом. За кофе обычно о жизни болтали и о не связанных с работой вещах.
System может плохо отрабатывать на больших нагрузках + можно уменьшить количество скриптов если использовать базу данных как хранилище недоставленных сообщений ( например sqlite или odbc ). Тогда останется только один скрипт, который будет по крону ходить в бд и формировать call file, или даже сразу вызывать originate на context через cli.
Нет, не отработает. Но в этом и задача sipp: Гонять конкретные сценарии и ожидать конкретного поведения от тестируемого сервиса.
Наверное не "recovery response" а "receive response"...
Потому что вы заявляетесь как "Больше чем Zoom", а в статье описано стандартное коробочное и довольно консервативное решение. Не понятно чем вы "больше чем Zoom".
Чтобы быть хотя бы равным условному Zoom - сервис должен уметь собираться в смешанное решение которое умеет расширяться и предоставляет дополнительные сервисы помимо базовой связи, что не возможно без работы ядра системы именно как SFU, так как это самый эффективный способ расширения. MCU в таких сервисах выступает как Gateway для конечных пользователей которые подсоединяются с девайсов не поддерживающих multiple media streams.
Я понимаю что оно ориентировано на большой бизнес и госсектор, а так же покупку/настройку уже имеющихся необходимых SIP/H.323 клиентов под него, но по функционалу и возможностям расширения исходя из того что написано в статье даже сравнивать это решение с Zoom и подобным сервисам пока рано.
Почему именно MCU? Почему не SFU?
Рынок сжимается не потому что облака, а потому что webrtc и новые подходы, а так же ПО, которое умеет эти новые подходы. Это развязывает руки строить свои приложения и на клиентской стороне рендерить сетку и не нагружать этим сервер. Ну и сами сервера за счёт этого становятся куда более расширяемыми горизонтально.
Каналы пользователей можно не грузить ненужным трафиком если использовать правильные подходы и технологии ( simulcast, svc, speaker detection, framerate adjusting и тд ). SFU подход дешевле выходит. Кроме того на MCU дефакто почти невозможно построить распределенную систему виеоконференц связи особенно если сервис рамазан по различным географическим точкам и собеседники находятся на разных концах этих точек.
Так что это не оправдание использованию MCU ( по крайней мере для видео ). Поэтому стоит очтановиться на "не для продакшн пока".
Вы всегда пишете об MCU, но ни разу не рассматривали SFU как сервер. Это потому, что продукт не умеет в SFU?
Все верно, но давайте не забывать, что архивация и разархивация забирают ресурсы, и синтез текста текста в голос тоже.
Все это при работе на конечном устройстве пользователя например в конференции между несколькими людьми пока что занимает больше времени и ресурсов чем кодирование и декодирование голосового сигнала
Хотя справедливости ради: подход с пересылкой метаданных и последующей их интерпретации несомненно имеет сильно больше преимуществ нежели пересылка реальных кодированных данных.
Достаточно посмотреть на последние эксперbменты с видео кодеками от nVidea
https://www.youtube.com/watch?v=NqmMnjJ6GEg&t=2s
Касаемо - где использовать такой низкий битрейт:
В видео конференциях например
Тут практически всегда довольно остро стоит вопрос доступной полосы
ее стараются уменьшить за счет всего что только можно
Достаточно посмотреть на техники применяемые тем же google meets:
- деградирование фреймрейта и битрейта картинки участников конференции (Вплоть до отключения их видео ) ради улучшения качества screen sharing например
- урезание количества каналов приемника аудио связи и тд
И это все ради повышения качества картинки
Высвободить несколько десятков кбит/с в голосе - тоже идет в расчет
но если говорить о НЕ RTC то такой подход может оправдан.
Тут важно понять не приблизимся ли мы в итоге к тому же количеству информации в итоге что несет в себе media payload. И если да то тогда нет особого смысла в таком подходе.
Если низкий битрейт сопряжен с потерями сигнала то потери при передаче текстовых данных не дадут их восстановить. С голосом проще - даже если часть данных не долетит, то ее вполне можно проиграть и понять.
Например пресловутый hello world:
Если мы его отправим некоторое и при этом потеряем скажем O в слове hello и L в world то при синтезе получим условно hell word что в целом поменяет контекст.
При передаче голосового сигнала контекст может быть более понятен из-за интонационного окраса и соответсвенно даже при относительно большой потере данных ( до 7%) - суть сообщения читается без особых проблем.
Ну, мне видео не монтировать и фото не ретушировать, а код писать да кино посмотреть - глаз не ломает. Вот сейчас смотрю то в Мак то в Lenovo и как-то в Lenovo нормально смотрится. Мб они и унылые по спекам, но мне хватает. Свои 700 EU он отрабатывает на 146%.
Кстати да, корпус - сплав , присмотрелся сейчас. пластик толкьо вкоруг клавы. Tак что тут наврал.
У меня модель без сканера отпечатков пальцев.
У моей жены рабочий - Т серия.
Кстати мало чем отличается от E кроме цены в 1500 EU :-)
Но сканер там есть. Правда она под виндой работает.
Это конечно субъективно, но мне как программисту FHD за глаза. Это было релевантно и для 13 для 15(16). У меня на маке разрешение сильно больше, но мне не менее комфортно работать от этого за 15 дюймовым Lenovo с FHD
Про пространство - я не про количество виртуальных рабочих столов. Их мне что на винде хватало что на Linux хватает. Это не killer feature макбуков
Про пространство я говорю - именно о пространстве на экране
Та же IDE сильно удобнее выглядит на 15 дюймовом дисплее нежели на 13. При работе в VSCode например сильно видна разница.
Про спину - Вы в командировки с собой монитор не повезете да и не всегда есть возможность его использовать. При этом 15 сильно выигрывает в фокусном расстоянии. Хотя казалось бы - да. Пара сантиметров.
Да и потом в чем плюс 13 сейчас? 15 дюймовые ноуты весят 1.5 кило в среднем. 200-300 грамм разницы по-моему не такая уж большая цена за комфорт.
Но, да. Все субъективно конечно.
Проблема 13 не в плохих дисплеях- проблема в размере экрана. Зрение садится только в путь, горбишься, так как постоянно машинально приближаешься к ноутбуку на более близкое расстояние. Да и пространства для работы мало.
Именно эти факторы и заставили меня пересесть на 15. Спина больше не устаёт. Сижу за ним теперь на нормальном расстоянии.
К вопросу о релевантности соотношения цена- качество:
У меня рабочий - mac 16 2020 года, свой же - скромный thinkpad 15 серии Е ( 700 EU ) на котором стоит Linux. И при выборе - на чем же удобнее печатать ( да и работать ) - я выбираю thinkpad. При чем он на столько удобный что я даже выносную клаву себе купил trackpad ( такая же как на ноуте ) просто потому что она очень удобная и приятная. Гораздо лучше маковской ( которая у меня к слову тоже есть. Выдали на работе. Лежит пылится ).
У него хорошая батарея которая на Linux до 5 часов держит ( не так дрова оптимизированы как под Windows, ну или я их недонастроил )
Весит он 1.7 кило на сколько я помню.
Корпус - пластик, да. Но не сказать что он плохого качества.
До этого пользовался hp probook 13 ( 2,3,4 поколения были в семье ). Тоже хорошие ноутбуки, при этом в разы дешевле аналогов по железу и держат до 8 часов на Windows. Слез потому чтт 15 от lenovo оказалась и меньше и дешевле.
Так что при правильном выборе ноута - можно сильно подрезать ценник и все ещё иметь крайне удобный инструмент для работы.
HTTP со времен 1.1 по дефолту использует постоянный коннект. HTTP/2.0 игнорирует заголовок Connection. Браузеры максимально держат соединение до сервиса.
Ну и неожиданно websocket это обычный tcp. Так что технически нет разнице в транспорте для http и ws.
У http было одно преимущество перед ws - это реализация на его уровне досылки HTTP сообщений при переустановлении соединения. Чистый ws это просто транспорт и в нем нет этого из коробки. Но во всяких прикладных настройках типа socket.io это уже давно реализовано.
Как интересно наблюдать за тем как Web разработчики открывают для себя транспортные протоколы и идеологии толстых и тонких клиентов спустя десятки лет после их создания...
Все это хорошо если только не одно но: наниматели ищут по стэку. И им не видно что такой full stack может все - и в VoIP и в Web и в IoT. Им нужен тот кто умеет или одно или другое.
Мифический узкий канал связи:
Даже работая в офисе все переписки ведёшь в чате. Вот так вот подойти к кому-то и что-то спросить стало уже архаизмом. За кофе обычно о жизни болтали и о не связанных с работой вещах.