| Summary: | ASTERISK-22886: CDRs: Applications that manipulate CDRs are out of step with engine, creating unpredictable results | ||
| Reporter: | Matt Jordan (mjordan) | Labels: | |
| Date Opened: | 2013-11-21 17:24:42.000-0600 | Date Closed: | 2013-12-18 18:54:01.000-0600 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | CDR/General |
| Versions: | 12.0.0-beta1 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | CDRs are now generated by consuming messages from the Stasis message bus. This has had the advantage of decoupling CDR code from the Asterisk core, making CDRs more predictable and maintainable.
One downside however has been that the channels producing state for the CDRs are now operating on different threads than the actual maintenance of the CDR records. This means that dialplan applications that manipulate CDRs, such as ForkCDR, ResetCDR, and NoCDR (as well CDR_PROPSET) manipulate CDR data that may be 'stale', in that updates to the records are currently in flight. From a testing perspective, this has made verifying ForkCDR in particular problematic. From a longer term perspective, the potential exists for the wrong CDR record to get disabled, enabled, forked, etc. In general, these applications should not be directly manipulating the CDRs. They should instead be raising a message on the Stasis message bus that the CDR engine interprets when the message is serviced. More strangely, we could actually use the act of entering into the dialplan application as a mechanism to trigger the application. That is, the entry point of app_forkcdr is a NoOp that simply returns success, but the module itself has registered a Stasis message handler that looks at all channel messages and, if it sees an application message that matches ForkCDR, it handles it and directly manipulates the CDR engine. That would be odd, but would work as well as generating an additional message for the bus. | ||
| Comments: | |||