I've been working for some time now on a problem that I've been having with the Brooktrout TR1000 and outbound calls that include a <GenerateDigits> tag. What's happening is that after some variable number of calls between 1 and 10 but usually closer to 1, I see two messages in the Windows Application event log and the port stops responding.

The messages that I see are:

Call Manager in wrong state Internal error - no user action defined.
[ERR] Recvd ICALL_ON_CLOSE_REQ in wrong state:StopAllMedia | File: CMsg.cpp Line: 892 SessID: {D2CF62FE-1F09-42F5-9C08-777539700EC2}

followed by:

Call Manager in wrong state Internal error - no user action defined.
Recvd ICALL_ON_FINAL_RELEASE_REQ in wrong state:StopAllMedia | File: CMsg.cpp Line: 999 SessID: NuLL

Microsoft support has put me in touch with Intervoice, who is now looking at my log files to determine if the problem is me (my application) or some sort of bug, perhaps in the Intervoice TIM.

---

Late breaking update: Cantata has just contacted me with a descripition of the root problem and a workaround. The problem is caused by attempting to play a prompt while the <GenerateDigits&rt; tag is still sending out digits. Cantata says:

We don’t implement PAL_SUBERR_MUTUAL_EXCLUSIVITY and maybe that’s the problem. Our firmware does not allow simultaneous GSEND and PLAY...I assume this is a valid sequence from the TIM perspective. However this could be a TIM bug. We still need to figure out who should be doing what.

The workaround is to add a "thread.sleep(4000)" in the postback of the page that sends the digits so that there is a delay between the sending of the digits and the playing of the prompt that is on the next page. I've done this and have been able to make more than 150 consecutive problems without the error messages appearing.

---

Even later breaking update: Thanks to the help of the folks at GotSpeech.Net, I've found and resolved the root issue of this problem. It turns out that when you send a message you actually get two messages back in response.

The first message, GenerateDigitsResponse, indicates that Speech Server has started sending the requested digits. The second message, DigitsGeneratedEvent, indicates that Speech Server has completed sending the digits. So what happening is that flow was being passed on to the next page in my application as soon as digits began to play, resulting in digits playing at the same time as the prompt.

The thread.sleep workaround just caused the page to pause long enough for the playing of digits to complete before transferring control. However this was not the optimum solution as the amount of delay necessary would change with the number of digits being sent.

To make the SMEXMessage control that I'm using to send the message wait until it receives a "DigitsGeneratedEvent" message before continuing, I use the following javascript function as the SMEXMessage OnClientReceive event handler.

function SMEX_OnClientReceive(sender, sCTSA)
{
 var OKToContinue=false;

 var MyMessage = sCTSA.baseName;

 LogMessage("msgid_1", "SetDigits_OnClientConnected executed");
 LogMessage("msgid_1", MyMessage);

 switch (sCTSA.baseName)
 {
  case "GenerateDigitsResponse":
   break;

  case "DigitsGeneratedEvent":
   SpeechCommon.Submit();
   OKToContinue=true;
   break;

 }

 return OKToContinue;
}