Realtime is a mechanism within Asterisk that allows you to connect certain parts of Asterisk (chan_sip for example) to a database. The database is queried when something needs configuration. This gives this system its name, realtime. It allows you to make changes in a database in realtime and have them instantly reflected within Asterisk.
But, Josh! Why do you hate it?
I don’t hate what realtime attempts to do. I hate how it does it.
Querying a database has a cost and depending on the database itself querying can take a noticeable amount of time. This slows down your Asterisk process and depending on where the query is taking place can have a blocking effect on other things. (I’m looking at you chan_sip… with your mostly single threaded implementation)
From a developer perspective there is also additional work required to support realtime. It’s not invisible.
There’s a pseudo-replacement for realtime in Asterisk 12 called sorcery that I wrote. I say pseudo because it currently uses realtime to interface with databases. From a developer perspective you code to the sorcery API and everything else happens behind the scenes. It is my hope that there will be native drivers for various SQL and even NoSQL systems as time progresses.
Realtime also means that you are dependent on a database at all times for your information. If your database goes down you are out of luck.
To help with some of these problems a caching mechanism was added to some users of realtime, allowing returned results to be cached for a period of time. This reduces the dependency on the database and allows faster lookup. It also has a cost: You can no longer make changes in the database and have them instantly reflected. This also requires additional work by developers to implement this caching as there is no standardized implementation.
These are the primary reasons I hate realtime.
So… what’s a different way to do things?
Settle for near-instant updates
Does it really matter if it takes a few seconds or even a minute for an update to be reflected? I think in practice the answer is “no”.
Store in a database
Storing information in a database is fine, continue to do so.
Produce configs from a database
Instead of directly connecting your telephony application to Asterisk have a third party application produce configuration from the database. Why is this good? The lack of a database won’t cause a disturbance to your deployment. It may become out of date, but stuff will still function using the old configuration until it is brought back up to date. This also stops Asterisk from having to query another resource, thus removing a potential bottleneck.
Push into Asterisk, don’t pull
While not currently possible the sorcery API does allow this to be added in the future. Instead of having Asterisk pulling from a database you can push information into it in an atomic fashion. This removes the need to produce a configuration and reload everything.
Ignore what I’ve said and still use the database directly
Yeah, this is still an option. You just have to understand what you are doing and the consequences of doing so.