[странное] Звонки на внешних провайдеров через Queue

[HolyBoy]

Здравствуйте.

Имеется несколько SIP-провайдеров, через которых идут звонки во внешний мир. Существует такая особенность, что количество исходящих звонков через каждого провайдера должно быть ограничено цифрой N. Был сооружён общеизвестный костыль с использованием GROUP_COUNT: если количество созданных каналов для первого провайдера из списка превышает заданное N, то пытаемся соединиться со вторым, затем, если не удалось, то с третьим и тд. Схема страдает очевидными недостатками и выглядит некрасиво.

Появилась мысль: а что, если делать исходящий вызов через очередь? Основная проблема: невозможно передать вызываемый экстеншн к агенту, который может быть каналом Local. Никто не думал над таким решением?

[ded]

C точки зрения технологий обработки очередь - это буфер-накопитель в цепочке конвейер-с-накопителем. Когда обработка не справляется - всё копится в буфере.
ИП маршрутизаторы так и устроены, есть очередь на вход и очередь на выход.
FastEthernet0/0 is up, line protocol is up
Hardware is AmdFE, address is 0004.270c.a800 (bia 0004.270c.a800)
Internet address is 10.233.248.26/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/325472/0 (size/max/drops/flushes); Total output drops: 4238
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 103000 bits/sec, 45 packets/sec
5 minute output rate 56000 bits/sec, 40 packets/sec

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

[SVoy]

ранее уже подымался этот вопрос, но помнится все свелось обратно к перебору линий.

чем не устраивает стандартный вариант (аля freepbx) - прописали очередность транков которые используются на данном направлении, кто не поместился - продолжает работать, а не слушает сообщения: "ориентировочное время для освобождение линии ххх сек. Ваш звонок очень важен.. Спасибо, что подождали..".

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

[HolyBoy]

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

Именно так.

Если использовать GROUP_COUNT, то, один из минусов — линейное возрастание загруженности линий вверх по списку. Другой минус — увеличение времени обработки звонка, если какие-то из линий уже заняты: ведь список каждый раз пробегается от начала до конца. Я уж не говорю об эстетической стороне: код, который всё это реализует уж очень безобразный.

PS Как же плохо, что убрали команду, ограничивающую количество исходящих звонков для peer, при неограниченных входящих.

[Vlad1983]

используйте рендомный перебор совместно с GROUP_COUNT
тогда плавно будет расти по всем операторам

[HolyBoy]

Ну что же, организовать буфер исходящих звонков в виде очереди можно приблизительно так:

extensions.conf

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

[test]
exten = _1XX,1,Set(__EX=${EXTEN})
same= n,Queue(300,tT,,,60)

[queue]
exten = 201,1,Dial(SIP/201/${EX},20,Tt)

queues.conf

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

[300]
musicclass=default
strategy=rrmemory

timeout=10
retry=5
timeoutpriority=conf
weight=0
autopause=no
maxlen=0
ringinuse=no

member=Local/201@queue,,,SIP/201

Разумеется, в работу ставится побольше участников и код в [queue] правится соответственно. Такая схема работает как надо: количество входящих извне неограниченно, исходящие ограничиваются доступными транками в самой очереди, однако, существует "но"! Если вдруг количество одновременных исходящих звонков через один транк увеличится и станет бо́льшим, чем 1, то всё летит к чёрту. И это очень печально.