HackFMI SMS Delivery Powered by Twilio
Ten days ago the regular HackFMI competition was held. This year they tried sending SMS notifications to all participants which was powered by Twilio both in terms of infrastructure and cost.
Twilio provided a 20$ upgrade code valid in the next 6 months for all new accounts. This was officially announced at the opening ceremony (although at the last possible time) of the competition, however no teams decided to incorporate SMS/Voice into their games. I'm a little disappointed by this fact.
In terms of software a simple Django app was used. It is by no means production ready but does the job and was quick to write.
A little over 300 messages were sent with number distribution as follows:
- Mtel - 166
- Globul - 86
- Vivacom - 50
The total price for Mtel and Globul messages is roughly the same because sending SMS to Globul via Twilio is as twice expensive. The total sums up to about 25 $. HackFMI team used two accounts to send the messages - one using the provided 20$ upgrade code from Twilio and the second one was mine.
There are comments.
SMS PIN Verification with Twilio and Django
This is a quick example of SMS PIN verification using Twilio cloud services and Django which I did for a small site recently.
The page template contains the following HTML snippet
<input type="text" id="mobile_number" name="mobile_number" placeholder="111-111-1111" required>
<button class="btn" type="button" onClick="send_pin()"><i class="icon-share"></i> Get PIN</button>
and a JavaScript function utilizing jQuery:
function send_pin() {
$.ajax({
url: "{% url 'ajax_send_pin' %}",
type: "POST",
data: { mobile_number: $("#mobile_number").val() },
})
.done(function(data) {
alert("PIN sent via SMS!");
})
.fail(function(jqXHR, textStatus, errorThrown) {
alert(errorThrown + ' : ' + jqXHR.responseText);
});
}
Then create the following views in Django:
def _get_pin(length=5):
""" Return a numeric PIN with length digits """
return random.sample(range(10**(length-1), 10**length), 1)[0]
def _verify_pin(mobile_number, pin):
""" Verify a PIN is correct """
return pin == cache.get(mobile_number)
def ajax_send_pin(request):
""" Sends SMS PIN to the specified number """
mobile_number = request.POST.get('mobile_number', "")
if not mobile_number:
return HttpResponse("No mobile number", mimetype='text/plain', status=403)
pin = _get_pin()
# store the PIN in the cache for later verification.
cache.set(mobile_number, pin, 24*3600) # valid for 24 hrs
client = TwilioRestClient(settings.TWILIO_ACCOUNT_SID, settings.TWILIO_AUTH_TOKEN)
message = client.messages.create(
body="%s" % pin,
to=mobile_number,
from_=settings.TWILIO_FROM_NUMBER,
)
return HttpResponse("Message %s sent" % message.sid, mimetype='text/plain', status=200)
def process_order(request):
""" Process orders made via web form and verified by SMS PIN. """
form = OrderForm(request.POST or None)
if form.is_valid():
pin = int(request.POST.get("pin", "0"))
mobile_number = request.POST.get("mobile_number", "")
if _verify_pin(mobile_number, pin):
form.save()
return redirect('transaction_complete')
else:
messages.error(request, "Invalid PIN!")
else:
return render(
request,
'order.html',
{
'form': form
}
)
PINs are only numeric and are stored in the CACHE instead of the database which I think is simpler and less expensive in terms of I/O operations.
There are comments.
Twilio is Located in Amazon Web Services US East
Where do I store my audio files in order to minimize download and call wait time?
Twilio is a cloud vendor that provides telephony services.
It can download and <Play> arbitrary audio files and will cache the files
for better performance.
Twilio support told me they are not disclosing the location of their servers, so from my web application hosted in AWS US East:
[ivr-otb.rhcloud.com logs]\> grep TwilioProxy access_log-* | cut -f 1 -d '-' | sort | uniq
10.125.90.172
10.214.183.239
10.215.187.220
10.245.155.18
10.255.119.159
10.31.197.102
Now let's map these addresses to host names. From another EC2 system, also in Amazon US East:
[ec2-user@ip-10-29-206-86 ~]$ dig -x 10.125.90.172 -x 10.214.183.239 -x 10.215.187.220 -x 10.245.155.18 -x 10.255.119.159 -x 10.31.197.102
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.29.amzn1 <<>> -x 10.125.90.172 -x 10.214.183.239 -x 10.215.187.220 -x 10.245.155.18 -x 10.255.119.159 -x 10.31.197.102
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43245
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;172.90.125.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
172.90.125.10.in-addr.arpa. 113 IN PTR ip-10-125-90-172.ec2.internal.
;; Query time: 1 msec
;; SERVER: 172.16.0.23#53(172.16.0.23)
;; WHEN: Mon Jun 24 20:48:21 2013
;; MSG SIZE rcvd: 87
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52693
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;239.183.214.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
239.183.214.10.in-addr.arpa. 42619 IN PTR domU-12-31-39-0B-B0-01.compute-1.internal.
;; Query time: 0 msec
;; SERVER: 172.16.0.23#53(172.16.0.23)
;; WHEN: Mon Jun 24 20:48:21 2013
;; MSG SIZE rcvd: 100
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25255
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;220.187.215.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
220.187.215.10.in-addr.arpa. 43140 IN PTR domU-12-31-39-0C-B8-2E.compute-1.internal.
;; Query time: 0 msec
;; SERVER: 172.16.0.23#53(172.16.0.23)
;; WHEN: Mon Jun 24 20:48:21 2013
;; MSG SIZE rcvd: 100
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15099
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;18.155.245.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
18.155.245.10.in-addr.arpa. 840 IN PTR ip-10-245-155-18.ec2.internal.
;; Query time: 0 msec
;; SERVER: 172.16.0.23#53(172.16.0.23)
;; WHEN: Mon Jun 24 20:48:21 2013
;; MSG SIZE rcvd: 87
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28878
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;159.119.255.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
159.119.255.10.in-addr.arpa. 43140 IN PTR domU-12-31-39-01-70-51.compute-1.internal.
;; Query time: 0 msec
;; SERVER: 172.16.0.23#53(172.16.0.23)
;; WHEN: Mon Jun 24 20:48:21 2013
;; MSG SIZE rcvd: 100
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28727
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;102.197.31.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
102.197.31.10.in-addr.arpa. 840 IN PTR ip-10-31-197-102.ec2.internal.
;; Query time: 0 msec
;; SERVER: 172.16.0.23#53(172.16.0.23)
;; WHEN: Mon Jun 24 20:48:21 2013
;; MSG SIZE rcvd: 87
In short:
ip-10-125-90-172.ec2.internal.
ip-10-245-155-18.ec2.internal.
ip-10-31-197-102.ec2.internal.
domU-12-31-39-01-70-51.compute-1.internal.
domU-12-31-39-0B-B0-01.compute-1.internal.
domU-12-31-39-0C-B8-2E.compute-1.internal.
The ip-*.ec2.internal are clearly in US East. The domU-*.computer-1.internal also
look like US East although I'm not 100% sure what is the difference between the two.
The later ones look like HVM guests while the former ones are para-virtualized.
For comparison here are some internal addresses from my own EC2 systems:
- ip-10-228-237-207.eu-west-1.compute.internal - EU Ireland
- ip-10-248-19-46.us-west-2.compute.internal - US West Oregon
- ip-10-160-58-141.us-west-1.compute.internal - US West N. California
After relocating my audio files to an S3 bucket in US East the average call length dropped from 2:30 min to 2:00 min for the same IVR choices. This also minimizes the costs since Twilio charges per minute of incoming/outgoing calls. I think the audio quality has improved as well.
There are comments.
Django Tips: Using Cache for Stateful HTTP
How do you keep state when working with a stateless protocol like HTTP? One possible answer is to use a cache back-end.
I'm working on an IVR application demo with Django and Twilio. The caller will make multiple choices using the phone keyboard. All of this needs to be put together and sent back to another server for processing. In my views I've added a simple cache get/set lines to preserve the selection.
Here's how it looks with actual application logic omitted
def incoming_call(request):
call_sid = request.GET.get('CallSid', '')
caller_id = request.GET.get('From', '')
state = {'from' : caller_id}
cache.set(call_sid, state)
return render(request, 'step2.xml')
def step2(request):
call_sid = request.GET.get('CallSid', '')
selection = int(request.GET.get('Digits', 0))
state = cache.get(call_sid, {})
state['step2_selection'] = selection
cache.set(call_sid, state)
return render(request, 'final_step.xml')
def final_step(request):
call_sid = request.GET.get('CallSid', '')
selection = int(request.GET.get('Digits', 1))
state = cache.get(call_sid, {})
state['final_step_selection'] = selection
Backend.process_user_selections(state)
return render(request, 'thank_you.xml')
At each step Django will update the current state associated with this call and return
a TwiML XML response. CallSid is a handy unique
identifier provided by Twilio.
I am using the latest django-s3-cache version which properly works with directories. When going to production that will likely switch to Amazon ElastiCache.
There are comments.