Age | Commit message (Collapse) | Author |
|
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
|
|
* 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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Try to defer some checks until needed in case there is an early exit.
Change-Id: Ibc6b34c38a4f60ad4f9b67984b7d070a07257064
|
|
Change-Id: I150505db307249a962987e7b941bdd369bb91f35
|
|
|
|
|
|
|
|
The only caller of cdr_object_fn_table.process_party_b() explicitly does
the check before calling.
Change-Id: Ib0c53cdf5048227842846e0df9d2c19117c45618
|
|
Change-Id: I9f424f5282ca7d833592f958d95f1b2bafb549b0
|
|
Change-Id: Ib59d7d2f2a4a822754628f2c48a308d6791a6e6e
|
|
* Also some misc formatting in cdr.c.
Change-Id: Ied89a28802a662c37c43326a1aafdce596e0df4a
|
|
This API was not actively maintained, was not added to new modules
(such as res_pjsip), and there exist better alternatives to acquire the
same information, such as the ARI.
Change-Id: I4b2185a83aeb74798b4ad43ff8f89f971096aa83
|
|
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
|
|
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
|
|
ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.
Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename
This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled. This variable was only used in lock.c so it
is now initialized in that file only.
ASTERISK-26480 #close
Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
|
|
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
|
|
* We weren't properly subscribing to the channel and it's originator
on create.
* We weren't doing a publish_dial after calling ast_call on dial.
* We weren't calling depart_bridge when a channel left the dial bridge.
The first 2 issues were causing events to not be generated and the third
was actually causing channels to not get properly destroyed when hung up.
Together these 3 issues were causing the new
rest_apichannels/create_dial_bridge tests to fail.
As a result of the fixes, the cdr state machine had to be slightly
tweaked to allow bridge leave events without asserting and the tests
themselves had to be updated to account for the channels now cleaning
themselves up.
Change-Id: Ibf23abf5a62de76e82afb4461af5099c961b97d8
|
|
|
|
Scenario: Caller blonde transfer
Bob calls Charlie who answers.
Bob puts Charlie on hold and calls Alice.
Before Alice answers, Bob transfers Charlie to Alice.
Charlie's channel triggers an assert because he gets an "ANSWERED"
event even though he never dialed anything. With recent changes to dial
events, this is now a valid scenario so the assert needed to be removed.
ASTERISK-26103 #close
Change-Id: I2679b517b696e7952ab7fb29403df9140e7d1de2
|
|
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
|
|
Dial events up to this point have come in two flavors
* A Dial event with no status to indicate that dialing has begun
* A Dial event with a status to indicate that dialing has ended
With this change, Dial events have been expanded to also give
intermediate events, such as "RINGING", "PROCEEDING", and "PROGRESS".
This is especially useful for ARI dialing, as it gives the application
writer the opportunity to place a channel into an early bridge when
early media is detected.
AMI handles these in-progress dial events by sending a new event called
"DialState" that simply indicates that dial state has changed but has
not ended. ARI never distinguished between DialBegin and DialEnd, so no
change was made to the event itself.
Another change here relates to dial forwards. A forward-related event
was previously only sent when a channel was successfully able to forward
a call to a new channel. With this set of changes, if forwarding is
blocked, we send a Dial event with a forwarding destination but no
forwarding channel, since we were prevented from creating one. This is
again useful for ARI since application writers can now handle call
forward attempts from within their own application.
ASTERISK-25925 #close
Reported by Mark Michelson
Change-Id: I42cbec7730d84640a434d143a0d172a740995543
|
|
last one"
|
|
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
|
|
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
|
|
This patch adds the functions
ast_cdr_modifier_register()
ast_cdr_modifier_unregister()
That work much like ast_cdr_register() and ast_cdr_unregister().
Modules registered will be given a chance to modify (or to do whatever
they want) CDR fields just before they are passed to registered engines.
Thus, for instance, if a module change the "userfield" field of a CDR,
the modified value will be passed to every registered CDR backend for
logging.
ASTERISK-25479 #close
Change-Id: If11d8fd19ef89b1a66ecacf1201e10fcf86ccd56
|
|
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
|
|
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
|
|
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
|
|
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
remove passing the version in with the macro. Other facilities
than 'core show file version' make use of the file names, such as
setting a debug level only on a specific file. As such, the act of
registering source files with the Asterisk core still has use. The
macro rename now reflects the new macro purpose.
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Remove the "core show file version" CLI command. Without the file
version, it is no longer useful.
- Remove the ast_file_version_find function. The file version is no
longer tracked.
- Rename ast_register_file_version/ast_unregister_file_version to
ast_register_file/ast_unregister_file, respectively.
* main/manager: Remove value from the Version key of the ModuleCheck
Action. The actual key itself has not been removed, as doing so would
absolutely constitute a backwards incompatible change. However, since
the file version is no longer tracked, there is no need to attempt to
include it in the Version key.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action
- Removal of the "core show file version" CLI command
Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
|
|
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
........
Merged revisions 433269 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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
........
Merged revisions 427902 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427903 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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
........
Merged revisions 425736 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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
........
Merged revisions 424942 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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
........
Merged revisions 422770 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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
........
Merged revisions 422719 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422720 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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
........
Merged revisions 422716 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
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
|
|
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
|
|
* 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
|
|
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
|
|
* 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
|
|
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
|
|
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
|
|
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
|
|
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
|