Пишу демон для мониторинга очередей на нескольких asterisk серверах. Есть очень много мелочей которые мне нужно реализовать, поэтому готовые решения использовать не получается.
Проблема в следующем: Имеется 2 подсети. Например 172.1.0.0/24 (N1) и 172.1.1.0/24 (N2). В N1 находится Asterisk, а в N2 находится сервер, на котором крутится демон. Демон устанавливает AMI соединение к астериску. Так вот это соединение очень быстро убивается по инициативе астериска.
Если же располагать сервер мониторинга в той же подсети, что и сам астериск, то соединение живет вечно. (По крайней мере у меня оно не падало. Тестировал 26 часов. Закрыл сам, из-за того что надоело ждать когда оно упадет :)) Если же в разных сетях то после первого же вывода: "Connection closed by remote host"
Пробовал снифать трафик и выяснилось, что TCP сессию рвет именно АТС. В последнем пакете с данными (Ответ на команду "Action: QueueStatus") АТС ставит флаг FIN, чем и инициирует завершение TCP сессии. В случае расположения серверов в одной подсети этот флаг не ставится и поэтому сессиия не рвется...
Уже думал грешить на Cisco роутер, который стоит между этими подсетями, но сняв трафик на обоих концах, окончательно убедился, что первый пакет с FIN флагом шлет именно АТС.
Еще есть вариант что соединение рвет не сам астериск а операционная система. Но интересно то, что рвется сессиия не по истечении какого-то определенного времени, а четко в последнем пакете с данными. Т.е. если подключиться по AMI и сразу отправить команду, например "Action: QueueStatus", то в последнем пакете тут же возникнет флаг FIN. Вывод в ответ на команду идет довольно большой. Может кто-то сталкивался с данной проблемой? Принимаются любые мысли к размышлению.
Вобщем, предоставлю любую интересующую информацию. Проблему надо как то побороть, а я уперся. Нужна помощь! :)
UPDATED. Проверял все телнетом на порт Asterisk Manager Interface (5038). История аналогичная. Соединение рвется сразу после вывода первой команды. Дело не в модуле питона, и не в моих кодах. Проблема на стороне сервера. Либо Asterisk, либо Linux. Вопрос в том что именно и как это пофиксить.
Asterisk AMI truncates long responses over medium latency connections https://issues.asterisk.org/jira/browse/ASTERISK-19603 Вот и ответ.
Задан: 2012-10-18 18:50:57 +0400
Просмотрен: 748 раз
Обновлен: Oct 19 '12
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.
А не может быть дело во фреймворке? Я правильно понимаю, что все через py-asterisk делается? Может что-то с буферами? Попробуйте простое соединение на 5038 порт телнетом и вывести эту команду.
zzuz ( 2012-10-18 19:24:08 +0400 )редактироватьИспользуется pyst (py-asterisk мне не очень приглянулся). Я забыл написать. Все проверено обычным телнетом на порт 5038. Устанавливаю соединение, Сначала Action: Login, потом Action: QueueStatus. В консоль выводится вся нужная мне инфа описывающая состояние очередей. Последняя строка Event: QueueStatusComplete. И после этого соединение рвется. Т.е. дело тут точно не в python'е
ramzed ( 2012-10-18 21:21:14 +0400 )редактироватьНу да , я тоже проблем не наблюдал с подключениями по pyast. Думаю дело в сети попробуйте для эксперемента пусть трафик через другой свитч , отличные от циски, чтобы исключить проблему на самой циске.
zzuz ( 2012-10-18 22:44:24 +0400 )редактироватьЗавтра попробую. Дело осложняется тем, что это все очень далеко находится физически. Одна подсеть тут в России, другая в США. Все это дело соединено VPN'ом. Тут очень много разных причин может быть... Может задержка кому то не нравится (Asterisk, Linux, Cisco).
ramzed ( 2012-10-18 23:20:59 +0400 )редактировать