Interesting question. You need a "voice interpreter" as described by the w3c spec on voiceXML (
https://www.w3.org/TR/voicexml20/#dml1.2.1) to see the RDCs in action. We use the one that ships with IBM's Voice Toolkit 6.0 for RAD 6 (eclipse-based IDE), which lets us hear the prompts using text-to-speech, and which provides a speech recognition engine which supports w3c standard grammars. This lets you interact with the RDCs natively, using a microphone and headset.
As for just running the RDCs, they work on Tomcat 5.x, and also on WebSphere 6.0.1+ (undoubtedly other J2EE 1.4 containers also, these are the only ones I've heard have been tested.
There are lots of free voice interpreter sites you can sign up for over the internet, including
http://community.voxeo.com, and ones run by BeVocal, TellMe, and Hey Anita. The problem is that they don't recognize standard grammars - and so blow up when the RDCs send these along. IBM's voice interpreter is the only one I've found so far that actually supports the w3c recommendation for speech grammars. Nuance-based grammars support a version of the specification from 2001. Until this is fixed - or someone provides grammars for the non-standard regnition engines - you'll have to use a voice browser such as IBM's (RAD 6 or RWD 6 required, and only on Windows due to the TTS dlls).
Having said that, the RDCs are simply JSP 2.0 tags which generate voiceXML, and manage the gathering of voiceXML form field input. We write unit tests for them using Canoo Webtest (free at
http://webtest.canoo.com/webtest/manual/WebTestHome.html). You can also interact with them with an html browser, as long as you've set it up to receive voiceXML, and you don't mind entering URLs such as
http://localhost:9080/VoiceTestApp/vui/choose-language.jsp?langChoiceResultNBest=1;english;english
So you don't need anything other than a browser to see them work, though it's not too exciting without a voice interpreter.
We're about to use the RDCs for a very large voiceXML effort. RDCs were very appealing to us because they 1) push all of the logic down to the application server - familiar territory for java web developers, and 2) greatly simplify the voiceXML by encapsulating logic for gathering form input to "reuseable" components. #1 also makes unit testing possible at the view layer. Typical voiceXML applications push so much logic onto the interpreter, they're basically monstrous client-side javascript applications. In short, impossible to test. Using Canoo, we can easily run through call flow logic and test out all the scenarios without having to use a phone and keypad. While it doesn't test the grammars or prompts, it does test the JSPs and the backend logic quite nicely.