Summary:	ASTERISK-21196: Refactor CDRs onto Stasis-Core to handle changes in bridging behavior
Reporter:	Matt Jordan (mjordan)	Labels:	Asterisk12
Date Opened:	2013-03-01 09:08:02.000-0600	Date Closed:	2013-06-16 22:09:03
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	CDR/General Core/Stasis
Versions:	12	Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Let me begin this issue by stating the obvious: *CDRs suck* Alas, we can't just remove them, so we have to do something about the Bridging API destroying the more complex logic that currently orchestrates CDRs. The Bridging API is replacing the current bridging code in features.c. This means the random snippets of code in the bridging loop that make CDRs "work" (for some definition of work, anyway) is going to get blown away. Reproducing the existing CDR code in the Bridging API would be like taking an old boat with a hole in the bottom, setting it on fire, taking a brand *new* boat, drilling a hole in the bottom of it, and kicking it out into the ocean. So rather than doing that, we should take the opportunity to refactor CDRs to use the channel/bridge state coming across the Stasis-Core message bus. This has a few obvious benefits: * CDR logic becomes completely separated from the rest of Asterisk. Special CDR logic doesn't pollute the rest of Asterisk, and can take advantage of being in it's own module that it may not be able to do elsewhere. * CDRs becomes easier to test. We can raise Stasis events in a unit test and have that drive the CDR logic to ensure that it handles common use cases. This issue is to track progress on this particular project. The following steps need to be done: # Create a specification on the wiki that defines the semantics of CDRs. Anything that falls outside of the use cases that the specification covers is undefined behavior and will not be supported. If you need something that the specification doesn't cover, go use CEL. # Write a test backend for CDRs that exposes produced CDR records to a unit test module. # Create unit tests for each of the use cases in the specification. Produce Stasis-Core events that map to those use cases and define the expected results from the CDR engine. # Refactor cdr.c to subscribe to Stasis-Core channel and bridge events. Use them to define a state machine for CDRs that tracks the events appropriately. # Remove explicit calls that modify CDR state. # Refactor existing CDR applications to either safely access CDR data in the core, or pass messages to the CDR data over Stasis-Core.
Comments:	By: Matt Jordan (mjordan) 2013-03-06 21:50:04.065-0600 Basic refactoring to use the config framework: https://reviewboard.asterisk.org/r/2372/ This makes loading/unloading atomic, and - if needed - easier to deprecate parameters.