Комментарии 12
Достаточно было добавить все транки во внутреннюю БД под ключами, например Trunk/{1,2,...n} = {peer_name} и до посинения перебирать их в цикле штатными средствами.
1. А это не штатные средства?
2. И как вашим методом можно вызвать сразу рабочий транк? Без попыток вызова не рабочих?
2. И как вашим методом можно вызвать сразу рабочий транк? Без попыток вызова не рабочих?
1. Это ненужное усложнение для решения простой задачи. Представьте себя на месте человека, который пришел после вас. А теперь представьте, что он импульсивный и склонный к насилию маньяк, который знает, где вы живете и которому не очень понравилось, что ему пришлось потратить полчаса, чтобы разобраться, как PBX находит пиру и еще полчаса, чтобы отладить, почему эта конструкция разломалась.
2. При включенном qualify попытки набора мертвых пир будут сразу отбиваться, так что живой найдется быстро.
2. При включенном qualify попытки набора мертвых пир будут сразу отбиваться, так что живой найдется быстро.
1. так я за 2 запроса к интерфейсу получаю необходимые мне данные. Вы же советуете сделать n запросов в базу. Мой метод как минимум производительнее))
А по поводу того что кто то там не разберется или будет этт делать слишком долго: есть такой инструмент — документация. Очень помогает. А если и документация не поможет — то это уже вопрос компетенции. А само по себе ничего не ломается.
2. Ну как бы уже ответил по поводу производительности.
А по поводу того что кто то там не разберется или будет этт делать слишком долго: есть такой инструмент — документация. Очень помогает. А если и документация не поможет — то это уже вопрос компетенции. А само по себе ничего не ломается.
2. Ну как бы уже ответил по поводу производительности.
Никакая документация не может служить оправданием для того, чтобы делать простые вещи сложно. Особенно для склонного к насилию маньяка :)
Насчет производительности — очень спорное утверждение, внутренняя БД астериска — это крохотная беркли (или sqlite в новых версиях), ходить в которую практически бесплатно.
Городить такую штуку имеет смысл, если нужна еще какая-то сложная бизнес-логика поверх простого вызова (нетривиальная IVR, например) — тогда да, можно сесть, покурить AMI, написать хороший скрипт с обработкой ошибок, логированием и проч.
Насчет производительности — очень спорное утверждение, внутренняя БД астериска — это крохотная беркли (или sqlite в новых версиях), ходить в которую практически бесплатно.
Городить такую штуку имеет смысл, если нужна еще какая-то сложная бизнес-логика поверх простого вызова (нетривиальная IVR, например) — тогда да, можно сесть, покурить AMI, написать хороший скрипт с обработкой ошибок, логированием и проч.
По поводу маньяка оставлю без комментариев).
А по поводу производительности — как бы то бесплатно ни было — это лишние шаги в обращении данным которые сыплятся сами. Надо только слушать. Ну тут можно долго спорить. Можно РОСТО взять как нибудь и замерить скорость и нагрузку. Тогда будет понятно.
Я не говорю что ваш метод не имеет права на существование. И вполне жизнепригоден, и не лишен изящества. Моей задачей было в общем то показать как можно напрямую из диалплана работать с AMI. Не используя при этом AGI во всех его интерпритациях. С данной задачей я справился вполне.
А по поводу производительности — как бы то бесплатно ни было — это лишние шаги в обращении данным которые сыплятся сами. Надо только слушать. Ну тут можно долго спорить. Можно РОСТО взять как нибудь и замерить скорость и нагрузку. Тогда будет понятно.
Я не говорю что ваш метод не имеет права на существование. И вполне жизнепригоден, и не лишен изящества. Моей задачей было в общем то показать как можно напрямую из диалплана работать с AMI. Не используя при этом AGI во всех его интерпритациях. С данной задачей я справился вполне.
2. *
dial через макрос в цикле в диалплане
10 каналов отбивается меньше чем за секунду. Нагрузка на сервер отсутствует.
у вас быстрее произойдут проблемы с tcp:connect(«127.0.0.1», 5038) чем с самим диалпланом.
dial через макрос в цикле в диалплане
10 каналов отбивается меньше чем за секунду. Нагрузка на сервер отсутствует.
у вас быстрее произойдут проблемы с tcp:connect(«127.0.0.1», 5038) чем с самим диалпланом.
Я про диалплан в conf файлах уже давно и думать забыл. Как и о более половины встроенных конструкций типа GotoIfTime, GotoIf, realtime диалплана, а так же макросов и подобной ерунды предложенной разработчиками, ибо скорость выполнения и удобство реализации оставляют желать лучшего.
tcp:connect(«127.0.0.1», 5038) не отработает только в том случае, если только навернется вся сеть на сервере. Но тогда и актуальность данной проблемы потеряет всякий смысл.
tcp:connect(«127.0.0.1», 5038) не отработает только в том случае, если только навернется вся сеть на сервере. Но тогда и актуальность данной проблемы потеряет всякий смысл.
как показала 6ти летняя практика, рано пока отказываться от конфов
количество коннектов на 5038 может быть ограничено.
А при наличии 50-100 номеров на пне 4 (по 2-3 линии каждый) при подобных «запросах» при «заглюченном оборудовании» коннект к 5038 может быть потерян, да и не дай бог сработает защита от доса)
количество коннектов на 5038 может быть ограничено.
А при наличии 50-100 номеров на пне 4 (по 2-3 линии каждый) при подобных «запросах» при «заглюченном оборудовании» коннект к 5038 может быть потерян, да и не дай бог сработает защита от доса)
Как показала 6 летняя практика- самое время отказываться. Особенно если это высоконагруженная система. Особенно если это облачное решение. Особенно если это взаимодействие с базами данных. ДА много таких вот «Особенно» я могу перечислить, исходя из опыта.
Все остальные «может» отлично обходятся с помощью прямых рук.
Что значит «заглюченное оборудование»?
Программы не умеют не работать «по настроению». Либо где то кривые руки, либо нерабочее железо. 1 исправляется поднятием компетенции любым путем, второе — заменой.
Все остальные «может» отлично обходятся с помощью прямых рук.
Что значит «заглюченное оборудование»?
Программы не умеют не работать «по настроению». Либо где то кривые руки, либо нерабочее железо. 1 исправляется поднятием компетенции любым путем, второе — заменой.
Какой нибудь pap2t может убить астериск
Глючит оборудованме, а не ПО. Атака внутри сети пользователя может откликнуться и на телефонии
С 1 и 2 согласен когда админ один, а когда их по одному на каждый номер + у сервера телефонии нет админа)
Я просто поделился опытом, за 6 лет вмешивались в работу сервера не больше 20ти раз.
Вы можете делать по своему.
Глючит оборудованме, а не ПО. Атака внутри сети пользователя может откликнуться и на телефонии
С 1 и 2 согласен когда админ один, а когда их по одному на каждый номер + у сервера телефонии нет админа)
Я просто поделился опытом, за 6 лет вмешивались в работу сервера не больше 20ти раз.
Вы можете делать по своему.
Я с вами соглашусь в том что идеальные условия не всегда присутсnвуют и что компроментирование сети вполне может быть. Но как правило когда «у сервера телефонии нет админа», то решения предложенные мною, как правило выше компетенции персонала компании.
А по поводу «железо глючит» — если что-то работает не так как должно работать и это в продакшне, Будь то ПО или железо.В таких ситуациях нужно задумываться о замене или об устранении причин неработоспособности. Сливать на «глючит» — не решение.
Моя статья все же больше касается именно разработчиков сервисов телефонии, нежели админов средней руки, или непрофилирующих в VoIP. В конце концов методы взаимодейсвия с интерфейсами сервера- это больше уже стезя программистов нежели админов.
Я повторюсь: смысл написания моей статьи все же сводится не к тому как проверять транки (это не более чем пример), а к раскрытию возможностей взаимодействия с интерфейсами астериска не из внешних приложений, а из самого диалплана.
А по поводу «железо глючит» — если что-то работает не так как должно работать и это в продакшне, Будь то ПО или железо.В таких ситуациях нужно задумываться о замене или об устранении причин неработоспособности. Сливать на «глючит» — не решение.
Моя статья все же больше касается именно разработчиков сервисов телефонии, нежели админов средней руки, или непрофилирующих в VoIP. В конце концов методы взаимодейсвия с интерфейсами сервера- это больше уже стезя программистов нежели админов.
Я повторюсь: смысл написания моей статьи все же сводится не к тому как проверять транки (это не более чем пример), а к раскрытию возможностей взаимодействия с интерфейсами астериска не из внешних приложений, а из самого диалплана.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Asterisk Manager Interface в диалплане