Recommended Wazo-native way to manage dynamic custom dialplan routes?

1

Hi,

I need a production-safe way to manage dynamic custom call routes in Wazo without writing Asterisk dialplan files over SSH and running dialplan reload after every change.

Today I generate custom entries under:

/etc/asterisk/extensions_extra.d/*.conf

for routes like:

  • tenant/context A extension 1000 → tenant/context B queue/extension

  • callback extension 7001 → tenant/context A device extension

This works, but I would prefer a Wazo-supported approach.

What is the recommended Wazo-native method for managing dynamic custom dialplan/routes via API or database, while still keeping Wazo in charge of tenants, users, endpoints, lines, and queues?

Should this be handled with:

  • Wazo API-managed custom routes?

  • Asterisk realtime/database lookups from a static dialplan?

  • a Wazo plugin/service?

  • another supported mechanism?

Main goal: route changes should take effect without regenerating dialplan files and reloading Asterisk each time.

Thanks.

2

The wazo system handles dialplan by dynamically generating the extensions.conf config file (through wazo-confgend). When the configuration changes the dialplan, a dialplan reload asterisk command is triggered automatically.

Unfortunately Wazo doesn’t currently support the Asterisk realtime architecture or similar to pull dialplan directly from the database without reloading.
“Dynamic realtime” dialplan, where updates to the dialplan in a database is reflected directly without needing a dialplan reload, is in fact not recommended for performance reasons among other things.

If you want to explore this further for your specific use cases though: Realtime Database Configuration - Asterisk Documentation .
I cannot help you with that, but you might be able to work something out with some asterisk and dialplan customizations.

For customizing dialplan using the wazo APIs, what’s currently missing is that we don’t support a “custom” type object to be associated directly with internal extensions: https://api.wazo.io/documentation/api/configuration.html#tag/extensions/operation/create_extension.
But we do support that for incalls: https://api.wazo.io/documentation/api/configuration.html#tag/incalls/operation/create_incall .
Note though that the “custom” destination is a single dialplan string. So this could be an application call like Playback(some-sound) or Dial(Local/extension@context) but not a multiline dialplan script.

For the conventional way to manage custom internal extensions in Wazo, I think the most flexible solution remains to maintain extra custom dialplan outside the wazo database. You might replicate the wazo-confgend pattern: wazo-asterisk-config/etc/asterisk/extensions.d/01-wazo.conf at master · wazo-platform/wazo-asterisk-config · GitHub.

You can use #exec /some/binary in an extensions_extra.d file, to have asterisk execute some binary (e.g. a shell or python script) to obtain the dialplan in conventional format. That script might be pulling data from a database to generate the dialplan format on the fly, as confgend does. Or it might pull pre-rendered dialplan conf from a database, or do anything else that results in dialplan conf.