summaryrefslogtreecommitdiff
path: root/main/cdr.c
AgeCommit message (Collapse)Author
2018-01-02cdr: submit: fix logic of test for batch modeTzafrir Cohen
ASTERISK-27539 #close Change-Id: I33cdf329d2bb4486dcae975c450f6aae94c515f7
2017-12-25cdr: Missing NULL check and unlock.Corey Farrell
* handle_dial_message: Missing a check for NULL peer. * ast_cdr_register: Missing unlock on allocation failure. ast_cdr_register is fixed by reordering so the new structure is allocated and initialized before locking the list. Change-Id: I5799b99270d1a7a716a555c31ac85f4b00ce8686
2017-12-18Merge "aco: Minimize use of regex." into 13Jenkins2
2017-12-15cdr: Minor optimizations.Corey Farrell
* bridge_candidate_process: remove SCOPED_AO2LOCK and return value. * handle_standard_bridge_enter_message: replace recursive call with goto statement. ASTERISK-24297 Change-Id: Id2eaa0822fb8dc799f63422bb3aa89de9d4ee2a2
2017-12-15aco: Minimize use of regex.Corey Farrell
Remove nearly all use of regex from ACO users. Still remaining: * app_confbridge has a legitamate use of option name regex. * ast_sorcery_object_fields_register is implemented with regex, all callers use simple prefix based regex. I haven't decided the best way to fix this in both 13/15 and master. Change-Id: Ib5ed478218d8a661ace4d2eaaea98b59a897974b
2017-11-08AST-2017-010: Fix cdr_object_update_party_b_userfield_cb() buf overrunRichard Mudgett
cdr_object_update_party_b_userfield_cb() could overrun the fixed buffer if the supplied string is too long. The long string could be supplied by external means using the CDR(userfield) function. This may seem reminiscent to AST-2017-001 (ASTERISK_26897) and it is. The earlier patch fixed the buffer overrun for Party A's userfield while this patch fixes the same thing for Party B's userfield. ASTERISK-27337 Change-Id: I0fa767f65ecec7e676ca465306ff9e0edbf3b652
2017-10-16cdr.c: Rename the Party A CDR container.Richard Mudgett
* Rename the Party A CDR container from active_cdrs_by_channel to active_cdrs_master. * Renamed the support functions associated with active_cdrs_master appropriately. ASTERISK-27335 Change-Id: I6104bb3edc3a0b7243ce502e45e8832b0cff14f7
2017-10-16cdr.c: Add container to key off of Party B channel names.Richard Mudgett
The CDR performance gets worse the further it gets behind in processing stasis messages. One of the reasons is because of a n*m loop used when processing Party B information. * Added a new CDR container that is keyed to Party B so we don't need such a large loop when processing Party B information. NOTE: To reduce the size of the patch I deferred to another patch the renaming of the Party A active_cdrs_by_channel container to active_cdrs_master and renaming the container's hash and cmp functions appropriately. ASTERISK-27335 Change-Id: I0bf66e8868f8adaa4b5dcf9e682e34951c350249
2017-10-12cdr.c: Eliminated many calls to ao2_global_obj_ref().Richard Mudgett
The CDR performance gets worse the further it gets behind in processing stasis messages. One of the reasons is we were getting the global config to determine if we needed to log a debugging message. * Many calls to ao2_global_obj_ref() were just so we could determine if debug mode is enabled. Made a global flag to check instead. * Eliminated many RAII_VAR() usages associated with the remaining ao2_global_obj_ref() calls. * Added missing NULL checks for the returned ao2_global_obj_ref() value. ASTERISK-27335 Change-Id: Iceaad93172862f610cad0188956634187bfcc7cd
2017-10-12cdr.c: Defer getting ao2_global_obj_ref() until needed.Richard Mudgett
The CDR performance gets worse the further it gets behind in processing stasis messages. One of the reasons is we were getting the global config even if we didn't need it. * Most uses of the global config were only needed on off nominal code paths so it makes sense to not get it until absolutely needed. ASTERISK-27335 Change-Id: I00c63b7ec233e5bfffd5d976f05568613d3c2365
2017-10-12cdr.c: Set stringfields only if they are different.Richard Mudgett
The CDR performance gets worse the further it gets behind in processing stasis messages. One of the reasons is we were repeatedly setting string fields to potentially the same string in base_process_party_a(). Setting a string field involves allocating room for the new string out of a memory pool which may have to allocate even more memory. * Check to see if the string field is already set to the desired string. ASTERISK-27335 Change-Id: I3ccb7e23f1488417e08cafe477755033eed65a7c
2017-10-12cdr.c: Fix setting dnid, callingsubaddr, and calledsubaddrRichard Mudgett
The string comparisons for setting these CDR variables was inverted. We were repeatedly setting these CDR variables only if the channel snapshots had the same value. ASTERISK-27335 Change-Id: I9482073524411e7ea6c03805b16de200cb1669ea
2017-10-11cdr.c: Defer misc checks.Richard Mudgett
Try to defer some checks until needed in case there is an early exit. Change-Id: Ibc6b34c38a4f60ad4f9b67984b7d070a07257064
2017-10-10cdr.c: Eliminated simple RAII_VAR usages.Richard Mudgett
Change-Id: I150505db307249a962987e7b941bdd369bb91f35
2017-10-09Merge "cdr.h: Fix doxygen comments." into 13Joshua Colp
2017-10-09Merge "cdr.c: Replace redundant check with an ast_assert()" into 13Jenkins2
2017-10-09Merge "cdr.c: Use current ao2 flag names" into 13Jenkins2
2017-10-09cdr.c: Replace redundant check with an ast_assert()Richard Mudgett
The only caller of cdr_object_fn_table.process_party_b() explicitly does the check before calling. Change-Id: Ib0c53cdf5048227842846e0df9d2c19117c45618
2017-10-09cdr.c: Replace inlined code with ao2_t_replace()Richard Mudgett
Change-Id: I9f424f5282ca7d833592f958d95f1b2bafb549b0
2017-10-09cdr.c: Use current ao2 flag namesRichard Mudgett
Change-Id: Ib59d7d2f2a4a822754628f2c48a308d6791a6e6e
2017-10-09cdr.h: Fix doxygen comments.Richard Mudgett
* Also some misc formatting in cdr.c. Change-Id: Ied89a28802a662c37c43326a1aafdce596e0df4a
2017-04-04CDR: Protect from data overflow in ast_cdr_setuserfield.Corey Farrell
ast_cdr_setuserfield wrote to a fixed length field using strcpy. This could result in a buffer overrun when called from chan_sip or func_cdr. This patch adds a maximum bytes written to the field by using ast_copy_string instead. ASTERISK-26897 #close patches: 0001-CDR-Protect-from-data-overflow-in-ast_cdr_setuserfie.patch submitted by Corey Farrell (license #5909) Change-Id: Ib23ca77e9b9e2803a450e1206af45df2d2fdf65c
2017-03-22cdr: Allow setting of user field from 'h' extensionSebastian Gutierrez
The CDR code previously did not allow the user field to be set from the 'h' extension in the dialplan. This change removes that limitation and allows it to be set. ASTERISK-26818 Change-Id: I0fed8a79b5e408bac4e30542b8f33a61c5ed9aa6
2016-10-18CDR: Alter destruction pattern for CDR chains.Mark Michelson
CDRs form chains. When the root of the chain is destroyed, it then unreferences the next CDR in the chain. That CDR is destroyed, and it then unreferences the next CDR in the chain. This repeats until the end of the chain is reached. While this typically does not cause any sort of problems, it is possible in strange scenarios for the CDR chain to grow way longer than expected. In such a scenario, the destruction pattern can result in a stack overflow. This patch fixes the problem by switching from a recursive pattern to an iterative pattern for destruction. When the root CDR is destroyed, it is responsible for iterating over the rest of the CDRs and unreferencing each one. Other CDRs in the chain, since they are not the root, will simply destroy themselves and be done. This causes the stack depth not to increase. ASTERISK-26421 #close Reported by Andrew Nagy Change-Id: I3ca90c2b8051f3b7ead2e0e43f60d2c18fb204b8
2016-06-07stasis: Add setting subscription congestion levels.Richard Mudgett
Stasis subscriptions and message routers create taskprocessors to process the event messages. API calls are needed to be able to set the congestion levels of these taskprocessors for selected subscriptions and message routers. * Updated CDR, CEL, and manager's stasis subscription congestion levels based upon stress testing. Increased the congestion levels to reduce the potential for bursty call setup/teardown activity from triggering the taskprocessor overload alert. CDRs in particular need an extra high congestion level because they can take awhile to process the stasis messages. ASTERISK-26088 Reported by: Richard Mudgett Change-Id: Id0a716394b4eee746dd158acc63d703902450244
2016-01-02main/cdr: Allow setting properties on a finalized CDR if it is the last oneMatt Jordan
Prior to this patch, we explicitly disallowed setting any properties on a finalized CDR. This seemed like a good idea at the time; in practice, it was more restrictive. There are weird and strange scenarios where setting a property on a finalized CDR is definitely wrong. For example, we may Fork a CDR, finalizing the previous one, then change a property. In said case, the old CDR is supposed to now be 'immutable' (so to speak), and should not be updated. From the perspective of the code, a forked CDR that is finalized is just finalized. Hence why we decided these should not be updated. In practice, it is much more common to want to set a property on a CDR in the h extension or in a hangup handler. Disallowing a common scenario to make an esoteric behaviour work isn't good. This patch fixes this by allowing callers to set a property IF we are the last CDR in the chain. This preserves the finalized CDR if it was forked, while allowing the more common case to function. ASTERISK-25458 #close Change-Id: Icf3553c607b9f561152a41e6d8381d594ccdf4b9
2016-01-02main/cdr: Set the end time on a CDR if endbeforehexten is YesMatt Jordan
Prior to this patch, the CDR engine attempted to set the end time on a CDR that was executing hangup logic and with endbeforehexten set to Yes by calling a function that inspects the properties on the Party A snapshot to determine if we are ready to set the end time. That always failed. This is because a Party A snapshot is not updated for CDRs that are executing hangup logic with endbeforehexten=Yes. Instead of calling a function that looks at the Party A snapshot, we just simply set the end time on the CDR. This is safe to call multiple times, and is safe to call at this point as we know that (a) we are executing hangup logic, and (b) we are supposed to set the end time at this point. ASTERISK-25458 Change-Id: I0c27b493861f9c13c43addbbb21257f79047a3b3
2015-06-15main/cdr: Carry over the disable flag when 'disable all' is specifiedmjordan
The CDR_PROP function (as well as the NoCDR application) set the 'disable all' flag (AST_CDR_FLAG_DISABLE_ALL) on the current CDR. This flag is supposed to be applied to all CDRs that are currently in the chain, as well as all CDRs that may be created in the future. Currently, however, the flag is only applied to the existing CDRs in the chain; new CDRs do not receive the 'disable all' flag. In particular, this affects parallel dials, which generate new CDRs for each pair of channels in the dial attempt. This patch carries over the 'disable all' flag when it is specified on a CDR and a new CDR is generated for the chain. ASTERISK-24344 #close Change-Id: I91a0f0031e4d147bdf8a68ecd08304d506fb6a0e
2015-06-13main/cdr: Copy context/exten on chained CDRs for parallel dials in subroutinesMatt Jordan
When a parallel dial occurs, a new CDR will be created for each dial attempt that is made. In most circumstances, the act of creating each CDR in the chain will include a step that updates the Party A snapshot, which causes the context/extension of the Party A to be copied onto the CDR object. However, when the Party A is in a subroutine, we explicitly do *not* copy the context/extension onto the CDR. This prevents the Macro or GoSub routine name from blowing away the context/extension that the channel was originally executing in. For the original CDR, this is not a problem: the original CDR already recorded the last known 'good' state of the channel just prior to it going into the subroutine. However, for newly generated CDRs in a chain, there is no context/extension set on them. Since we are in a subroutine, we will never set the Party A's context/extension on the CDR, and we end up with a CDR with no destination recorded on it. This patch updates the creation of a chained CDR such that it copies over the original CDR's context/extension. This is the last known "good" state of the CDR, and is a reasonable starting point for the newly generated CDR. In the case where we are not in a subroutine, subsequent code will update the location of the CDR from the Party A information; in the case where we are in a subroutine, the context/extension on the original CDR is the correct information. ASTERISK-24443 #close Change-Id: I6a3ef0d6e458d3b9b30572feaec70f2964f3bc2a
2015-05-15cdr: Fix 'core show channel' CDR variable truncation.snuffy
When the new Bridging API was implemented, the workspace variable changed to a malloc'd string, causing sizeof() to always be 8 (char). Revert back to stored on stack string for workspace. ASTERISK-25090 #close Change-Id: I51e610ae87371df771ce7693a955510efb90f8f7
2015-03-22Fix compilations errors on 64-bit OpenBSD systemsMatthew Jordan
In versiong 5.5, OpenBSD went to 64-bit time values. This requires a cast to (long) when printing members of certain time structs. Review: https://reviewboard.asterisk.org/r/4507 ASTERISK-24879 #close Reported by: snuffy Tested by: snuffy patches: openbsd-time64.diff uploaded by snuffy (License 5024) ........ Merged revisions 433268 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433269 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14Documentation: Revise explanation of cdr.conf option 'Unanswered'Jonathan Rose
ASTERISK-24279 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/4109/ ........ Merged revisions 427901 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427902 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-10-16main/cdr: Use 'time' when rescheduling batched CDRs as opposed to 'size'Matthew Jordan
When refactoring CDRs to use the configuration framework, a 'whoops' was introduced where the CDR batch size was used when rescheduling a batch, as opposed to the time duration. This patch corrects that obvious mistake. ASTERISK-24426 #close Reported by: Shane Blaser ........ Merged revisions 425735 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425736 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-10-09cdr.c: Make turning on CDR debug a one step process instead of two.Richard Mudgett
Now "cdr set debug on" doesn't also require "core set verbose 1" to see CDR debug output. ........ Merged revisions 424941 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-09-06main/cdr: Copy over location information during a forkMatthew Jordan
When a CDR is forked, a new CDR is created and appended to the CDR chain for the Party A. The forked CDR starts life off as a clone of the last non-finalized for the particular Party A. In the past, merely copying over the snapshots for Party A/Party B would be sufficient. However, as the CDRs now contain cached information from Party A - specifically application/data, context, and extension - we need to copy that over during a fork as well. Huzzah for unit tests catching this when the context/extension were derived from a cached value on the CDR instead of on Party A. ........ Merged revisions 422769 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-09-05main/cdrs: Preserve context/extension when executing a Macro or GoSubMatthew Jordan
The context/extension in a CDR is generally considered the destination of a call. When looking at a 2-party call CDR, users will typically be presented with the following: context exten channel dest_channel app data default 1000 SIP/8675309 SIP/1000 Dial SIP/1000,,20 However, if the Dial actually takes place in a Macro, the current behaviour in 12 will result in the following CDR: context exten channel dest_channel app data macro-dial s SIP/8675309 SIP/1000 Dial SIP/1000,,20 The same is true of a GoSub: context exten channel dest_channel app data subs dial_stuff SIP/8675309 SIP/1000 Dial SIP/1000,,20 This generally makes the context/exten fields less than useful. It isn't hard to preserve these values in the CDR state machine; however, we need to have something that informs us when a channel is executing a subroutine. Prior to this patch, there isn't anything that does this. This patch solves this problem by adding a new channel flag, AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a Macro or a GoSub. The CDR engine looks for this value when updating a Party A snapshot; if the flag is present, we don't override the context/exten on the main CDR object. In a funny quirk, executing a hangup handler must *not* abide by this logic, as the endbeforehexten logic assumes that the user wants to see data that occurs in hangup logic, which includes those subroutines. Since those execute outside of a typical Dial operation (and will typically have their own dedicated CDR anyway), this is unlikely to cause any heartburn. Review: https://reviewboard.asterisk.org/r/3962/ ASTERISK-24254 #close Reported by: tm1000, Tony Lewis Tested by: Tony Lewis ........ Merged revisions 422718 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422719 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-09-05main/cdr: Fix crash/memory consumption in CDRs in multi-party bridge scenariosMatthew Jordan
This patch fixes an issue where CDRs would get stuck generating an infinite number of CDRs, eventually crashing Asterisk (and consuming a lot of memory along the way). When a channel enters into a multi-party bridge, the CDR engine creates mappings of each participant to each other participant, picking the 'A' party as it goes. So, if we have four channels in a multi-party bridge (Alice, Bob, Charlie, Denise), we would have something like: Alice => Bob Alice => Charlie Alice => Denise Bob => Charlie Bob => Denise Charlie => Denise This works fine when participants enter the bridge a single time. When a participant leaves a bridge, the CDRs for that channel are transitioned to a finalized state. The bug occurs if Bob rejoins. When the CDR engine creates mappings between the channels, it walks through all the participants currently in the bridge, and realizes that no one in the bridge can create a CDR with the channel (Bob). As such it creates a new CDR for the candidate and appends it to that candidate's chain. Unfortunately, on this particular code path, it doesn't stop traversing the candidate's chain. Since we just added ourselves to the chain, this causes the loop to keep going, constantly adding new CDRs. This patch makes it so the engine bails when it creates a CDR match in this case. Review: https://reviewboard.asterisk.org/r/3964/ ASTERISK-24241 #close Reported by: Deepak Singh Rawat Tested by: Deepak Singh Rawat ASTERISK-24208 Reported by: Frankie Chin ........ Merged revisions 422715 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422716 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-06Stasis: Allow message types to be blockedKinsey Moore
This introduces stasis.conf and a mechanism to prevent certain message types from being published. Internally, this works by preventing the chosen message types from being created which ensures that those message types can never be published. This patch also adjusts message publishers such that message payloads are not created if the related message type is not available. ASTERISK-23943 #close Review: https://reviewboard.asterisk.org/r/3823/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-05-09Allow Asterisk to compile under GCC 4.10Kinsey Moore
This resolves a large number of compiler warnings from GCC 4.10 which cause the build to fail under dev mode. The vast majority are signed/unsigned mismatches in printf-style format strings. ........ Merged revisions 413586 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 413587 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 413588 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-04-15Remove unused RAII_VAR() declarations.Richard Mudgett
* Remove unused RAII_VAR() declarations. The compiler cannot catch these because the cleanup function "references" the unused variable. Some actually allocated and released resources that were never used. * Fixed some whitespace issues in stasis_bridges.c. ........ Merged revisions 412399 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-18cdr: Add asserts for when we don't know about a CDR for a channelMatthew Jordan
In the CDR core, every channel should either be filtered out (due to being an 'internal' channel used as an implementation detail, such as playing media back into a bridge) or it should get a CDR. Even if that CDR ends up being discarded, we still give the channel a CDR in case we end up needing it. If we hit a situation where a channel does not have a CDR, we should blow up in -dev-mode. Asserts are appropriate for that. This patch adds those asserts, as they would have quickly caught the error fixed by r410814. ........ Merged revisions 410861 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410862 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-13cdr.c: Add missing aow_unlock(cdr) in off nominal path of handle_dial_message().Richard Mudgett
* Trivial common code hoisting in handle_bridge_leave_message(). * Some whitespace fixing. ........ Merged revisions 410541 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410542 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-02-03cdrs: Check for applications to lock onto during dial begin handlingMatthew Jordan
This patch brings CDR processing further in line with r407085. During some dial operations, the application would not be locked to the Dial application and would instead continue to show the previously known application. In particular, this would occur when a Parked call would time out. This was due to a previous snapshot already locking the application to Park - processing this in a Dial Begin allows the Dial application to reassert its rightful place. (CDRs. Ugh.) But hooray for the Parked Call tests for catching this in the Asterisk Test Suite. ........ Merged revisions 407166 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-01-31CDRs: fix a variety of dial status problems, h/hangup handler creating CDRsMatthew Jordan
This patch fixes a number of small-ish problems that were noticed when witnessing the records that the FreePBX dialplan produces: (1) Mid-call events (as well as privacy options) have the ability to change the overall state of the Dial operation after the called party answers. This means that publishing the DialEnd event when the called party is premature; we have to wait for the execution of these subroutines to complete before we can signal the overall status of the DialEnd. This patch moves that publication and adds handlers for the mid-call events. (2) The AST_FLAG_OUTGOING channel flag is cleared if an after bridge goto datastore is detected. This flag was preventing CDRs from being recorded for all outbound channels that had a 'continue' option enabled on them by the Dial application. (3) The CDR engine now locks the 'Dial' application as being the CDR application if it detects that the current CDR has entered that app. This is similar to the logic that is done for Parking. In general, if we entered into Dial, then we want that CDR to record the application as such - this prevents pre-dial handlers, mid-call handlers, and other shenaniganry from changing the application value. (4) The CDR engine now checks for the AST_SOFTHANGUP_HANGUP_EXEC in more places to determine if the channel is in hangup logic or dead. In either case, we don't want to record changes in the channel. (5) The default option for "endbeforehexten" has been changed to "yes". In general, you don't want to see CDRs in the 'h' exten or in hangup logic. Since the semantics of that option changed in 12, it made sense to update the default value as well. (6) Finally, because we now have the ability to synchronize on the messages published to the CDR topic, on shutdown the CDR engine will now synchronize to the messages currently in flight. This helps to ensure that all in-flight CDRs are written before shutting down. (closes issue ASTERISK-23164) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3154 ........ Merged revisions 407084 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407085 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-01-12CDRs: Synchronize dialplan applications that manipulate CDRs with the engineMatthew Jordan
In https://reviewboard.asterisk.org/r/3057/, applications and functions that manipulate CDRs were made to interact over Stasis. This was done to synchronize manipulations of CDRs from the dialplan with the updates the engine itself receives over the message bus. This change rested on a faulty premise: that messages published to the CDR topic or to a topic that forwards to the CDR topic are synchronized with the messages handled by the CDR topic subscription in the CDR engine. This is not the case. There is no ordering guaranteed for two messages published to the same topic; ordering is only guaranteed if a message is published to the same subscriber. Stasis was modified in r405311 to allow a publisher to synchronize on the subscriber. This patch uses that API to synchronize the CDR publishers with the CDR engine message router, which maintains the overall topic subscription. (closes issue ASTERISK-22884) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3099/ ........ Merged revisions 405312 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-19app_cdr,app_forkcdr,func_cdr: Synchronize with engine when manipulating stateMatthew Jordan
When doing the rework of the CDR engine that pushed all of the logic into cdr.c and made it respond to changes in channel state over Stasis, we knew that accessing the CDR engine from the dialplan would be "slightly" non-deterministic. Dialplan threads would be accessing CDRs while Stasis threads would be updating the state of said CDRs - whereas in the past, everything happened on the dialplan threads. Tests have shown that "slightly" is in reality "very". This patch synchronizes things by making the dialplan applications/functions that manipulate CDRs do so over Stasis. ForkCDR, NoCDR, ResetCDR, CDR, and CDR_PROP now all use Stasis to send their requests over to the CDR engine, and synchronize on the channel Stasis topic via a subscription so that they return their values/control to the dialplan at the appropriate time. While going through this, the following changes were also made: * DISA, which can reset the CDR when a user successfully authenticates, now just uses the ResetCDR app to do this. This prevents having to duplicate the same Stasis synchronization logic in that application. * Answer no longer disables CDRs. It actually didn't work anyway - calling DISABLE on the channel's CDR doesn't stop the CDR from getting the Answer time - it just kills all CDRs on that channel, which isn't what the caller would intend. (closes issue ASTERISK-22884) (closes issue ASTERISK-22886) Review: https://reviewboard.asterisk.org/r/3057/ ........ Merged revisions 404294 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-27Filter out internal channels from dial message handlingMatthew Jordan
Surrogate channels would pop up from time to time in dial message handling. This would cause a WARNING message to appear, indicating that the Surrogate channel had no CDR. This patch filters out those channels that have the internal implementation flag set, such that the WARNING message isn't displayed. ........ Merged revisions 402090 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-27Prevent CDR backends from unregistering while billing data is in flightMatthew Jordan
This patch makes it so that CDR backends cannot be unregistered while active CDR records exist. This helps to prevent billing data from being lost during restarts and shutdowns. Review: https://reviewboard.asterisk.org/r/2880/ ........ Merged revisions 402081 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-03When serializing CDR variables (like for "core show channels") don't output ↵Joshua Colp
an error if CDRs aren't enabled. ........ Merged revisions 400442 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400443 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-02Only create Stasis subscriptions when enabledMatthew Jordan
Subscribing to Stasis isn't free. As such, this patch makes AMI, CDR, and CEL - the "big 3" - only subscribe when enabled. Toggling their availability via a .conf file will unsubscribe/subscribe as appropriate. Review: https://reviewboard.asterisk.org/r/2888/ ........ Merged revisions 400312 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400313 65c4cc65-6c06-0410-ace0-fbb531ad65f3
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-29 04:51:54 +0000