IVR vs Asp.net MVC: How can I stop reinventing the browser? - asp.net-mvc

Question

I'm making an IVR system for a project, and have decided on Twilio to handle the phone portion (making and receiving calls, sending and receiving SMS messages). This will surface a website with an IVR front-end, allowing users to navigate the site using their touch-tone phone.
I'm not making all the content browse-able over the phone, just what makes sense.
Twilio sends in parameters to your URL on the querystring or via POST, and you respond with a special subset of XML that tells the IVR how to act. I made a lot of headway very quickly with ASP.net MVC, treating the Twilio XML content as a View and rendering the site's data to it.
Here's what a response to Twilio looks like:
<?xml version="1.0" encoding="UTF-8" ?>
<Response>
<Say>Hello World</Say>
<Play>http://api.twilio.com/Cowbell.mp3</Play>
</Response>
Here's what a menu looks like to Twilio:
<?xml version="1.0" encoding="UTF-8" ?>
<Gather action="http://your_url" numdigits="1">
<Say>Press 1 to execute your_url, passing a parameter named "digits"</Say>
</Response>
Here's where I'm stuck:
I'm trying to add a universal "back" button, maybe a "skip" button, a "repeat" button, etc, and I'm finding that on each view, I'm detecting the digit pressed and then if-ing to a hardcoded Response.Redirect(). I know this is going to quickly become unmaintainable for large numbers of views and menus.
So, how can I model the MVC app so that it's more like an application and less like a game of Zork? Stacks of Menu objects, each with Lists of MenuItem objects? How can I make, say "9" the universal option for "back" and have the app respect it, no matter where in the menu system the user is, without having to code for it in each view?
The back feature is just a symptom of the chaos this project will step into if I don't take a moment now to design it properly. Are there .net IVR frameworks out there I can inspect for ideas? Any help would be appreciated, I know this is not a novel problem, I just can't seem to get my head around the best path to take.

Answer 1

Although I almost don't have a clue about what you are talking, since nobody sofar said anything I will have a shot at it (don't shoot me if I'm totally not in the direction).
In MVC 2 you can render actions in your views:
<%= Html.Action("home", "menu" , new { someparam = somevalue, someotherparam = someothervalue }) %>
This would call the Menu action in your Home controller with the given parameters. The Result of this Action would then be inserted in your view.
This way you can keep your views clean, and all your Menu stuff in one place. Just have to add the above stated line in every view.
Again the same can be done with HtmlHelper's, yet sometimes the above stated way is just easier.

Answer 2

Ricky from Twilio here.
For some reason, having code that's organized like Zork sounds like fun to me but in practice I can understand how that may drive someone crazy!
We just launched a bunch of non-trivial, production ready tutorials to help when developers have questions about how to organize a specific kind of application. One tutorial is an IVR built using C# with ASP.NET MVC.
Taking a look out how we decide to structure things, we're using 3 controllers to control our logic:
IVRController.cs: This controller contains the code that welcomes a user when they call into our IVR.
MenuController.cs: This controller is where we determine the appropriate IVR menu for the user depending on their inputs.
PhoneExchangeController.cs: In this controller, we have the logic to forward a call from our IVR to another phone number.
As you're looking to customize the experience by adding something like "Press 9 to go back", making changes to MenuController.cs should help get you there.