Pull to refresh

Comments 12

Каким образом через originate мониторится статус соединения с агентом?

У originate два плеча — channel и context/extension (или альтернатива app/params)
В режиме async статус соединения по channel сообщается в originateresponse (success=answer).
Вы чтоли именно его используете для соединения с оператором, а второе плечо — для вызова внешнего номера?
(агентом я тут обозвал оператора колцентра)
Я понял).

Есть отдельный инструмент который отлавливает все 'event'ы. При формировании originate — мы пишем в локальные переменные тип звонка и кто его обслуживает, поэтому нет необходимости запоминать соответствие конкретного агента какому то каналу.

Всёравно не совсем понял.
Чтоли хитрый AGI в диалплане, который вызывает оператора, и который указан в originate-channel?
А в originate-context таки диалплан вызова внешнего абонента?
Вызов оператора через originate, где channel это номер оператора — а в контексте уже выход на dialplan, где будет вызываться клиент. Agi в схеме нет. Оператор принял вызов и ушёл в обычный dialplan, как бы сам звонить клиенту, средствами dial'a. Сам originate происходит через ami запрос скриптом, который просто знает через какого оператора кому позвонить. Если изобразить кодом:

$response = aster01->{ASTMAN_CONNECT}->action
        ({
            Action      => 'Originate',
            Channel     => '007@aster01',
	    Context 	=> 'default',
            Exten       => 'callback',
            Priority    => 1,
        })


То есть в данном случае будет вызов агента 007 который уйдёт звонить через экстен «callback». В этом экстеншене уже вызов клиента.
Вот не совсем понятна такая логика.
Астериск же сам вполне способен определить свободных агентов, и разрулить приоритеты, и написать всё подробно в queuelog, и оповестить всех евентами.
Всё дело в том, что ещё до меня были написаны свои механизмы обслуживания очередей и сбора статистики. Поэтому видимо это и ввело вас в заблуждение :).
Я сейчас сооружаю похожую систему и тоже через ami originate.

В originate-channel: диалплан, который маршрутизирует звонок, выбирает транк, и заканчивается примерно Dial(SIP/${TRUNK}/${DIALNUMBER})

В originate-context: предполагается диалплан, передающий звонок оператору, и полагаю, что встроенного механизма очередей для этого достаточно, тоесть этот диалплан упрётся в Queue(${QUEUEID}) и астериск сам разрулит кому из операторов передать звонок.
А статистику и аналитику можно собрать через QueueLog.

Следить за состоянием абонентов предполагается через евенты OriginateResponse/Hangup
Следить за состоянием агентов и очереди предполагается через евенты типа AgentConnect, QueueMemberdded, итп.

Что тут не так и какие грабли вылезут?
Выглядит всё красиво, но на то они и грабли, чтобы неизвестно когда и где вылазить).
Можно городить грабли, а можно воспользоваться железобетонными вызовами диалплана…

Например, звонить не на '007@aster01', а на Local экстеншн, а внутри даплана вызывать Dial, при этом, если звонок упадет в экстеншн 'h' — событие Hangup, если в экстеншн Callback — событие Answer.
Если Вам нужно обзвонить клиентов и соединить их с оператором, как решаете проблему, если у клиента стоит IVR или какая-то говорилка? Есть ли у вас механизм распознавания, что трубку на той стороне подняла станция или живой человек?
Мы считаем звонок отвеченным, только если случился answer, бывают накладки вроде IVR или голосовой почты, но их очень мало.
Sign up to leave a comment.

Articles