GotSpeech.NET

Does anyone know if the VoiceXML Interpreter is available from the core API?

---

Marc LaFleur




Blog: Speaking from the Edge

No, it's not.

---

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

I figured.

I did end up with a viable workaround. I created a workflow that contains the VXML activity. By starting that workflow with some input parameters I was able to replicate the functionality I needed.  I'm now able to drop out to VXML when I need but otherwise work directly with the API.

---

Marc LaFleur




Blog: Speaking from the Edge

Can you explain what you did here? I sounds useful. I have this fear about running part of my application as a workflow and other parts just using hte core API. The fear centers around not really knowing evertying the workflow is doing behind hte scenes and my Core API code not playing well with it. Does this apply to your situation, and if so, have you seen any issues?

Thanks,

Mike

Good question.

When you kick off a workflow from the API is takes over your application until it completes. Think of it as modal. I've run a good number of calls in our test lab (40,000 or so) and we've see no issues so far.

I've got an example of how to kick off a workflow on my bog - Executing a Speech Server Workflow via the API. I used the same method with the VoiceXML interpreter by passing in the starting page as an input parameter.

Hope this helps.

---

Marc LaFleur




Blog: Speaking from the Edge

Thanks marc,

It's good to hear that you have done this and haven't seen any weirdness. I have seen teh value in jumping into some workflow code at points in my core API based app, but was fearful of the unexpected.

Mike

That's a good way to think about it.  Here's a couple of things to watch out that come to mind:

1. Make sure you've unsubscribed from SpeakCompleted before invoking the workflow, otherwise your handler will be invoked if the workflow contains a Statement.  The same goes for other event handlers to which you might have subscribed.
   
2. Following on from (1), the safest thing to do is to ensure that your core app doesn't try to interact with the CoreAPI whilst the workflow is running.  This applies particularly to SpeechRecognizer et al; e.g. you'll confuse QuestionAnswerActivity if you start a recognition in parallel.  However this doesn't stop you doing things in parallel to the workflow that are unrelated to the workflow activities, e.g. a database lookup, and using IApplicationHost.QueueEvent is safe.
   
3. Watch out for property changes when the workflow completes.  E.g. if QuestionAnswerActivity changes ISynthesizer.InitialSilenceTimeout, I think the new value persists for the rest of that call.

---

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Those are all great points.

Your third point is really important to remember. You should never assume that the default value of a given property is the current value of that property. I expressly assign the values of every property relevant to the event I’m kicking off just for this reason.

---

Marc LaFleur




Blog: Speaking from the Edge