Detecting a call being answered

[paulbibby]

Hello,

I've got some code in _processCall (called on the dialog's change event) that I'd like to only run once when the call is answered and at no other time. I had planned to do this by looking to see if the state was ACTIVE, but I've seen some strange behaviour concerning requests to  _processCall() when the caller hangs up.

During one sandbox _processCall() was being requested when the caller hung up, followed by a request to handleEndDialog(), however in another sandbox I only saw the request to handleEndDialog() and no _processCall() request before the hangup. Both sandboxes were 11.5 sandbox with 6002 calling 6007. Does anyone know why this may be? From the logs I can see that when _processCall was being requested before the hangup the call type was AGENT_INSIDE, however in the other sandbox the call type was OTHER_IN (captured when the call started), so maybe the sandboxes were configured differently.

Based on the above behaviour I can just set a flag to  check if it's the first change in an active call, but is there a better way of doing this? Some other event to listen to?

Cheers,

Paul

[dekwan]

Hi Paul,

Based off of your description, it is most likely due to either who hung up first or the order of events as a result of the hang up. Finesse due to CCX/CCE does not guarantee the order of events. When it is a two party call and the caller hangs up, sometimes the event happens where:

1) caller is DROPPED and agent is ACTIVE. Then agent & caller is DROPPED and you get a DELETE

or

2) agent is DROPPED and you get all of the events after.

So what I would recommend is to check that at least two parties of the call are in ACTIVE state.

You will have to look into the webservices logs to verify that my theory is true. Take a look at the dialog events that you receive when these methods are triggered. You will probably see a pattern.

Thanx,

Denise

[paulbibby]

Thanks Denise, that makes sense now!