T1 discoveries
I've just installed a Brooktrout TR1000+P24VH-T1-S in a server where it replaced the TR1000 4-port analog card. The installation, as promised by Cantata technical support, went flawlessly with these caveats:

• I wasn't able to start the TIM after installing the card. In the application event log I saw messages stating "Failed to get line assignments from MTC Server". My interpretation of this error was that I did not have the T1 line plugged into the card (which I did not--but the error could have been a little clearer).
  
  
• After I did plug in the T1 line, I still wasn't able to get the TIM to start. After re-reading the directions, I found that the TR1000-T1 must be used either through a PBX or with a CSU. I put a CSU in the line but the TIM would still not start.
  
  
• Finally, I started up the Brooktrout configuration utility again. I thought I had configured all ports to be outbound but it turns out that I had configured only one to be outbound. The remaining 23 were unconfigured. I dragged the slider all the way over to the left to allocate all ports as outbound and restarted the TIM. This time it worked.

1-800 Discoveries
After starting the TIM and testing it with a sample outbound call, I decided to see if I could get my verification apps to work. These apps periodically dial other IVR systems to verify that they are functioning properly. They make a great test of my outbound software and systems because they run regularly on a scheduled basis and an interruption in service is not critical (at least during the day, and at least not right now).

The numbers that these applications dial are 1-800 numbers. With the previous TR1000, an analog board, the calls were going through just fine. With the new TR1000-T1, I was getting a rapid busy signal. Yet test calls to my desk phone and to my cell phone were going through properly. What could be going wrong, I wondered?

A quick email to our T1 service provider resolved the question. It turns out that outbound 1-800 calls are only possible from a local T1 or from a POTS line. Our T1 is an LD T1. This is not really a big issue as I do still have the analog TR1000 and can put it in another server. The verification applications can then run on that server.

Apparently Speech Server 2007 will be delayed by at least another six months. This is so it can be combined with Microsoft Communications Server. I found out about this on GotSpeech.NET.

My immediate reaction to this is one of disappointment. I had hoped to be using Speech Server 2007 by January. As it now stands, we'll be working with Speech Server 2004 for a while yet.

My long term reaction to this is that it could well be a smart move on the part of Microsoft. The world of telecommunications is changing rapidly. I've been reading for some time about how teenagers in Asia and Europe are far more inclined to "text" on their cell-phones than talk on them, and I think it's only a matter of time before this trend becomes equally pervasive here in the US. Merging Speech Server with Windows Communication Server should allow developers to take advantage of the extra capability of a text-enabled cell phone.

You can already see the first inklings of this convergence. Watch one of the talent contest TV shows. At the bottom of the screen they'll say that you can send a text message to an address to vote for a contestant. So how about systems that allow you either to call or to engage in a text conversation? Verizon is already doing this with the minutes-used reports that they offer subscribers. You can either call or send a text message, and in a minute or two you receive a minutes-used report sent to your phone. I predict that a lot of IVR systems will begin to offer this sort of functionality in the near future. Want your credit card balance? Movie times? Make a reservation?

Of course, Microsoft may be thinking too far ahead. This is the trap that they fell into with Speech Server 2004, which was oriented toward voice-enabled applications. IE: PDAs with speech-enabled interfaces. The idea was good but the need never materialized. I don't think so, though. I think this time they'll get it right on.

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;
}