The log you sent has one application error in it. The Label "SAVE_RESULT" apparently exists, but isn't connected to anything. If you have a Label named "SAVE_RESULT" that is connected to a step, I would recommend doing a search to see if a label with that name is in more than one place in the application. You should find at least one with a dangler that isn't connected to anything. Either connect the one Label with no link to the correct place in the flow, or delete any "SAVE_RESULT" Label steps that are extras and shouldn't be in the application.

Here is the output in the log that shows the error:

Hi Chris,

I have been following this thread and it's great you guys have seemed to find the bug. My thoughts are why didn't the Teleflow Designer software pickup this bug when the ap is saved/compiled? It should have been an easy bug for the Telelflow Designer software to find.

We are currently looking at using Teleflow to build our IVR/dialer ap.

Daryl

Excellent question Daryl! For a start, TeleFlow applications aren't compiled, and are in fact interpreted by the TeleFlow Server (or TeleFlow Simulator) when run.

However, you are correct that this particular type of error is something that TeleFlow Designer can determine. In the "Tools" menu is an option called "Local Steps for Errors" which finds broken links and obvious errors that can be determined at design time(such as when a required field isn't populated with anything), and allows you to jump to them to fix them.

Having said that, this does raise an interesting point. There has been some discussion about this, and the conclusion is that TeleFlow Designer should, by default, run something akin to the "Local Steps for Errors" when you save your TeleFlow application. This way you could catch these errors before they become a problem. I don't have a release date yet, but this feature will be in the next version of TeleFlow Designer.

We will post to this thread when the next release becomes available.

Thanks!

We found what was causing the issue, and it seems to have cleared everything up - I haven't had to restart the service in over a week now, and that's GREAT. Thanks for your help in resolving this! To continue with Daryl's point, we found a key difference in Simulator versus Real-Time, and that was the playing of WAV files in a specific format that NMS required. We would've caught a lot of problems a lot sooner, preventing our need to post questions to the forums, if the simulator by default restricted the formats to the Engenic supported telephony hardware or if we could've told simulator that we were using NMS. So as a result, all of our WAV testing had to be live, which was really problematic on a production system... Just a thought for a future release!

Chris and Tim - Thanks again for your help and patience,

That's great news!

On the WAV issue, you make an excellent point. It was actually because of how contentious audio issues could be that we standardized on the specific telephony-grade audio formats(a single format of WAV, one of VOX, one of VCE) we did. The Voice Script Manager records directly to the WAV format, and you will also find that if you record to WAV files in TeleFlow Simulator (in a TeleFlow Application with a Record step) it records to that format.

Having a unified format at the design level also helps if there is a need to convert to another format(such as VOX files for applications run on Dialogic hardware).

Unfortunately, as you found out, that standardization does not extend to the TeleFlow Simulator. Given that this can be quite misleading, this issue could use some attention. While we are not presently ready to revisit how audio support is being handled in TeleFlow, it is something we will look at again in the future.

For the time being, I would recommend, to save yourself the trouble of double-testing, the following: If the files you are going to use in production are being created by the developer, use the Voice Script Manager to record them. If they are being supplied separately, but are available to you when you are testing your application in TeleFlow Simulator, be sure to convert them to the 8kHz, 16-bit, Mono Windows PCM Wav file format before you start your testing. This way you are testing with the exact same files in simulation as you will run with in production.

You will still need to run a few tests when you do a new installation, because you want to ensure the volume is appropriate on the phone, and that you have the NMS configuration correct(the NMS card must be configured to play the audio format you want it to play). You might also have specifically made changes to where the audio files are in production that differs from where they are in Simulation.

There is a new version of the TeleFlow software available, and the "automatic search for errors on save" feature discussed in this thread has been added to the TeleFlow Designer.

Whenever you save an application in this version of TeleFlow, you will notice a red icon with "E: {number}" in the menu bar (immediately before the button to launch TeleFlow Simulator). The number shown indicates the number of errors found, and clicking this icon/button brings up a list of errors you can jump to and fix.

Find the latest TeleFlow software here: http://teleflow.org/download.html