asterisk.ru

Ситуация:
Если очередь. Queue. В ней 3 оператора. Для этой queue задан h extension (т. е. что-то сделать когда кто-то из абонентов этой очереди положит трубку). Обнаружил, что этот самый h extension
отрабатывает только для последнего dst канала:
Первоначальный А канал, к примеру: С5350-00000001
B каналы операторов: SIP/109-00000005, SIP/115-00000006, SIP/202-00000007
По факту устанавливается соединение с каналом 202(С5350-00000001 -- SIP/202-00000007) . Но по окончании разговора h extension (где я ворочаю perl скрипт для корректировки параметров CDR)
отрабатывает для того канала, на котором трубка снята не была! (С5350-00000001 -- SIP/115-00000006), причем, эта запись всегда отображается последней (id) Сие Баг? Как побороть особенность такой реализации? Для команды Dial проблема решилась включенеим опции e но для queue такой опции нет. Версия asterisk - 13.17.0.
На крайняк думаю использовать предвоканал local , но может есть другое решение?

А в каком случае срабатывает h для queue?
А какой канал приехал в queue?
А какие каналы сбриджевались?
А какой канал вернул hangup?

1. h для queue срабатывает всегда.
2. Приехал c5350-00000001
3. Сбриджевались c5350-00000001 и SIP/202-00000007
4. Hangup вернул канал c5350-00000001 и dstchannel SIP/115-00000006
А должен был быть в dstchannel SIP/202-00000007

Поставьте для отладки шаг DumpChan() и увидите в переменных не только SIP/115 но и SIP/202

А для каких каналов сработает h если инициатором был канал c5350-00000001 ?
для канала
<c5350-00000001> < SIP/202-00000007>
<SIP/115-00000006> <Мосводоканал>
??? ))))

для канала c5350-00000001 dstchannel SIP/115-00000006 - true, так же как и
dstchannel SIP/202-00000007 - true, потому что это очередь и вызов идет на все каналы очереди.
c5350-00000001 вернет бридж и статус завершения с SIP/202-00000007.
Неправильно сортируете. Ловите bridge, а не dstchannel.

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

