Как реализовать исходящие звонки с перебором линий?

[hёdgehog]

И снова здравствуйте.
Возникла необходимость реализовать с помощью FreePBX следующую логику:
1. Поступает звонок, который должен уйти на мобильный;
2. FreePBX смотрит, какая линия использовалась в последний раз, и прибавляет к номеру 1, а если номер вышел за пределы возможных, то сбрасывает его в единицу.
3. FreePBX набирает в транк номер вида 0L, где 0 - признак звонка через GSM, L=номер линии. Далее посылает набранный номер;
4. Если произошёл отказ линии, то FreePBX переходит к пункту 2.
Дополнительные заморочки:
1. Шлюз не один. Нумерация линий у всех шлюзов сквозная;
2. Звонок приходит из исходящего маршрута
Эта логика была реализована в чистом астере, и для меня не было бы сложностью перенести её в другую установку. Проблема именно в том, как реализовать всё вышеописанное посредством GUI. На данный момент всё сделано через приоритеты Custom Contexts, кучку маршрутов с именами типа "FromSamsungToMobileOverGSM0-1" и шаблонами номеров в каждом вида "0L" (приставка)+"89XXXXXXXXX". Главная гадость в этом решении = что набор всегда начинается с одной и той же линии, независимо от истории. И если для звонков в FXO это некритично (какая разница, через какую линию звонить, они всё равно не определяются - занимается первая свободная линия), то для звонков на мобильные распределение играет роль, поскольку затраты должны выравниваться по всем SIM-картам (хотя бы приблизительно).
Можно ли реализовать подобную логику, не слишком правя диалплан ручками? Что можно для этого использовать?

[ded]

Это точно не в разделе Вопросы новичков, в таком виде имеет три выхода:
1) реализовать подобную логику не слишком правя диалплан руками можно. Что можно для этого использовать? - вэб интерфейс FreePBX, по определению.
2) самостоятельно и кропотливо
3) всё это опубликовть в разделе Бизнес, обозначить бюджет.

[april22]

а если использовать модуль TrunkBalansing !?
там правда иная логика , но может и Вам подойдет .

[murr]

И снова здравствуйте.
И если для звонков в FXO это некритично (какая разница, через какую линию звонить, они всё равно не определяются - занимается первая свободная линия), то для звонков на мобильные распределение играет роль, поскольку затраты должны выравниваться по всем SIM-картам (хотя бы приблизительно).

Звонки будут разной продолжительности, количество звонков единовременно будет колебаться, с каких-то симок будут отправляться СМС, по каким-то будут проходить входящие. Мне кажется существующий рандом занятия линий на исходящих техническими средствами корректировать проблематично и не имеет особого смысла.

Мы привязали большую часть симок на единый корпоративный (хоть и на физ. лицо) договор и они все привязаны к единому денежному счету. Рекомендую.

[hёdgehog]

Звонки будут разной продолжительности, количество звонков единовременно будет колебаться, с каких-то симок будут отправляться СМС, по каким-то будут проходить входящие. Мне кажется существующий рандом занятия линий на исходящих техническими средствами корректировать проблематично и не имеет особого смысла.

Мы привязали большую часть симок на единый корпоративный (хоть и на физ. лицо) договор и они все привязаны к единому денежному счету. Рекомендую.

Думали об этом. У Билайна нет (насколько я знаю) возможности выделить группу номеров в договоре для объединения счетов. Если сменим оператора, тогда, возможно, такое получится, но пока нас устраивает цена и качество Вымпелкома.
SMS мы со шлюзов не отправляем, для этого есть интернет-шлюзы с приличными ценами (типа smsc.ru). Входящие ходят, да. Но там некритичные объёмы.
И да, в нашей бизнес-логике эта схема уже работает, и разброс по каналам колеблется до 100 минут в месяц, но при этом трафик на канал входит в оплаченные 1500 минут с посекундной тарификацией с запасом. А вот если всегда перебор будет начинаться с первого канала, то на нём повиснет большая часть трафика, что не есть хорошо.
А вообще - задача, насколько я понимаю, тривиальная. Но самое простое решение - поправить диалплан ручками через extensions_override_freepbx.conf. Но решение это неочевидно, поскольку кастомный контекст не будет виден из GUI, чего как раз я хотел избежать.
April22, я покопаюсь в предложенном решении, но, подозреваю, оно будет работать, только если описать каждую линию как транк по отдельности.
Ded, я глубоко уважаю вас, как специалиста (хоть и авансом, потому что постов, кроме вариаций на несколько сентенций из серии "кури маны", "плати деньги", "нах.. полез, если не знаешь?" и т.п. я ни в одном форуме, где вы отметились, не обнаружил. Возможно, плохо искал, поскольку для вас проблемы, решаемые мной - давно пройденный этап, неинтересный для обсуждения). И тем не менее - если вы не испытываете желания сменить ник на К.О., то воздержитесь от ответов такого рода в моих постах, хорошо? Я уверен, что для вас решение очевидно, и вы мне его не скажете (либо скажете, и даже поможете удалённо - за отдельную плату), но для меня это означает, что ваши посты - флуд, ибо количество полезной информации в них неограниченно мало отлично от нуля.

