||8 years ago|
|.gitignore||9 years ago|
|FirstMenu.py||9 years ago|
|LICENSE||9 years ago|
|README.md||8 years ago|
|SecondMenu.py||9 years ago|
|SimpleSpeechAuto.py||8 years ago|
|SimpleSpeechManual.py||8 years ago|
|SimpleWebApp.py||9 years ago|
|WatergateMenu.py||9 years ago|
|micro_webapp.py||9 years ago|
|otherREADME.md||9 years ago|
A robot that creates a Twilio menu to play audio files.
Tony Gwynn uses two methods: voice menus, and text menus.
The User Workflow
This is a "user" workflow for a very simplistic phone menu app.
To access the menu, the user calls up (or texts) a phone number.
This presents a first-layer menu where they select one digit.
This information is passed to a second-layer menu where they select one more digit.
This information is passed to a third-layer menu where they select one more digit.
Finally, the menu says all three digits back, and redirects the user to the main menu.
The Python Web App Workflow
You begin by writing an app that interacts and exchanges information between the browser and Python, and between Twilio and the user and yourself.
To run a Python web app, you can use a webapp framework like webapp2 or Flask. These provide the glue between HTTP requests (GET and POST, made by users through the browser or by Twilio via their API) and your Python app. These web frameworks open up a particular port and listen for requests. If you point Twilio to this address/port combo, it will redirect all incoming call requests to this URL.
To run webapp2, you just run the Python script - it's that easy. Just run:
and point Twilio to the computer on which you ran that command. Then, when users call your Twilio number, their call gets turned into a GET request from Twilio.
When a user calls, Twilio turns that caller into an interaction node sending/receiving data. Twilio passes information back and forth to your app. If you give it the port where your webapp is running, then Twilio is talking to your webapp through that port.
When you create methods like get(), you're constructing your webapp's response to Twilio's GET messages. Those messages will contain information, which you will gather, process, and use to craft your response. Then you send your response. And repeat.
This is a "Hello world" web app. It just prints some text to the browser.
This is a simple "Hello World" app that says hello to a caller.
It manually constructs the TwiML required to say hello.
In this case, we are running a server that listens for requests from Twilio (i.e., when someone calls the phone number). That means the server has to be listening on a port that's open to Twilio on a firewall.
This example is similar to the example above.
It automatically constructs the TwiML required to say hello, by letting the Python TwiML object do the hard work of writing the TwiML.
See the note above - this listens for callers from Twilio,
FirstMenu is a simple menu where the user enters a digit, the app repeats the digit back, and the user is redirected to the main menu again.
Nothing groundbreaking or exciting.
SecondMenu introduces an additional layer to the menus, which requires earlier menus to pass information to later menus.
This changes the layout of the script. Whereas before we were defining a Request type, now we are defining a WSGI (Web Server Gateway Interface) object, which allows for more flexibility in defining routing rules and so on.
The first menu processes a GET request (the initial phone call).
It then passes the digits pressed by the user to a POST request.
It then saves and recites the digits pressed (the first menu's digits).
It then redirects the user to a new menu (the second menu).
It then accesses the digits saved to repeat them back to the user (the first menu's digits).