AMI_CLIENT_BUFFER_OVERFLOW IP-Телефония и СКУД

Asterisk: manager.c Client buffer overflow, dropping connection on AMI

Обновлено: 24.08.2026 · Официальная документация ↗

Предупреждение в логах: WARNING: manager.c: Client buffer overflow, dropping connection on AMI.
Внезапный разрыв TCP-сессии между Asterisk и CRM или интеграционным скриптом.
Потеря событий вызова (Newchannel, Hangup, Bridge) в панелях мониторинга.
Увеличение потребления оперативной памяти процессом Asterisk при пиковой нагрузке.

1. Настройка фильтрации событий (Eventfilter) в manager.conf

Не передавайте клиенту ненужные события высокой частоты (RTCP, VarSet, Newexten). Ограничьте поток в профиле пользователя /etc/asterisk/manager.conf:

[crm_integration]
secret = TopSecretKey
permit = 192.168.1.0/24
read = call,system
write = call

# Фильтрация белым списком (только необходимые регулярные выражения)
eventfilter = Event: (Newchannel|Hangup|BridgeEnter|BridgeLeave|DialBegin|DialEnd)

# Исключение мусорных событий
eventfilter = !Event: (RTCPReceived|RTCPSent|VarSet|Newexten)

2. Увеличение тайм-аутов и размеров буферов записи

В секцию [general] файла manager.conf добавьте параметры:

[general]
enabled = yes
port = 5038
bindaddr = 0.0.0.0
writetimeout = 5000
authtimeout = 30
httptimeout = 60

3. Применение настроек

asterisk -rx "manager reload"

4. Оптимизация клиентского приложения

Убедитесь, что интеграционный скрипт (Python, Node.js, PHP) читает TCP-сокет в асинхронном неблокирующем цикле (I/O event loop) и не производит синхронных блокирующих вызовов СУБД внутри обработчика сокета.

💡 Практика специалистов: Никогда не выполняйте запись в базу данных или обращение к внешним веб-сервисам в главном потоке чтения AMI сокета — используйте очереди сообщений (Redis Pub/Sub, RabbitMQ, Kafka).

Частые вопросы (FAQ)

Почему происходит переполнение буфера AMI?

Asterisk складывает сгенерированные события в локальную выходную очередь сокета. Если клиентское приложение читает данные медленнее, чем они генерируются ядром PBX, буфер переполняется, и Asterisk принудительно разрывает соединение.

Какие события генерируют наибольший объем сетевого спама в AMI?

События RTCP (RTCPReceived/RTCPSent), VarSet (изменение любых канальных переменных) и Newexten (каждый шаг выполнения диалплана).

Как полностью отключить отправку событий клиенту, если нужны только команды?

При отправке команды Login передайте заголовок Events: off или настройте в manager.conf значение read = none.

Помогает ли увеличение writetimeout решить проблему навсегда?

Увеличение writetimeout сглаживает кратковременные всплески, но фундаментально проблема решается фильтрацией событий (eventfilter) и оптимизацией производительности клиентского демона.