Einleitung
Das Problem bei der Benutzung von Variablen im Dialplan ist, dass der Wert dieser und überhaupt aller zur Laufzeit definierten Variablen bei einem Systemabsturz oder einem Neustart von Asterisk gelöscht wird bzw. dass die Variablen auf ihre Anfangswerte zurückgesetzt werden. Dadurch sind bestimmte Einsatzszenarien gar nicht denkbar. Wenn man beispielweise eine Call-Forwarding-Funktion[1] oder ein Calling-Card-System implementieren möchte, dann sollten diese natürlich z. B. das Restguthaben in einer Datenbank speichern, damit diese Daten bei einem Neustart des Systems wieder korrekt zur Verfügung stehen.
Performance
Für kleine, schnelle Lese- und Schreibzugriffe (Call-Forwarding-Ziele,
kleine Zähler, Feature-Flags) ist die AstDB die richtige Wahl.
Historisch lag sie in einer Berkeley DB, seit Asterisk 11 in einer
SQLite3-Datei (/var/lib/asterisk/astdb.sqlite3) — beide sind für
Key-Value-Zugriffe schnell genug, um sie im Dialplan bedenkenlos zu
nutzen.
Sobald aber komplexe Datenmodelle ins Spiel kommen (User-Profile mit
vielen Feldern, Queue-Zustände über mehrere Tabellen, Realtime-
Konfiguration), ist die AstDB das falsche Werkzeug. Dann lohnt sich
der Sprung zu einer externen Datenbank (PostgreSQL, MySQL) —
angebunden per func_odbc, res_config_odbc/res_odbc oder per
ARI-Anwendung, die ihre eigene Persistenz verwaltet.