Для индексации полезных и бесполезных разговоров

[notify_ded_bot]

Кажется уловил. Спасибо, буду пробовать

[notify_ded_bot]

Ну просто очередь не умеет узнавать статус сип эндпоинта который находится за транком. Если вы пропишете в аргументе state_interface ссылку на транк типа PJSIP/trunk, то будут разные приколы - получив один звонок астериск будет считать что этот "транк" уже занят звонком и не распределит следующие.

Я это и не предлагаю. :)

[notify_ded_bot]

угу, осталось его подружить с state_interface как-то

как-то так
; Конечная точка, куда шлем пакеты (Нода-Б)
[nodeB-pub]
type=endpoint
transport=transport-udp
aors=nodeB-pub
context=default

[nodeB-pub]
type=aor
contact=sip:IP_АДРЕС_НОДЫ_Б:5060

; Настройка исходящей публикации статусов
[nodeB-devicestate]
type=outbound-publish
server_uri=sip:nodeB-pub
event=asterisk-devicestate ; Важнейший параметр: тип события Asterisk

; Настройка входящей публикации (разрешаем Ноде-Б присылать нам статусы)
[nodeB-inbound]
type=inbound-publication
event_asterisk-devicestate=nodeB-pub

; Объединяющий блок публикации
[nodeB-state-exchange]
type=asterisk-publication
devicestate_publish=nodeB-devicestate
device_state=yes

[notify_ded_bot]

Проблема в том, что у меня регистрация пользователей хранится на другой вообще ноде, не астер. И у меня при входящих не отрабатывает очередь звонков, т.к астер не знает состояние сипучеток.
Что то в гугле не нашел ничего. Пока из идей это написать "движок" который будет генерить SUBSCRIBE и как то запихивать это в память астериска, если это возможно.
На крайний случай писать кастомную очередь на AGI или FastAGI

Я просто перед вызовом удалённых пиров по http-ami запрашивал их текущий статус (но это был не нагруженный колл-центр, а станция с относительно небольшим количеством звонков (до 1000 в день)

[notify_ded_bot]

Там всего одна библиотека затронута, можно весь пакет не ставить

У кого стоит nginx там тоже дырка, тоже нужно обновлять

[notify_ded_bot]

У кого стоит nginx там тоже дырка, тоже нужно обновлять

в версиях 1.30.0-1.30.5 и 1.31.2-1.31.6

если стоит более старая, но с патчами против других выявленных ранее уязвимостей — там скорее всего этой дырки нет

[notify_ded_bot]

Сангома пишет, что пофиксили в 17 freepbx https://go.sangoma.com/e3t/Ctc/Y+113/d5hz9404/VVKWlD7Z0NGfW25zbCq2SfYTgW7xsyK95Wv0zpN3JhCGH3qgz0W7Y8-PT6lZ3lYW8nNvgp1mv-YwW52dJf66Tm7pTW5MH3g143Rm_tN5TDDLwYHMnDW5-8YGw3xwD91W2ycp_r1Wv-TvW24Xctq6H36T_W6x_ZDw5N7tl8W5FH5rX8k9F-QW7hQTLk3ZrWSsW4PDnLM5qKzT3W5yhm052kdmWJW8h6QDG2fy4VGW4gnYSZ6QLKRYN2VcHFN-mN4zW7tg5Sy4pv5w8W7DhZfX3271VSW4bYq2w57lwrDW4Lzdqs8YfQQtW95N9Wv6xQPKNW6xqdDy1nxK7zW62DsxK1W12mPW3JybLZ7dK3BKW4p-B6q2G2Qf0VBBMPS8Y9FPFVdK4bc5gYXG2f89FWv404

А вот интересно, как вокслинк решил эту проблему. Там где на роки 9 установлен фрипбх 15 с php 5.6. А то вроде эта cve затронула версии php от 5.4 и выше. Есть ли для этого дистрибутива адекватное решение без переустановки всего на новый дистр!?

[notify_ded_bot]

ну вот взял и решил)

[notify_ded_bot]

А вот интересно, как вокслинк решил эту проблему. Там где на роки 9 установлен фрипбх 15 с php 5.6. А то вроде эта cve затронула версии php от 5.4 и выше. Есть ли для этого дистрибутива адекватное решение без переустановки всего на новый дистр!?

а вас не смущает, что fp15 это примерно 2020 года продукт и там кроме php куча язвимостей может быть?

[notify_ded_bot]

минусы: — мы живем во время ии: уязвимости находятся быстро
плюсы: — мы живем во время ии: уязвимости закрываются быстро