Calls dropped while in park

[AlSam]

I am having issues with calls while in park. I have had several CSR's report that when they return to their desk and grab the call they left in park there is a different caller on the line. I normally would ignore it if it was a few calls but I have had dozens of reports of it. Any help in figuring this out would be greatly appreciated.

[williamconley]

your title:

Calls dropped while in park

and your description:

and grab the call they left in park there is a different caller on the line

are somewhat at odds. (dropped vs different caller ...?)

how long are these calls being left in park?

have you tested this to see what is really happening?

[AlSam]

your title:

Calls dropped while in park

and your description:

and grab the call they left in park there is a different caller on the line

are somewhat at odds. (dropped vs different caller ...?)

They're not really at odds since it seems that the original call (the one that was put on park) gets dropped and when the call is grabbed there appears to be a different caller on the line. Park times may vary from a minute or so to 3 or 4. It depends on how complex the matter it is that the CSR is handling. I haven't really had the chance to do some testing on my own since I would have to be at the customer site in order to do so. I will be making a HW change soon so i will go ahead and do some testing. While doing so, should I be looking at a particular log?

[williamconley]

the agi logs should have the details of what goes into and out of "park"

best to test it in a "controlled" situation (noone on the system) and get a feel for how it "should" look so you can look at the Live Logs and find the flaw.

[AlSam]

I was able to reproduce the problem. CallA is answered by an agent on Zap/1-1. Agent places call in park. CallA is disconnected (for whatever reason). CallB comes in on Zap/1-1. Agent grabs call. CallB is connected to Agent.

[williamconley]

So your openvox card and asterisk are not communicating regarding the hangup properly.

does this happen with SIP calls?

[AlSam]

I don't believe it happened while we were on SIP, then again, I'm not 100% sure. Do you think there is anything that can be done to test this out?

[williamconley]

yep. try it with a sip account call. set up a "test" to duplicate the problem, and when you can reliably duplicate it ... switch to SIP and see if the problem persists. if not ... you'll need to find out why your openvox is not communicating properly, or how it differs.

[AlSam]

Did some testing and had pri debug enabled. What I found is that the OpenVox card is sending the call hangup command. The CLI output shows:

...
[Oct 11 10:32:44] > Message type: RELEASE (77)
[Oct 11 10:32:44] > [08 02 81 90]
[Oct 11 10:32:44] > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: Private network serving the local user (1)
[Oct 11 10:32:44] > Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
[Oct 11 10:32:44] -- Hungup 'Zap/1-1'
...

The parked_channels table does not show the call anymore. However, the web client does not show the call being hung up and remains in park status with the "grab parked call" option still available. Upon clicking on the "grab parked call" button, I end up with the most recent call that came in to 'Zap/1-1'

[williamconley]

well, that pretty much goes along with what matt said ... openvox has all sorts of issues.

you'll have to identify why openvox is hanging up the call. too much silence?

[AlSam]

Let me clarify. During this test, the call was not randomly hung up. I originated the hangup. I hung up the call on my cell phone. I was just showing that the OpenVox card and asterisk are communicating.

[williamconley]

oh! so you hung up, openvox successfully told asterisk to hang up ... but the coding is somehow different from how a SIP call terminates so VICIdial does not recognize that the call has hung up.

But that brings us back to ... what is the difference between a SIP hangup and the OpenVox hangup?