none
Allowing global commands during a statement-type prompt RRS feed

  • Question

  • I'm looking to allow global commands to interrupt during a long report statement. Since statements don't have a barge-in property, I have been trying to use a Question Answer activity to make the statement. I then tried to make a grammar that would always return true so that if nothing was said, it would still move to the next term in the workflow. This didn't work though.

    I was wondering if there are any other ways around this. Perhaps to call an end to the question answer activity's activity manually or something.

    I appreciate any help.
    Thanks

    Guy
    Tuesday, July 17, 2007 1:12 AM

Answers

  • Guy,

     

    I think the best way to achieve what you want is to wrap the QA in a SpeechSequence, and provide that SpeechSequence with a ConsecutiveNoInputSpeechEventActivity, which contains a GoToActivity pointing to the activity after the QA in the workflow (or elsewhere, as you wish).  Set the ConsecutiveNoInputSpeechEvent to trigger on a single "no input" event, and you should get the behavior you're looking for.

     

    Note, however, that you might hit a bug involving GoToActivities in SpeechEventActivities, in which if the event is triggered by the user hanging up, the workflow hangs after the SpeechEvent executes.  This will be fixed in the release version, and in the meantime you can work around it by checking that the TelephonySession is still Connected before executing the GoToActivity.

     

    A suggestion - are global commands truly the only valid input during this extended prompt?  An often-useful pattern is to push the grammars from the next QA in the flow "up" to the QA which plays the long prompt.  This way, when the user says something, they will not only stop the prompt, but will also be obeyed, rather than having to repeat themselves in response to the next QA in the flow.  You can then use the TurnStarting event on the QA to play just a short prompt on the second and subsequent turns, so that if the user says something unintelligible, they don't have to sit through the long prompt again to find out what their options are.

    Maybe this isn't relevent to your application, but I thought I'd suggest it.

     

    Wednesday, July 18, 2007 12:02 AM

All replies

  • Guy,

     

    I think the best way to achieve what you want is to wrap the QA in a SpeechSequence, and provide that SpeechSequence with a ConsecutiveNoInputSpeechEventActivity, which contains a GoToActivity pointing to the activity after the QA in the workflow (or elsewhere, as you wish).  Set the ConsecutiveNoInputSpeechEvent to trigger on a single "no input" event, and you should get the behavior you're looking for.

     

    Note, however, that you might hit a bug involving GoToActivities in SpeechEventActivities, in which if the event is triggered by the user hanging up, the workflow hangs after the SpeechEvent executes.  This will be fixed in the release version, and in the meantime you can work around it by checking that the TelephonySession is still Connected before executing the GoToActivity.

     

    A suggestion - are global commands truly the only valid input during this extended prompt?  An often-useful pattern is to push the grammars from the next QA in the flow "up" to the QA which plays the long prompt.  This way, when the user says something, they will not only stop the prompt, but will also be obeyed, rather than having to repeat themselves in response to the next QA in the flow.  You can then use the TurnStarting event on the QA to play just a short prompt on the second and subsequent turns, so that if the user says something unintelligible, they don't have to sit through the long prompt again to find out what their options are.

    Maybe this isn't relevent to your application, but I thought I'd suggest it.

     

    Wednesday, July 18, 2007 12:02 AM
  • I used the first method and that worked exactly as I needed. I couldn't use the second method as the workflow immediately leads back to the main menu after the statement. Thanks for your advice.

    Guy

    Friday, July 20, 2007 7:18 PM