[ded]

Уважаемый hёdgehog! Как можно ещё по Вашему ответить на Ваш вопрос -

Можно ли реализовать подобную логику, не слишком правя диалплан ручками?

? К.О. говорит, что только два варианта: 1) Можно и 2) Нельзя.
Я тоже оцениваю полезность Ваших вопросов (как Вы моих ответов), она тоже недалеко от нуля
Если я объяснил Вам вот тут http://forum.asterisk.ru/viewtopic.php? ... 896#p47896 и Вы ответили - Понятно, спасибо! то как это согласуется с Вашим Высказыванием о том, что ничего кроме флуда от меня не обнаружили? Предлагаю Вам забрать своё замечание, ОК?

Если можно - не надо выказывать никакого уважения в мою сторону. Это должно Вас как-то, возможно, успокоить.
Ну, и буду работать над собой!

[SolarW]

а если использовать модуль TrunkBalansing !?
там правда иная логика , но может и Вам подойдет .

Присоединяюсь к пожеланию.
Возможность разбрасывать исходящие по разным каналам и ограничивать количество минут в месяц по каждому каналу там есть.

[murr]

А вообще - задача, насколько я понимаю, тривиальная. Но самое простое решение - поправить диалплан ручками через extensions_override_freepbx.conf. Но решение это неочевидно, поскольку кастомный контекст не будет виден из GUI, чего как раз я хотел избежать.

Тривиальная для чистого астера. Для FreePBX - только через override.
Раз разрабы не предусмотрели такую логику (даже правильнее сказать - заложили свою) - придется ваять руками. Куда же деться.

И да - через Гуй оно рулиться естественно не будет. Это не баг - это фича.

А это решение https://github.com/POSSA/freepbx-trunk- ... the-Module может даже кстати и взлетит.

Load ratio (LR): If the LR is defined with an integer > 1, the module will randomly allow or deny the outbound call based only on the load ratio. There is no determination of previous trunk usage and it does not attempt to balance minutes or number of calls. If you want to randomly balance outbound calls equally over three (n) trunks, you must create 2 (n-1) balanced trunks, one with a load ratio of 3 (n) and one with a load ratio of 2 (n-1). When you define the outbound route, you will order trunks such that the balanced trunk with LR=3 is first, LR=2 is the second and an unbalanced, unrestricted trunk will be the third. The odds of the call being handled by the first trunk is 1/3, the odds of the second call is 1/3 (more precisely, half of the remaining 2/3) and the third trunk will receive 1/3 (or all of the remaining). To disable this rule enter 1.

[zzz777z]

поскольку кастомный контекст не будет виден из GUI, чего как раз я хотел избежать.

А зачем Вам, собственно, смотреть на GUI?

Может такой контекст подойдет?

Код: Выделить всё

exten => _09XXXXXXXX,1,NoOp()
  same => 2,Goto(${RAND(3,7)})
  ;рандомно выберет приоритет с 3 до 7 
  same=> 3,Dial(SIP/${EXTEN}@gateway0)
  same=> 4,Dial(SIP/${EXTEN}@gateway1)
  same=> 5,Dial(SIP/${EXTEN}@gateway2)
  same=> 6,Dial(SIP/${EXTEN}@gateway3)
  same=> 7,Dial(SIP/${EXTEN}@gateway4)

[hёdgehog]

zzz777z, GUI нужен не мне, он нужен тем, кто будет обслуживать систему после меня или в моё отсутствие. Мой теперешний сотрудник не обладает необходимой квалификацией.
April22, murr, SolarW - спасибо за подсказку, хотя я и не понял пока, можно ли реализовать требуемое, если каждый шлюз=транк, а в каждом транке несколько каналов, но я попозже разберусь. Если это невозможно - переделаю конфигурацию, чтобы каждый канал регился отдельным транком. В любом случае, сейчас на это совершенно нет времени.
ded, признаю свою неправоту, и приношу извинения. В любом случае, подобные инсинуации были бы более уместны в личке, а форум не предназначен для фаллометрии. Посему ещё раз приношу свои извинения.

Временно решил проблему затычкой - перенёс логику из asterisk в extensions_override_freepbx.conf. Когда дойдут руки, и разгребу основные задачи по переходу на новое ПО, сяду разбираться с Trunk Balance. Спасибо всем.