Dan, Yes and I was agreeing with your proposal! However, I'm not convinced these are only workarounds, or that they should not be needed/used even if changes are made to the acc module.
For the wrapper routes suggestion, I only used t_relay as an example because you did. The larger point is that using routes to handle cases where many different parts of code have to perform the same action can greatly improve the size and readability of the config script and reduce the chances of some obscure path being missed when changes are made to that action in the future. It is a good policy in many programming languages; OpenSIPS is no different! As for using the acc_extra variables, I'm not sure how $acc_extra(some_var) is worse for "readability" than $var(some_var) or $avp(some_var). To me, what is much less readable is storing a value in one place only to have the script move it somewhere else later. It may not be obvious to anyone reading the script how or why that copy was occurring. Storing the value in acc_extra makes it immediately clear that the value will be used for accounting, in a way that was not even possible in the old accounting method. Ben Newlin On 4/11/19, 10:03 AM, "Devel on behalf of Dan Pascu" <[email protected] on behalf of [email protected]> wrote: On 10 Apr 2019, at 15:57, Ben Newlin wrote: > We have employed 2 methods to decrease the pain of setting all of these variables: > * For as many values as possible, we removed the script variable and use only the acc_extra variable. It is a r/w variable after all. This means that for these variables we do not have to worry about copying the value from an avp or dlg_val into acc_extra as it is just always there. > * We use wrapper functions extensively. In fact, we have had to patch OpenSIPS to increase the number of allowed routes. For Dan's example with t_relay, our approach would be to wrap the t_relay call in another route, which always sets the acc_extra before calling t_relay. Both of these are just workarounds that should not be needed. Holding values in $acc_extra only doesn't improve readability and t_relay is not the only call that can result in accounting being generated. If you only use t_relay, then wrapping it might work for you, but it doesn't scale well and makes reasoning about the code harder. The core idea of my proposal is to get notified when accounting is generated and given the opportunity to fill in the values for the extra accounting. -- Dan _______________________________________________ Devel mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
