Cisco Support Community

Reliable way to distinguish parked calls and incoming calls

I'm wondering if anybody has managed this in the following scenario:

A calls B

B parks the call

B takes the call back.

From B's point of view, it has 1 received call from B, and one outgoing call to the park number.

From A's point of view, there's one outgoing call to B and that should be it. However, there are two CallCtlConnEstablishedEv's on A's side when B takes the call back, resulting in another received call. I've been tracing A and B via JTrace and while I can easily distinguish between a regular outgoing call and the call being taken back from park on B's side, on A, the only two times CallControlCause is CAUSE_PARK is when the Call is being disconnected.. those events are preceded by CallCtrlConnEstablished (and all the other evs indicating a connection is being set up). I tried storing CallIDs as well.. the problem is those change.. when the call is lost for A, I can store the CallID.. then when the call is taken back.. the CallID has changed.. in fact there are two CallIDs.. one for the call from B to the park number, and then another one for the call between A and B.

So safe for storing callee and called party and try to match parked calls with newly established calls (which is unreliable.. imagine the call has been parked and now A puts the call on hold, then makes a new call to B) I see no way to prevent having a received call in A's call log when B takes the call back from park.

Do you have any ideas?


Re: Reliable way to distinguish parked calls and incoming calls

I've dug a bit deeper and found the problem. As far as parking the call goes.. no problem. Then B calls the park number, which creates a new CallID.. which is of course correct.. and here is where the problem lies: the call currently on park is being transfered to the new call.. so the CallCtlConnEstablished Event on B has a new CallID and of course that's considered a new call.

CreatePlease to create content