Have code. Will travel.

It's an inevitable fact: all software contains bugs and they usually aren't on purpose. Unless you need to guarantee a client is gonna pay you. (kidding. kind of.)

I noticed last week there were a lot of calls being tested but very few were passing. It looks like they weren't able to pass the audio code test. Was my code broken?

What was the actual problem?

This bug brought up a few usability questions for Banana Phone:

Were the instructions not clear enough for the caller to understand what to do?

Was there a bug with inputting the code after the caller hears the audio clip?

Can we somehow pre-load the White List with contact info so the people we talk to regularly don't need to test at all?

The answer to all those questions is "Yes." I investigated a little further and found the bug.

Here's a simplified flow chart for the Banana Phone software that shows where the bug is:

The part where Banana Phone accepts button pushes from the caller to input the 4-digit code was broken, and would only sometimes accept the full 4-digit input from that caller. Intermittent failures are a burn.

For example, the caller would hear an audio clip with the code "4157", and enter "4157" on their phone's dialpad, the system would ignore the first number and only see the "157" part. Thus, legit callers who were passing the human test were getting hung up on. This is clearly a huge bug.

Explanation

This bug was caused by me trying to do something fancy (as most bugs are).

I tried to have the audio play in the background while the user was pressing buttons at the same time.

This should be pretty standard functionality, and Asterisk offers this out of the box. I tested this dialplan on my prototype hardware (more on that at a later time, testing is going great) and this worked fine.

But on the original set-up with the Obi110 ATA and the Raspberry Pi, the command layering in the dialplan didn't agree with the ATA. It caused the call input to lock-up temporarily while the user entered the code, and thus ignored the first digit pressed.

In addition, I have adjusted the audio files to be shorter, about 8 seconds, to allow the caller to hear the entire 4-digit code before they start to enter it. I've also added an extra section in the audio files that slightly clarifies what the caller is supposed to do when they hear the code so Banana Phone can be as user friendly as possible.

I've listened to a lot of newly generated audio files since fixing this bug and it is pretty concise. I've updated the audio files available for download on the tutorial pages as well to reflect this change.

What about pre-loading contacts to our white list?

Banana Phone, as it currently stands, performs the job it's supposed to: block robocalls. The human caller testing and white list is a proven proactive solution to robocall filtering, but it can still be a little confusing for callers to go through the human test.

It's a common pattern in software design to develop the minimum amount of functionality first, then add on features later to make the product better. So this brings us to the problem at hand: How do we make Banana Phone into a mature product concept?

Simple. Have a mobile app that ties it to your smart phone.

This is the next logical step in creating a real product from proof-of-concept software. My goal here is to create a system that block ALL robocalls on ALL devices, so a mobile app is the next large step towards that.

Having a mobile app enables us to:

Load up our existing phone contacts into our device's white list

Automatically add newly saved phone contacts to our white list

Block robocalls on our mobile device just like our landline device

That last one is a little tricky, but it just so happens I'm also a talented Android developer.

I'm laying out the back-end database for call processing and sharing white list data among a user's associated devices now.

That code isn't really "tutorial" friendly, plus Mr. Wizard can't just be handing out all the secrets. There's an end goal here, mind you.