Understanding full log


(Brandon Brown) #1

We are writing a parser for the ‘full’ log inside of the asterisk directory. So far it is going pretty well but we hit a snag when a caller goes into a queue and an agent answers the call, then transfers them to another agent’s direct extension. The problem is that the channel name remains the same when the MoH is playing or the other agent transfers the call.

If you look at the log snippets below it appears that extension 320 is actually placing them on hold after extension 366 answers the phone call. The channel stays the same Local/320@from-queue-00261a79. Is there a way to determine who is actually placing the caller on hold? Is is also the same problem for when extension 366 transfers back to 320.

We can determine who put the caller on hold when the caller is in a queue and an agent answers then transfers into another queue, because the channel name is different. However it doesn’t appear to change when it is an agent to agent transfer.

## Extension 320 answers the phone call from the queue
[2020-11-13 14:07:38] VERBOSE[28280][C-0001c335] app_queue.c: Local/320@from-queue-00261a79;1 answered SIP/voipinnovations-inbound1-0003b96b
[2020-11-13 14:07:38] NOTICE[28280][C-0001c335] app_queue.c: Delaying member connect for 1 seconds
[2020-11-13 14:07:38] VERBOSE[28375][C-0001c335] bridge_channel.c: Channel SIP/320-0003b96e joined 'simple_bridge' basic-bridge <f840a82c-94b2-422e-a265-04c21969cbc4>
[2020-11-13 14:07:38] VERBOSE[28369][C-0001c335] bridge_channel.c: Channel Local/320@from-queue-00261a79;2 joined 'simple_bridge' basic-bridge <f840a82c-94b2-422e-a265-04c21969cbc4>
[2020-11-13 14:07:39] VERBOSE[28280][C-0001c335] file.c: <Local/320@from-queue-00261a79;1> Playing 'custom/Qualified_Sales_Lead.slin' (language 'en')
[2020-11-13 14:07:42] VERBOSE[28280][C-0001c335] res_musiconhold.c: Stopped music on hold on SIP/voipinnovations-inbound1-0003b96b
[2020-11-13 14:07:42] VERBOSE[28386][C-0001c335] bridge_channel.c: Channel Local/320@from-queue-00261a79;1 joined 'simple_bridge' basic-bridge <214de424-47e0-41fa-8c3a-17f65ad09b16>
[2020-11-13 14:07:42] VERBOSE[28280][C-0001c335] bridge_channel.c: Channel SIP/voipinnovations-inbound1-0003b96b joined 'simple_bridge' basic-bridge <214de424-47e0-41fa-8c3a-17f65ad09b16>

## Put caller on hold and transfer to 366
[2020-11-13 14:07:46] VERBOSE[28369][C-0001c335] res_musiconhold.c: Started music on hold, class 'HoldMusic', on channel 'Local/320@from-queue-00261a79;2'
[2020-11-13 14:07:48] VERBOSE[28369][C-0001c335] res_musiconhold.c: Stopped music on hold on Local/320@from-queue-00261a79;2
[2020-11-13 14:07:48] VERBOSE[28375][C-0001c335] bridge_channel.c: Channel SIP/320-0003b96e left 'simple_bridge' basic-bridge <f840a82c-94b2-422e-a265-04c21969cbc4>
[2020-11-13 14:07:48] VERBOSE[28375][C-0001c335] app_stack.c: SIP/320-0003b96e Internal Gosub(crm-hangup,s,1) start
[2020-11-13 14:07:48] VERBOSE[28369][C-0001c335] pbx.c: Executing [366@from-internal-xfer:1] GotoIf("Local/320@from-queue-00261a79;2", "1?ext-local,366,1:followme-check,366,1") in new stack

## Extension 366 answers and puts the caller on hold right away
[2020-11-13 14:07:59] VERBOSE[28369][C-0001c335] app_dial.c: SIP/366-0003b971 answered Local/320@from-queue-00261a79;2
[2020-11-13 14:07:59] VERBOSE[28486][C-0001c335] bridge_channel.c: Channel SIP/366-0003b971 joined 'simple_bridge' basic-bridge <7642f90e-8399-4db0-9f3a-406b404b7f8b>
[2020-11-13 14:07:59] VERBOSE[28369][C-0001c335] bridge_channel.c: Channel Local/320@from-queue-00261a79;2 joined 'simple_bridge' basic-bridge <7642f90e-8399-4db0-9f3a-406b404b7f8b>
[2020-11-13 14:07:59] VERBOSE[28369][C-0001c335] res_musiconhold.c: Started music on hold, class 'HoldMusic', on channel 'Local/320@from-queue-00261a79;2'
[2020-11-13 14:08:12] VERBOSE[28369][C-0001c335] res_musiconhold.c: Stopped music on hold on Local/320@from-queue-00261a79;2

## Extension 366 takes caller off hold and initiates a transfer back to extension 320
[2020-11-13 14:08:13] VERBOSE[28369][C-0001c335] res_musiconhold.c: Started music on hold, class 'HoldMusic', on channel 'Local/320@from-queue-00261a79;2'
[2020-11-13 14:08:24] VERBOSE[28369][C-0001c335] res_musiconhold.c: Stopped music on hold on Local/320@from-queue-00261a79;2
[2020-11-13 14:08:24] VERBOSE[28486][C-0001c335] bridge_channel.c: Channel SIP/366-0003b971 left 'simple_bridge' basic-bridge <7642f90e-8399-4db0-9f3a-406b404b7f8b>
[2020-11-13 14:08:24] VERBOSE[28486][C-0001c335] app_stack.c: SIP/366-0003b971 Internal Gosub(crm-hangup,s,1) start
[2020-11-13 14:08:24] VERBOSE[28369][C-0001c335] pbx.c: Executing [320@from-internal-xfer:1] GotoIf("Local/320@from-queue-00261a79;2", "1?ext-local,320,1:followme-check,320,1") in new stack

#2

Look into using mysql asteriskcdr queries after reading up on how various fields in the tables cdr and cel are related.


(Brandon Brown) #3

This unfortunately won’t show when someone was placed on hold. We are currently having a problem where some of our agents will answer a call and immediately put them on hold and then either forget about the caller until they hang-up or transfer them into another queue or extension. We are looking for a way to flag these calls which we can do by parsing the ‘full’ log but it breaks when it is an agent to agent transfer since the channel name stays the same. Do you know of a way to get ‘hold’ events to log into CEL? It would also be nice to flag calls where an agent kept a caller on hold for a long time which would be easy to do if we could log the ‘hold’ events


#4

Are your agents using server side ‘hold’ feature or phone side ‘hold’ buttons ?


(Brandon Brown) #5

I assume it would be phone side. We use Bria, so when the call comes in they have to answer it before clicking the pause/hold button


#6

I’m not sure how or if Bria tells the server how it’s handling calls internally, perhaps use ‘Parking’ instead.


(Brandon Brown) #7

I know Bria sends an INVITE packet when it places callers on hold. We would have to tell agents to start using a feature code for Parking right? I doubt we can change the default behavior inside of Bria for the hold button.


#8

I would investigate how asterisk handles that INVITE with sngrep, if it ends up in the CEL table likely the linkedid might be the original uniqueid