I'm getting into some (for me) really awkward dialplan stuff. If anyone recalls, I have been playing with ConfBridge and 3-way calling with an IVR. The issues I've always had is, which channel has control through the dialplan, which channel has pertinent variables, and how to share that information among members of the bridge.
So far, I've managed a proof of concept using SHAREd variables... but this only goes so far. I have to know channel names of members, I need to establish and share everything before the channel enters the bridge app and loses its place in the dialplan, I need to avoid hoisting data too high in scope so that multiple instances of bridges aren't overwriting each other, etc. Not fun, not pretty, not reliable.
From what I can tell, I'm in need of a temporary data storage method that exists outside of the dialplan but still gets removed when all channels are gone. The scope of SHAREd isn't broad enough, but GLOBAL is too broad. This is where the database or /tmp come into play.
These come with their own set of problems however. I am unaware of a good method of housekeeping. Once calls enter the abyss of ConfBridge via Originate, I have no reliable way of executing instructions to clear my temp variables (either in /tmp or the DB) on the last channel to hangup.... or, at least I'm not aware of any. /tmp will clear itself on reboot, but ideally a reboot will be rare so I would still need to do housekeeping, and a fair share of parsing of data as it would be unstructured. The Database would be a little cleaner in implementation, but I'm not sure if it has its own method of cleaning up. If not, the only thing I can think of is storing the active channels as they join in a keytree identified by the BridgeID, then having a scheduled task that checks the DB for bridges and checks to see if any of the channels contained within are still active.
TL;DR- *slams head into desk*
P.S. Even though I do plan on using ARI in the future... I really don't want to fight with yet another layer of complexity.
So far, I've managed a proof of concept using SHAREd variables... but this only goes so far. I have to know channel names of members, I need to establish and share everything before the channel enters the bridge app and loses its place in the dialplan, I need to avoid hoisting data too high in scope so that multiple instances of bridges aren't overwriting each other, etc. Not fun, not pretty, not reliable.
From what I can tell, I'm in need of a temporary data storage method that exists outside of the dialplan but still gets removed when all channels are gone. The scope of SHAREd isn't broad enough, but GLOBAL is too broad. This is where the database or /tmp come into play.
These come with their own set of problems however. I am unaware of a good method of housekeeping. Once calls enter the abyss of ConfBridge via Originate, I have no reliable way of executing instructions to clear my temp variables (either in /tmp or the DB) on the last channel to hangup.... or, at least I'm not aware of any. /tmp will clear itself on reboot, but ideally a reboot will be rare so I would still need to do housekeeping, and a fair share of parsing of data as it would be unstructured. The Database would be a little cleaner in implementation, but I'm not sure if it has its own method of cleaning up. If not, the only thing I can think of is storing the active channels as they join in a keytree identified by the BridgeID, then having a scheduled task that checks the DB for bridges and checks to see if any of the channels contained within are still active.
TL;DR- *slams head into desk*
P.S. Even though I do plan on using ARI in the future... I really don't want to fight with yet another layer of complexity.