Везде в доках про НА написано corosync + drbd но на мой взгляд это бд вынести на отдельный хост и вместо corosync использовать keepalived и будет схема простая как карбюратор, а при выходе из backup в master пнуть старт астериск чтобы произвести актуальную генерацию конфигов
Везде в доках про НА написано corosync + drbd но на мой взгляд это бд вынести на отдельный хост и вместо corosync использовать keepalived и будет схема простая как карбюратор, а при выходе из backup в master пнуть старт астериск чтобы произвести актуальную генерацию конфигов
Везде в доках про НА написано corosync + drbd но на мой взгляд это бд вынести на отдельный хост и вместо corosync использовать keepalived и будет схема простая как карбюратор, а при выходе из backup в master пнуть старт астериск чтобы произвести актуальную генерацию конфигов
надо понять что делать кластер который может перебросить вызов на запасную ноду или же warm spare или же что то промежуточное ( a la VRRP ) лучшие решения с камой фронтэндом, сохранением RTP довольно сложные да и не всем нужны
Товарищи, подскажите пожалуйста, почему функция CONFBRIDGE, record_command может исполняться некорректно? В логе вижу: Executing [CONF@dynamic-conference:5] Set("SIP/1111-000065d3", "CONFBRIDGE(bridge,record_command)=/usr/bin/mv /var/spool/asterisk/monitor/tmp/2025.01.22_17-44-53-1111-conf.wav /var/spool/asterisk/monitor/2025.01.22_17-44-53-1111-conf.wav") in new stack А по завершении конференции: Executing [/usr/bin/mv /var/spool/asterisk/monitor/tmp/2025.01.22_17-44-39-1111-conf.wav /var/spool/asterisk/monitor/2025.01.22_17-44-39-1] Как будто там лимит на 128 символов.