[[0mExecuting [101@ro:11] ^[[1;36mQueue^[[0m("^[[1;35mSIP/sip.ru-001a7f57^[[0m", "^[[1;35in,t^[[0m") in new stack
[[0mStarted music on hold, class 'default', on channel 'SIP/sip.ru-001a7f57'

[0mSIP/117-001a7f5b connected line has changed. Saving it until answer for SIP/sip.ru-001a7f57
[0mSIP/509-001a7f5a connected line has changed. Saving it until answer for SIP/sip.ru-001a7f57
[0mSIP/109-001a7f59 connected line has changed. Saving it until answer for SIP/sip.ru-001a7f57
[0mSIP/521-001a7f58 connected line has changed. Saving it until answer for SIP/sip.ru-001a7f57
[[0K^[[1;30m -- ^[[0mGot SIP response 486 "Busy Here" back from :5060
[[0K^[[1;30m -- ^[[0mSIP/117-001a7f5b is busy
[[0K^[[1;30m -- ^[[0mGot SIP response 486 "Busy Here" back from :8080
[[0K^[[1;30m -- ^[[0mSIP/521-001a7f58 is busy
[[0K^[[1;30m -- ^[[0mNobody picked up in 0 ms
[[0K^[[1;30m -- ^[[0mSIP/109-001a7f59 is ringing
[[0K^[[1;30m -- ^[[0mSIP/509-001a7f5a is ringing

[[0K^[[1;30m -- ^[[0mSIP/109-001a7f59 connected line has changed. Saving it until answer for SIP/sip.ru-001a7f57
[[0K^[[1;30m -- ^[[0mSIP/109-001a7f59 answered SIP/sip.ru-001a7f57
[[0K^[[1;30m -- ^[[0mStopped music on hold on SIP/sip.ru-001a7f57
[[0K^[[1;30m -- ^[[0mChannel SIP/109-001a7f59 joined 'simple_bridge' basic-bridge <4dc4130b-7451-4111-a428-b63141604fd7>
[[0K^[[1;30m -- ^[[0mChannel SIP/sip.ru-001a7f57 joined 'simple_bridge' basic-bridge <4dc4130b-7451-4111-a428-b63141604fd7>

[[0K^[[1;30m == ^[[0mSpawn extension (ro, 101, 11) exited non-zero on 'SIP/sip.ru-001a7f57'
[[0mExecuting [h@ro:1] ^[[1;36mNoOp^[[0m("^[[1;35mSIP/sip.ru-001a7f57^[[0m", "^[[1;35mHANGUPCAUSE is 16^[[0m") in new stack
[[0K^[[1;30m -- ^[[0mExecuting [h@ro:2] ^[[1;36mNoOp^[[0m("^[[1;35mSIP/sip.ru-001a7f57^[[0m", "^[[1;35morderId ^[[0m") in new stack
[[0mExecuting [h@ro:3] ^[[1;36mNoOp^[[0m("^[[1;35mSIP/sip.ru-001a7f57^[[0m", "^[[1;35mUNIQUEID : 1503999551.3036377^[[0m") in new stack
[[0K^[[1;30m -- ^[[0mExecuting [h@ro:4] ^[[1;36mNoOp^[[0m("^[[1;35mSIP/sip.ru-001a7f57^[[0m", "^[[1;35mUSER CALLL END!!!!!!!!!!!!!!!!!!!!!!!!!
[[0K^[[1;30m -- ^[[0mExecuting [h@ro:10] ^[[1;36mHangup^[[0m("^[[1;35mSIP/sip.ru-001a7f57^[[0m", "^[[1;35m^[[0m") in new stack
[[0K^[[1;30m == ^[[0mSpawn extension (ro, h, 10) exited non-zero on 'SIP/sip.ru-001a7f57'
[[0K^[[1;30m == ^[[0mMixMonitor close filestream (mixed)
[[0K^[[1;30m == ^[[0mEnd MixMonitor Recording SIP/sip.ru-001a7f57

channel | dstchannel | disposition | linkedid
--------------------------+------------------+-------------+--------------------
SIP/sip.ru-001a7f57 | SIP/117-001a7f5b | BUSY | 1503999551.3036377
SIP/sip.ru-001a7f57 | SIP/509-001a7f5a | NO ANSWER | 1503999551.3036377
SIP/sip.ru-001a7f57 | SIP/109-001a7f59 | ANSWERED | 1503999551.3036377
SIP/sip.ru-001a7f57 | SIP/521-001a7f58 | BUSY | 1503999551.3036377
(4 rows)

DumpChan() показывает все нормально:
Name= SIP/c5350a-000000ea
...
ConnectedLineIDNum= 202
...
Всё классно.....Но! При этом я не вижу status ANSWERED.
Но если я в этом месте диалплана(h exten) делаю вот так (Я использую CDR adaptive module):
...
same => n,Set(CDR(into)=test)
...
То в БД я вижу, что "test" появляется не в ожидаемой записи CDR,соответсвующей каналу SIP/202-000000ec со статусом ANSWERED
а в CDR записи, соответствующей каналу 115-000000ef , хотя этот канал не был отвечен.

Repz, идею про bridge - не понял.

Upd:
при включённом cdr debug:

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

    -- Channel SIP/202-000000f4 left 'simple_bridge' basic-bridge <2300cf5b-f578-4986-9819-3b48bc5c3998>
[Aug 29 14:45:33] Bridge Leave message for SIP/202-000000f4: 1504007133.00587792
[Aug 29 14:45:33] 0x7f34b4005300 - Processing Bridge Leave for SIP/202-000000f4
[Aug 29 14:45:33] 0x7f34b4005300 - Transitioning CDR for SIP/202-000000f4 from state Bridged to Finalized
[Aug 29 14:45:33]     -- Channel SIP/c5350a-000000f2 left 'simple_bridge' basic-bridge <2300cf5b-f578-4986-9819-3b48bc5c3998>
[Aug 29 14:45:33] Bridge Leave message for SIP/c5350a-000000f2: 1504007133.00587872
[Aug 29 14:45:33] 0x7f34b4000cc0 - Processing Bridge Leave for SIP/c5350a-000000f2
[Aug 29 14:45:33] 0x7f34b4000cc0 - Transitioning CDR for SIP/c5350a-000000f2 from state Bridged to Finalized
[Aug 29 14:45:33] 0x7f34b4005300 - Beginning finalize/dispatch for SIP/202-000000f4
[Aug 29 14:45:33] 0x7f34b4005300 - Dispatching CDR for Party A SIP/202-000000f4, Party B <none>
[Aug 29 14:45:33]   == Spawn extension (megalink-call-center-on, call-center, 5) exited non-zero on 'SIP/c5350a-000000f2'
[Aug 29 14:45:33]     -- Executing [h@megalink-call-center-on:1] Gosub("SIP/c5350a-000000f2", "queue-after-hangup,s,1") in new stack
[Aug 29 14:45:33]     -- Executing [s@queue-after-hangup:1] NoOp("SIP/c5350a-000000f2", "queue after hangup") in new stack
[Aug 29 14:45:33]     -- Executing [s@queue-after-hangup:2] Set("SIP/c5350a-000000f2", "CDR(info)=test") in new stack
.....
[Aug 29 14:45:33]     -- Executing [h@megalink-call-center-on:2] Hangup("SIP/c5350a-000000f2", "") in new stack
[Aug 29 14:45:33]   == Spawn extension (megalink-call-center-on, h, 2) exited non-zero on 'SIP/c5350a-000000f2'
[Aug 29 14:45:33] 0x7f34b4002450 - Beginning finalize/dispatch for SIP/c5350a-000000f2
[Aug 29 14:45:33] 0x7f34b4002450 - Dispatching CDR for Party A SIP/c5350a-000000f2, Party B <none>

Получается, исходя их этого лога, СНАЧАЛА формируется CDR запись о разговоре, а потом запускается h extension,в котором я могу влиять
уже на другую CDR запись, что по факту и имею.
Вот если кто подскажет, в каком месте диалплана можно словить этот состояние :

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

Transitioning CDR for SIP/202-000000f4 from state Bridged to Finalized

и повлиять на вид CDR, буду безмерно благодарен.
Пока знаю, что менять параметры CDR можно:
1. перед попаданием в bridge для А канала: всё, что перед командой DIAL (QUEUE)
2. перед попаданием в bridge для Б канала: в опции U команды dial
3. Сразу после выхода из bridge - ????
4. Hangup - Возможно, это и есть п3, но вот работает с глюками и не для всех каналов, покидающих bridge (в случае queue, для команды Dial это "лечится" включение опции 'e')

CDR формируется с момента создания канала, посмотрите cdr where channel ='SIP/c5350a-000000f2' возможно там есть все что нужно.
что пытаетесь в CDR записать/изменить?
CDR штука самодостаточная.....
как сделать из диалплана не подскажу, я использую AMI, там есть куча замечательных Events:
Event: BridgeEnter
Event:QueueCallerJoin
Event:QueueCallerLeave
Event:QueueCallerAbandon
Event: Hangup
События на любой вкус и цвет))

ТС, поясню: CDR придуман в основном для отчётов по работе в обычном режиме АТС. Как только заводим надстройки для Call center - наш CDR перестаёт удовлетворять.
Смотрите CEL, там всё придумано именно по Events.

Repz, Я в CDR пишу всякие интересные вещи: имя пира, номер, account code, городской номер, ip адрес пира, выбранный динамически провайдер, направление вызова и др. поля, которые я придумал самостоятельно и которые за меня asterisk сам не заполнит.
В сторону CEL я смотрел - ужоснах

Один простой звонок генерит больше десятка записей. Оно мне так всю БД заспамит, а потом сие еще как-то парсить надо.
Ну а в целом-то cdr_adaptive меня полностью устраивает.
Не разобрался только с одним:
формирование понятных CDR записей только для attended transfer и только для приложения Queue.
PS Для работы самого колл-центра есть таблица queue_log, куда пишутся все события именно приложения queue, которная парсится перлоскриптом и который формирует html с графиками и рюшками и посылает отчёты по работе коллцентра руководителям. А в CDR хочется писать лишь те вызовы, которые биллинговать надо.

asterisk.ru

queue after hangup - странность

queue after hangup - странность

Re: queue after hangup - странность

Re: queue after hangup - странность

Re: queue after hangup - странность

Re: queue after hangup - странность

Re: queue after hangup - странность

Re: queue after hangup - странность

Re: queue after hangup - странность

Re: queue after hangup - странность