Our user list is in a sqlite db. That's also what lines 1 and 4 are about : Adding the LUA extension (line 1) and opening the database (line 4). It's a bit buggy : Sometimes we end up with a locked SQLite database, and all further operations fail. The solution is either a MySQL database, reverting back to textfiles, or fix the locking issue. I haven't fount the cause yet.
A context is a group of extensions. In this dialplan, all SIP phones end up in the context sipphones. The incoming ISDN lines are mapped to the bri-incoming context. That means that you can also do nice things with incoming calls, based on the number of the calling party. This script looks up the number using a REST call, and then displays the number on the display of the phone.
The default context (which is always present), maps to the unauthenticated context (using the include directive), and that just calls a function that drops the call.
**Initialisation and extensions ** We define our outgoing interface on line 10 : TRUNK, which is our ISDN BRI card.
The API key on line 13 is for the interface to our admin interface, which requires a login and cookies, except when using the API, which needs the apikey.
The actual work is done in the extensions table on line 352 : That maps what extension (read : number) is handled in which context. It also determines for example what happens when you dial 911 (or 112) : You want that to work, even when the extension isn't logged on.
In short : It maps dialed numbers to action the PBX takes. For example : If you dial #741, you ask the PBX to call e_hotdesk_login(), with the context and extension as arguments.
It does checking (is the extension enabled, and not already logged in), asks for the PIN, and if that is correct, writes the SIP phone ID to the database, and puts the user on the right queue.
Logging out is the reverse : Remove from the queue, and remove the SIP phone ID from the database.
The dialplan we now use is sub-optimal : You need to think about the public service, and what mapping the SIP phone uses, and is hardcoded. That might interfere with the dialplan you think up, which get's you into trouble.
Make sure you get this right : Users get annoyed when the dialplan changes on a regular basis, and you end up with unhappy collegues.
Issues I've ran into :
No real argument checking of the calls into Asterisk from within Lua. Documentation is a bit scarse, so you need to debug, and have a debug console run at maximum level open while writing the Lua code.
The SQLite DB keeps getting locked, especially when the DB is accessed a lot. No idea how to fix this, or what the real cause is. A good solution would be to use Yaml instead, since the file is mostly read-only anyway.
When doing a transfer, the person doing the tranfer is displayed, instead of the caller. The cause is that Asterisk acts as a intermediate gateway, doing an outgoing call, and then a passthrough between the two connections. It's fixable in theory.
Conslusion : You can do a lot of very nice stuff with Asterisk. I have really touched the real nice goodies yet. Hope I can some day.
If you cant to discuss : contact me.