We have an application which requires a conference to be established based on information provided by the original caller. The flow of the application is similar to the following:

1) Original Caller (A) calls VXML application (inbound call)
2) Caller A answers a series of questions
3) Caller A is then placed on Hold.
4) The application places a Dial attempt to Party B.
5) If Party B answers the call, Party B is presented with the option to press '*' to connect Party C, or press '#' to connect Caller A.
6) Party B presses the '#' key and Caller A is conferenced with Party B. At this point, both Caller A and Party B are conferenced.
7) Caller A hangs up on the conference.

The application never gets the updated state of Caller A as 'disconnected'. In the aesconnector.log file, I found the following lines which show the disconnect was recognized, but the state was updated to the value "conferenced".

Is there a step that I'm missing that would ensure the cti information for each party (Caller A, Party A and Party B) is updated correctly? I've tried using the CallInfo data object, but the value is always "conferenced" for each party.

<!-- BEGIN CUT -->
30/07/2013 12:12:36:703 DEBUG - getObserversFromCallId: gathering observers... done waiting on sync list size of list is 48
30/07/2013 12:12:36:703 DEBUG - CTICallObserver.callChangedEvent:8731: got Connection Disconnected Event 107
30/07/2013 12:12:36:703 DEBUG - CTICallObserver.callChangedEvent 8731: Event: 3 is 205 for call 316 Provider:AES2
30/07/2013 12:12:36:703 DEBUG - CTICallObserver.callChangedEvent:8731: got Connection Disconnected Event 205
30/07/2013 12:12:36:703 DEBUG - CTICallObserver.callChangedEvent 8731: Event: 4 is 117 for call 316 Provider:AES2
30/07/2013 12:12:36:703 DEBUG - CTICallObserver.callChangedEvent:8731: got an unknown event 117
30/07/2013 12:12:36:703 DEBUG - CTICallObserver.callChangedEvent 8731: Event: 5 is 215 for call 316 Provider:AES2
30/07/2013 12:12:36:703 DEBUG - CTICallObserver.callChangedEvent:8731: got an unknown event 215
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.callChangedEvent 8731: Event: 6 is 107 for call 316 Provider:AES2
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.callChangedEvent:8731: got Connection Disconnected Event 107
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.callChangedEvent 8731: Event: 7 is 205 for call 316 Provider:AES2
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.callChangedEvent:8731: got Connection Disconnected Event 205
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.callChangedEvent 8731: Event: 8 is 102 for call 316 Provider:AES2
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.callChangedEvent:8731: got an unknown event 102
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.callChangedEvent 8731: Event: 9 is 103 for call 316 Provider:AES2
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.callChangedEvent:8731: got Call Observation Ended Event
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.removeCall:clearing MRCR:316 from ext:8731
30/07/2013 12:12:36:719 DEBUG - getObserversFromCallId: done gathering observers
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.removeCall:removing call:316 from ext:8731
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.updateCallState 8731: setting call:316 to state:conferenced
30/07/2013 12:12:36:719 DEBUG - CTICallObserver.updateCallState 8731: setting cached call:316 to state:conferenced
<!-- END CUT -->

Thank you,
Michael

What is the affect it is having on your application? Is it losing the conference? Typically, the caller into VP won't drop off the conference, so the scenario is rather unique. Again, this might be a case for CCXML as opposed to AES.

The end result is the the application doesn't recognize the caller has disconnected. It's not just the original caller, the status doesn't get updated correctly for any of the parties, regardless of who disconnects. If you look at the log snippet I sent, the CTICallObserver obviously gets the notice that the call id has disconnected, yet continues to set the status as "conferenced". Why isn't the status getting updated correctly?

Sorry, but switching to a CCXML application because the CTICallObserver isn't updating the status correctly is not a viable solution. The bigger question is why isn't the status getting updated to the correct value in the CTICallObserver class. Is there something I need to do in my application to ensure the status is updated correctly?

Can you send me the CTIC log for this call from the time the call arrives until it is complete (neilg@avaya.com)? How long after the conf is established are you getting the party A disconnect?

Log is on it's way. :) I also included the trace.log file from the VXML application as well. For this test, the following sequence of events took place.

1) Original caller (call id: 60) called VXML application
2) call id 60 placed on Hold (60 status is changed to "held")
3) application Dial'd another caller (call id: 61) (61 status is "established")
4) application conferenced call id 60 with call id 61 (60 status is "held", 61 status is "conferenced")
5) Application uses CallInfo data node to update call id 60 cti info (updated information shows status is "conferenced", original information shows status is "held")
6) Application uses CallInfo data node to update call id 61 cti info (updated information shows "established", original information shows "conferenced")
7) after approximately 30 seconds, call id 61 disconnected (61 status is left as "conferenced")
8) Steps 5 & 6 are repeated multiple times for several minutes with no change in values
6) after approximately 5 seconds, Original caller (call id 60) disconnected (you'll see the final trace output of the cti call information variables (all 4 of them) are all incorrect as far as the status)

Also note that nobody is "getting" disconnected. The cti variables' status is not getting updated when any of the parties hangs-up. The status should be updated to the correct value when any of the party members hangs up... this is the real issue. :)

Thanks a bunch, Neil. I appreciate your help with this. :)
Michael