AMI принудительно разрывает соединение(TCP/IP Connection) при выполнении команд(Action).
К примеру у меня (* 1.6-11) гарантированный разрыв связи происходит во время выполнения команды:
Action: Command
Command: database showЭто фитча или баг?
Может быть есть какие-то настройки Asterisk которые позволяют убрать этот фитча-баг?
РЕШЕНО
Это очередной 19603 баг Asterisk.
Баг ASTERISK-19603 звучит так: Asterisk AMI truncates long responses over medium latency connections.
Решение: пересобрать Asterisk накотив патч ASTERISK-1948: [patch] Allow Manager API Command to return big amount of output data +++
PS: Честно говоря этот патч не решает проблему, а является workaround т.к. очевидно что ошибка архитектурного плана. Это ошибка синхронного блокирующего вывода нарушающая асинхронность ManagerEvent событий. Правильным решением было бы реализовать ManagerAction-Command как реализован ManagerAction-BDGet.
Задан: 2014-09-03 14:54:59 +0400
Просмотрен: 475 раз
Обновлен: Sep 04 '14
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.
ошибка архитектурного плана в разработке которая использует AMI подобным образом... как правило в грамотных решениях для обменна данными используют Restful API сервер и клиент - или, в крайнем случае - прямое соединение с базой данных через VPN... гонять кучу данных из внутренней БД Asterisk через AMI - думаю не самое лучшее решение и неудивительно что разработчики Астера такое не предусмотрели... тем более- "database show" - довольно бессмысленная команда...
octopas ( 2014-09-05 00:02:28 +0400 )редактироватьВ коем веке несколько килобайт это куча данных? Каменный век что ли? Притом что AMI может легко выплевывать десятки мегабайт эвентов под высокой нагрузкой. Да и Restful API до *11 нет, ну а c прямым доступом по VPN можно съесть большую админскую свинью и батхёрт BerkleyBD x SQLLite. В тоже время "database show" весьма осмысленно использовать, чтобы продемонстрировать данный баг, который может вылезти и в других командах только внезапно.
CallCenterCoder ( 2014-09-05 14:25:57 +0400 )редактироватьа свою реализацию Restful сервера сделать - никак? на любом выбранном языке программирования и нормальном MVC фреймворке... зачем использовать Asterisk для передачи данных? внутренняя БД Астериска - для экспериментаторов, она изначально ИМХО не предназначена чего-то серъезного... берем Postgresql, MySql и реализуем restful контроллеры... и забываем про встроенную в Астер БД, потому что ничего серъезного опять-же реализовать на ее основе не получится (ну нет Berkley DB нормальных индексов, foreign key и тп, не говорю уже о хранимых процедурах, оконных функциях и других фичах - которые неизвестно когда понадобятся - на каком этапе развития системы). если речь идет о PHP - север - ZF2+Doctrine2+ZFCUser (реализуем AbstractRestfulController), клиент - ZF2+Guzzle HTTP. почти уверен что на любых других языках программирования есть соответсвующие реализации и библиотеки...
octopas ( 2014-09-06 21:15:26 +0400 )редактироватьТеоретически можно сделать не только Restful, но и космический корабль как Энтерпрайз NX-01. Вопрос зачем?? Restfull? Обычно для задач которые решают всяческие типа CTI-API как AsteriskAMI больше не нужно чем получения состава устройств, юзеров и т.п. и манипулирование этим. Для этого AsterBD вполне самодостаточна и вполне достаточно Application_Database. Зачем городить ещё что-то?
И вообще по мне так логичнее было бы использовать стандарт OSI и ECMA типа CSTA или TSAPI, а не выдумывать велосипеды типа AMI. Как и все птичие языки диалпланов заменить на созданный международным консорциумом W3C стандарт VXML, CCXML.
А то получается что вместо использования международных стандартов каждый изобретает свой велосипед.
CallCenterCoder ( 2014-09-08 15:16:53 +0400 )редактировать