Откуда такая интересная классификация серверов? Почему simulcast и SVC переехали из технологий управления качеством входящего изображения в виды серверов конечной поставки данных?
Ничто не мешает использовать simulcast или SVC как на SFU так и на MCU.
В вашем случае это не Asterisk/freeswitch а другое ПО но сути это не меняет
Разницы в SRTP или RTP тут нет
Ну и в целом нет смысла тащить Network в докер для Reatime Communitation просто по той причине что для нескольких инстансов так или иначе придется мапить диапазон портов на рызные диапазоны портов хоста
профита в виде еще одного NAT нет.
Так тут не в архитектуре построения приложений дело. Тут ведь проблема в том как работает докер. Не важно ведь сколько там будет комнат, тайминги при обработке RTP могут поехать и в 1 комнате с 2 участниками очень легко.
Тут нужно либо тонко ядро хост системы настраивать либо использовать сеть хоста.
Я бы добавил все таки в статью пометку - предостережение о том что в виртуальных сетях докера не стоит поднимать RTC продакшн решения и использовать их только в для dev.
Его не выкинули. Webrtc - signalling agnostic технология. Хотите SIP - используйте SIP.
Другое дело что SIP далеко не всегда там необходим. Он несёт в себе много routing функционала который для сигнализации webrtc зачастую просто не нужен.
Зачем запихивать в статью о PBX упоминание проки ( kamailio )?
А по существу : при всех достоинствах yate ( замечательная задумка движка, которая обеспечивает неплохую производительность по нагрузке ) наличие неуправляемого NAT резолвера, который ни в какую ни считается с rfc3261 и ломает маршрутизирующие хедеры, так и его привентивый BYE впихнуть во ме немыслимые сценарии обработки failure вызовов - делают из него поделку и не более.
Ну почему chan_sip то в 2020 и на 16 астериске когда есть pjsip?
Chan_sip deprecated уже давно и не поддерживается разработчиками. Если уж несёте в массы VoIP то несите релевантные модули.
Проблема в том, что каждый вендор тянул, тянет и будет тянуть одеяло на себя. Идея унификации не нова и даже очень хороша, но вендоры- это любители посадить на иглу, поэтому действуют в большинстве своём исходя из логики — купите у нас партию задешево, вы вам построим всю архитектуру, а потом, когда вы поймёте, что наше оборудование ломается чаще чем вы его используете, будет уже поздно, так как вся инфраструктура проприетарная и вы уже по уши в ней. И, либо много денег на переезд на другую инфру и переписывать Api на другой, либо сидеть с тем же и есть что дали…
Один порт у asterisk к проблеме определения входящего вызова не имеет никакого отношения: проблема в том что, если девайс в sip.conf описан как friend, а в поле from приходит source number того, кто звонит вместо имени девайса, который написан в [...] в sip.conf то asterisk будет соотносить входящие по IP:PORT с которого прилетел звонок, а так как у GoIP в вашем случае он один и тот же для всех — asterisk отождествит входящий с первой попавшейся линией.
В Вашем случае вы просто передаете номер звонящего в Remote-Party-ID хедере и asterisk его оттуда читает.
На самом деле самое простое решение вашей проблемы — изменить в advanced voip настройку порта Для каждой линии. То есть линию 1 повесить на порт 5060, линию 2 — на порт 5061 и т.д. А на asterisk использовать тип peer, так как авторизация вам тут не нужна вообще, а goip на сколько я помню умеет работать в режиме IP2IP.
Ну и 2 девайса (in и out ) в настройке asterisk — тоже лишнее.
Откажитесь от вызова System. Любой внешний вызов через System/Exec и тд очень сильно грузит систему, что особенно заметно при хорошей нагрузке.
Если нужно выполнение внешнего скрипта в любой задаче — пишите нормальный демон скрипта и кидайте ему данные через curl, например, или слушайте астериск через AMI/ARI.
Прошу прощения за ошибки: сначала не увидел, а потом уже не было возможности поправить так как писал с телефона. Да и сейчас не вижу кнопки редактирования коммента.
В нидерландах есть такое понятие как high sckilled migrant. Это словосочетание обеспечивает (практически всегда) 30% tax rulling что приятно сказывается на зарплате. Это имеет двойной эффект как для работника так и для работодателя, потому что работодатель может предложить gross меньше, но выхлоп будет для работника будет такой же как если бы он получал больший gross без tax rulling ( 65000 с tax rulling будет равно примерно 78000 без него) а 65 000 тут даже без tax rulling считается хорошей оплатой. Особенно если жить не в Амстердаме, где жилье owerpriced.
Поэтому для работодателя выгодно нанимать high sckilled migrant ( если работодатель имеет разрешение на подобный найм) так как ему платить в итоге меньше приходится.
при чем тут практический смысл и название протокола?
Есть протокол WS он может использовать как транспорт транспорт TCP (WS) так и TLS (WSS). Сам протокол при этом остается тем же самым, отличаются только заголовки согласования соединения на этапе HTTP запросов, так что обозначать WS или WSS с практической точки зрения да и с точки зрения здравого смысла — как на клиенте так и на сервере НЕТ, так как данные после установления соединения будут идти по установленному траcпортному каналу, коим будет являться или TCP или TLS.
Более того, WS может не обязательно использоваться в web
многие предпочитают этот протокол как межсерверный (тот же астериск для отсылки events по ARI)
И там вполне можно это делать по незащищенному каналу ибо нет смысла нагружать приложение в локальной среде.
На нашем астериске настроен WSS протокол для SIP. И астер ожидает в параметрах соединения именно его, но библиотека JSSIP упорно отправляет WS несмотря ни на какую конфигурацию. Разработчики библиотеки при этом упорно тыкают в стандарты, в которых действительно нет никаких требований по этому поводу. А коллеги из астера упорно не хотят ничего исправлять. В общем, тупик. Ну а мы в это время находим в исходниках строку this._configuration.contact_uri = new URI(...), меняем transport: 'ws' на transport: 'wss' и продолжаем радоваться жизни.
Напишите нормально, что хотели сказать. Из написанного вами не понятно в чем дело…
Напишите просто, что астер исходя из параметра в contact выбирает не шифрованный ws для доставки сообщений, когда нужен шифрованный.
Откуда такая интересная классификация серверов? Почему simulcast и SVC переехали из технологий управления качеством входящего изображения в виды серверов конечной поставки данных?
Ничто не мешает использовать simulcast или SVC как на SFU так и на MCU.
Проблема кроется в том как работает Docker: в том как он синхронизируется CPU и как выделяются рессурсы.
Чтобы не повторяться оставлю ссылку на kamailio.ru/kamailio-conf от 2019 года. Тут отлично освещена эта проблема и очень хорошо подана.
Смотрите с 4:06:50
https://www.youtube.com/watch?v=D3OJvNQ4-uI
В вашем случае это не Asterisk/freeswitch а другое ПО но сути это не меняет
Разницы в SRTP или RTP тут нет
Ну и в целом нет смысла тащить Network в докер для Reatime Communitation просто по той причине что для нескольких инстансов так или иначе придется мапить диапазон портов на рызные диапазоны портов хоста
профита в виде еще одного NAT нет.
Тут нужно либо тонко ядро хост системы настраивать либо использовать сеть хоста.
Я бы добавил все таки в статью пометку - предостережение о том что в виртуальных сетях докера не стоит поднимать RTC продакшн решения и использовать их только в для dev.
Его не выкинули. Webrtc - signalling agnostic технология. Хотите SIP - используйте SIP.
Другое дело что SIP далеко не всегда там необходим. Он несёт в себе много routing функционала который для сигнализации webrtc зачастую просто не нужен.
Зачем запихивать в статью о PBX упоминание проки ( kamailio )?
А по существу : при всех достоинствах yate ( замечательная задумка движка, которая обеспечивает неплохую производительность по нагрузке ) наличие неуправляемого NAT резолвера, который ни в какую ни считается с rfc3261 и ломает маршрутизирующие хедеры, так и его привентивый BYE впихнуть во ме немыслимые сценарии обработки failure вызовов - делают из него поделку и не более.
Ну почему chan_sip то в 2020 и на 16 астериске когда есть pjsip?
Chan_sip deprecated уже давно и не поддерживается разработчиками. Если уж несёте в массы VoIP то несите релевантные модули.
Проблема в том, что каждый вендор тянул, тянет и будет тянуть одеяло на себя. Идея унификации не нова и даже очень хороша, но вендоры- это любители посадить на иглу, поэтому действуют в большинстве своём исходя из логики — купите у нас партию задешево, вы вам построим всю архитектуру, а потом, когда вы поймёте, что наше оборудование ломается чаще чем вы его используете, будет уже поздно, так как вся инфраструктура проприетарная и вы уже по уши в ней. И, либо много денег на переезд на другую инфру и переписывать Api на другой, либо сидеть с тем же и есть что дали…
В Вашем случае вы просто передаете номер звонящего в Remote-Party-ID хедере и asterisk его оттуда читает.
На самом деле самое простое решение вашей проблемы — изменить в advanced voip настройку порта Для каждой линии. То есть линию 1 повесить на порт 5060, линию 2 — на порт 5061 и т.д. А на asterisk использовать тип peer, так как авторизация вам тут не нужна вообще, а goip на сколько я помню умеет работать в режиме IP2IP.
Ну и 2 девайса (in и out ) в настройке asterisk — тоже лишнее.
Если нужно выполнение внешнего скрипта в любой задаче — пишите нормальный демон скрипта и кидайте ему данные через curl, например, или слушайте астериск через AMI/ARI.
www.iamexpat.nl/career/employment-news/2019-income-requirements-residence-highly-skilled-migrant-netherlands
и минимальный порог для начисления 30% ruling, то реально его получить только high skilled
В нидерландах есть такое понятие как high sckilled migrant. Это словосочетание обеспечивает (практически всегда) 30% tax rulling что приятно сказывается на зарплате. Это имеет двойной эффект как для работника так и для работодателя, потому что работодатель может предложить gross меньше, но выхлоп будет для работника будет такой же как если бы он получал больший gross без tax rulling ( 65000 с tax rulling будет равно примерно 78000 без него) а 65 000 тут даже без tax rulling считается хорошей оплатой. Особенно если жить не в Амстердаме, где жилье owerpriced.
Поэтому для работодателя выгодно нанимать high sckilled migrant ( если работодатель имеет разрешение на подобный найм) так как ему платить в итоге меньше приходится.
DTLS-SRTP отменили уже?
Есть протокол WS он может использовать как транспорт транспорт TCP (WS) так и TLS (WSS). Сам протокол при этом остается тем же самым, отличаются только заголовки согласования соединения на этапе HTTP запросов, так что обозначать WS или WSS с практической точки зрения да и с точки зрения здравого смысла — как на клиенте так и на сервере НЕТ, так как данные после установления соединения будут идти по установленному траcпортному каналу, коим будет являться или TCP или TLS.
Более того, WS может не обязательно использоваться в web
многие предпочитают этот протокол как межсерверный (тот же астериск для отсылки events по ARI)
И там вполне можно это делать по незащищенному каналу ибо нет смысла нагружать приложение в локальной среде.
Не правильно. Уровень приложения не в ответе за транспортный уровень.
Напишите нормально, что хотели сказать. Из написанного вами не понятно в чем дело…
Напишите просто, что астер исходя из параметра в contact выбирает не шифрованный ws для доставки сообщений, когда нужен шифрованный.