locked
CallDisconnectedException RRS feed

  • Question

  • For our outbound calls we are doing some reporting when the calls are disconnected.  We are seeing some (about 5-10%) of our connected calls never report when they are done. 

     

    This reporting code is being run at the end of the workflow as well as when a CallDisconnectedException is thrown.

     

    Are there any known circumstances where a call could be disconnected and a CallDisconnectedException might NOT be thrown? 

     

    Monday, July 16, 2007 8:58 PM

Answers

  • I recorded the workflow to attach to the TelephonySession.Closed event.  This has proven to be more reliable. 

     

    The problem was not that the workflow would hang.  There were no exceptions and the workflow would complete successfully.  But the CallDisconnectedException would not get thrown. 

    Wednesday, July 18, 2007 7:52 PM

All replies

  • I have looked at some of these calls in the Analytics and Tuning Studio. 

     

    I can see that the sessions were disconnected by user hang-up. But I don't see anything to indicate why our code to handle the CallDisconnectedException is not always being called. 

    Tuesday, July 17, 2007 2:56 PM
  • There is a known issue in beta 2 that could cause this. The scenario is this:

    • the caller hangs up as recognition is running. This causes recognition to complete with a non-recognition
    • you have a SpeechEventActivity (e.g., ConsecutiveSilences) that is then triggered (either the threshold is 1, or else you already had the n-1 non-recognition events.)
    • the SpeechEventActivity contains a GoToActivity that is triggered

    In this case, the workflow will fail to execute the GoTo properly and the workflow will never terminate. Are you able to confirm that this is what is happening? The easiest way might be to insert some logging immediately before the GoToActivity.

     

    The only known work-around for beta 2 is to use an IfElseActivity to execute the GoToActivity if and only if "TelephonySession != null && TelephonySession.State == TelephonySessionState.Connected"

     

    Dan

     

    Tuesday, July 17, 2007 4:47 PM
  • I don't think that's what's happening in this case. 

     

    It seems to happen after a particular statement activity starts running.  After that statement we have a custom activity which plays a prompt and starts listening for DTMF input.  The prompt only plays once even if the result was silence or no reco.  Then another statement activity runs, and then we disconnect the call. 

     

    We do have a ConsecutiveNoInputsEvent set up but the number is set to 3. 

     

     

    Tuesday, July 17, 2007 9:07 PM
  • What if we attached an event handler to the TelephonySession.Closed event and did our post-processing there?  Would that be more reliable?
    Tuesday, July 17, 2007 9:46 PM
  • Doing your post-processing in a handler for TelephonySession.Closed would probably be more reliable.  The one possible problem with this is that you wouldn't necessarily know the state of the Workflow when your post-processing runs.  Depending on what processing you need to do there, that may or may not be a problem.

     

    Do you know where in the [Statement -> Custom Activtiy -> Statement] sequence the flow ceases?  CallDisconnected is thrown by our Workflow activities, but not by the core speech objects (Sythesizer, DtmfRecognizer, etc).  Is it possible that the user is hanging up during your custom activity such that you are getting InvalidOperationException from calling the core speech objects while the TelephonySession is Disconnected?

     

    Do you know if the workflow is terminating successfully, or if it's hanging?  The known bug Dan referred to would result in a hang, whereas if you were getting an exception other than CallDisconnected that should show up in your global unhandled exception handler.  If the flow of the workflow doesn't proceed, and you're not getting CallDisconnectedException, one of those two things must be happening.

    Wednesday, July 18, 2007 12:20 AM
  • I recorded the workflow to attach to the TelephonySession.Closed event.  This has proven to be more reliable. 

     

    The problem was not that the workflow would hang.  There were no exceptions and the workflow would complete successfully.  But the CallDisconnectedException would not get thrown. 

    Wednesday, July 18, 2007 7:52 PM