Implementing a phone service only callable by registered numbers and users
Via FreeSWITCH
NOTE: This post is a work in progress.
Our Access News service has been using the Telephone Reader system for more than two decades, but it is time to switch. The main reasons:
- Windows 7 server (end of life)
- User credentials (two 4-digit code for user ID and passcode) are barely accessible for listeners, who are visually-impaired.
- Hard (and expensive) to customize
- Difficult to maintain for blind operators
- Outdated on-site hardware
- Proprietary
Why FreeSWITCH?
Have nothing against Twilio, Nexmo, etc. but (1) it is relatively easy to set up a FreeSWITCH server from scratch (even in the cloud), (2) free, (3) has more features than one can use, and (4) I am a textbook overcomplicator (and like to know how things work).
To prove (1) above, here are the set up instructions for Debian 9, which worked out of the box on a new Google Cloud Engine instance.
See the official documentation and the latest book, FreeSWITCH 1.8. Both are messy at times, but all the needed info is there.
As mentioned in the beginning, the current system requires two 4 digit codes from users, and these can be preset when saving in contacts. This may not always work though, and switching a phone is always a hassle. With FreeSWITCH, it is possible to simplify user experience:
- Calls can be whitelisted based on incoming phone number, that will get registered when the user signs up.
2. Passcode & user ID mechanism as a fallback. (E.g., user is travelling, anonymous calls)
Getting a number and connecting the back-end to a telco
telco: telecommunications company, in this case, a SIP provider
Chose SignalWire, because it was founded by the people behind FreeSWITCH (making it easy to set up), and is cheap.
Whitelist registered numbers only
The dialplan consists of contexts that in turn contain one or more extensions. Conditions inside an extension are used to evaluate incoming connections, and decide whether the actions in an extension are executed.
NOTE: An “extension” is a broad term, and does not necessarily mean a phone extension. See the XML Dialplan chapter or its Beginning Concepts section if too eager.
Conditions allow matching against channel variables (see full list), such as the the number of the caller ( ani , i.e., automatic number identification of the caller).
1. First try: stack XML conditions
Conditions can be “stacked” as the above XML snippet shows: first, check whether our registered number has been called, and, if true, see if calling number matches our regular expression.
The problem with this approach is that the failure of any conditions results in jumping to the next extension (i.e., skipping any subsequent conditions and, hence, actions). One could play with the break attribute, but it is error prone, and it has its quirks.
For example, in case of
break="on-false", the default, if the condition is false, then actions are skipped, and evaluation jumps to the next extension. Conversely,break="on-true"stops evaluation if condition is true (skipping subsequent conditions), but the actions in the condition will be flagged to execute!
2. Use the <condition regex=...> syntax
From Beginning Concepts, it allows to create a logical OR relationship between sub-conditions:
The problem with this one is that it is static, and not very admin-friendly: new numbers can only be added by editing the XML, and reloadxml has to be issued for the new dialplan to take effect.
3. Use (Lua) scripts
Specifics are coming, but have to implement it first.
Get ANI from the session, and do a database query for that number; if there’s a match, let the call through. If not, offer a passcode challenge, and drop call if all fails.
