asterisk

Commit Graph

Author	SHA1	Message	Date
Matt Jordan	4a58261694	git migration: Refactor the ASTERISK_FILE_VERSION macro 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	11 years ago
Mark Michelson	bd0bdf1e41	Fix some memory leaks. These memory leaks were found and fixed by John Hardin. I'm just committing them for him. ASTERISK-24736 #close Reported by Mark Michelson Review: https://reviewboard.asterisk.org/r/4389 ........ Merged revisions 431468 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431469 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	d4695774e7	Bridges: Fix feature interruption/unintended kick caused by external actions If a manager or CLI user attached a mixmonitor to a call running a dynamic bridge feature while in a bridge, the feature would be interrupted and the channel would be forcibly kicked out of the bridge (usually ending the call during a simple 1 to 1 call). This would also occur during any similar action that could set the unbridge soft hangup flag, so the fix for this was to remove unbridge from the soft hangup flags and make it a separate thing all together. ASTERISK-24027 #close Reported by: mjordan Review: https://reviewboard.asterisk.org/r/3900/ ........ Merged revisions 420934 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 420940 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420947 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	20a14e568f	bridges/bridge_native_rtp: Reconfigure bridge on removal of framehook This patch is a re-do of r414122. When r414122 was merged, a major problem with it was uncovered. UNBRIDGE soft hangup flags have a catastrophic effect on the pbx core if they leak out from the bridge layer: the channel gets hung up. With the number of threads involved in a blind transfer, and with the initial patch, it was likely that this would occur. This caused a large number of test failures This patch is nearly identical with the one proposed in r414122, save for the following changes: - We explicitly clear the UNBRIDGE flag when setting an after goto on a channel in a bridge - Defensively, if we encounter an UNBRIDGE flag in the pbx core, we handle it https://reviewboard.asterisk.org/r/3585/ ........ Merged revisions 415443 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415444 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	66c46fba24	CDRs: fix a variety of dial status problems, h/hangup handler creating CDRs 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	13 years ago
Matthew Jordan	cafc115896	A great big renaming patch This patch renames the bridging* files to bridge. This may seem pedantic and silly, but it fits better in line with current Asterisk naming conventions: channel is not "channeling" * monitor is not "monitoring" etc. A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is the act of using a bridge on a set of channels - and the API that fulfills that role is more than just the action. (closes issue ASTERISK-22130) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago

6 Commits (200493d9cced7f01182eb7820de9e2c3604a79cd)