asterisk

Commit Graph

Author	SHA1	Message	Date
George Joseph	0ad6d2b3cf	Merge "ari: Implement 'debug all' and request/response logging"	9 years ago
Richard Mudgett	e922979d49	stasis_bridge.c: Fix off-nominal stasis control ref leak. Change-Id: Ib17218343a6596832060180e19386da9df150ac8	9 years ago
George Joseph	6691606723	ari: Implement 'debug all' and request/response logging The 'ari set debug' command has been enhanced to accept 'all' as an application name. This allows dumping of all apps even if an app hasn't registered yet. To accomplish this, a new global_debug global variable was added to res/stasis/app.c and new APIs were added to set and query the value. 'ari set debug' now displays requests and responses as well as events. This required refactoring the existing debug code. * The implementation for 'ari set debug' was moved from stasis/cli.{c,h} to ari/cli.{c,h}, and stasis/cli.{c,h} were deleted. * In order to print the body of incoming requests even if a request failed, the consumption of the body was moved from the ari stubs to ast_ari_callback in res_ari.c and the moustache templates were then regenerated. The body is now passed to ast_ari_invoke and then on to the handlers. This results in code savings since that template was inserted multiple times into all the stubs. An additional change was made to the ao2_str_container implementation to add partial key searching and a sort function. The existing cli code assumed it was already there when it wasn't so the tab completion was never working. Change-Id: Ief936f747ce47f1fb14035fbe61152cf766406bf (cherry picked from commit `1d890874f3`)	9 years ago
Corey Farrell	a6e5bae3ef	Remove ASTERISK_REGISTER_FILE. 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	9 years ago
Richard Mudgett	6b1a632290	res_stasis: Handle re-enter stasis bridge with swap channel. We lose the fact that there is a swap channel if there is one. We currently wind up rejoining the stasis bridge as a normal join after the swap channel has already been kicked from the bridge. This patch preserves the swap channel so the AMI/ARI events can note that the channel joining the bridge is swapping with another channel. Another benefit to swaqpping in one operation is if there are any channels that get lonely (MOH, bridge playback, and bridge record channels). The lonely channels won't leave before the joining channel has a chance to come back in under stasis if the swap channel is the only reason the lonely channels are staying in the bridge. ASTERISK-25947 #close Reported by: Richard Mudgett ASTERISK-24649 Reported by: John Bigelow ASTERISK-24782 Reported by: John Bigelow Change-Id: If37ea508831d1fed6dbfac2f191c638fc0a850ee	10 years ago
Richard Mudgett	af114edb8b	stasis_bridge.c: Update stasis bridge push diagnostic messages. Change-Id: I195b14994c9dcccb9452491ca20a885d2a54605a	10 years ago
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
Scott Griepentrog	388d691f34	stasis transfer: fix stasis bridge push race part two When swapping a Local channel in place of one already in a bridge (to complete a bridge attended transfer), the channel that was swapped out can actually be hung up before the stasis bridge push callback executes on the independant transfer thread. This results in the stasis app loop dropping out and removing the control that has the the app name which the local replacement channel needs so it can re-enter stasis. To avoid this race condition a new push_peek callback has been added, and called from the ast_bridge_impart thread before it launches the independant thread that will complete the transfer. Now the stasis push_peek callback can copy the stasis app name before the swap channel can hang up. ASTERISK-24649 Review: https://reviewboard.asterisk.org/r/4382/ ........ Merged revisions 431450 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431451 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Scott Griepentrog	49f405fe4c	stasis transfer: fix a race condition on stasis bridge push After a bridge transfer completes where a local replacement channel is used, a stasis transfer message with the details of the transfer is sent. This is processed by stasis which then sets the stasis app name and replaced channel snapshot on the replacement channel. However, since a separate thread was already started to run stasis on the new replacement channel, a race was on to see if the message processing would be completed before the app name was needed, otherwise the channel would be hung up. This change moves the calls used to set the stasis app name and the replace snapshot to the bridge_stasis_push function callback from the bridge transfer logic, allowing the steps to be completed earlier and more deterministically, and the race elimianted. NOTE: the swap channel parameter to bridge_stasis_push (and thus all bridge push callbacks) must always be present when performing a swap with another channel. ASTERISK-24649 #close Reported by: John Bigelow Review: https://reviewboard.asterisk.org/r/4341/ ........ Merged revisions 430939 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430940 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	4bb556a847	Stasis: Fix StasisStart/End order and missing events This corrects several bugs that currently exist in the stasis application code. * After a masquerade, the resulting channels have channel topics that do not match their uniqueids ** Masquerades now swap channel topics appropriately * StasisStart and StasisEnd messages are leaked to observer applications due to being published on channel topics ** StasisStart and StasisEnd publishing is now properly restricted to controlling apps via app topics * Race conditions exist where StasisStart and StasisEnd messages due to a masquerade may be received out of order due to being published on different topics ** These messages are now published directly on the app topic so this is now a non-issue * StasisEnds are sometimes missing when sent due to masquerades and bridge swaps into and out of Stasis() This was due to StasisEnd processing adjusting message-sent flags after Stasis() had already exited and Stasis() had been re-entered This was corrected by adjusting these flags prior to sending the message while the initial Stasis() application was still shutting down Review: https://reviewboard.asterisk.org/r/4213/ ASTERISK-24537 #close Reported by: Matt DiMeo ........ Merged revisions 429061 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 429062 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429063 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	74e706878b	Stasis: Fix StasisEnd message ordering This change corrects message ordering in cases where a channel-related message can be received after a Stasis/ARI application has received the StasisEnd message. The StasisEnd message was being passed to applications directly without waiting for the channel topic to empty. As a result of this fix, other bugs were also identified and fixed: * StasisStart messages were also being sent directly to apps and are now routed through the stasis message bus properly * Masquerade monitor datastores were being removed at the incorrect time in some cases and were causing StasisEnd messages to not be sent * General refactoring where necessary for the above * Unsubscription on StasisEnd timing changes to prevent additional messages from following the StasisEnd when they shouldn't A channel sanitization function pointer was added to reduce processing and AO2 lookups. Review: https://reviewboard.asterisk.org/r/4163/ ASTERISK-24501 #close Reported by: Matt Jordan ........ Merged revisions 427788 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427789 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427790 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	df5dbbd878	res_stasis: Don't play MoH to channels by default when added to holding bridges When ARI manipulates a bridge, it generally doesn't care what the mixing technology is. Operations on a bridge initiated through ARI should perform their action in generally the same way, regardless of the bridge's mixing technology. While the mixing technology may determine how media flows to channels, the actual operations on a bridge themselves should be the same. Currently, this isn't the case with holding bridges. When a channel joins without a role, MoH is started on that channel automatically. Subsequent bridge operations that would stop MoH would fail (as there is no Announcer channel playing MoH to the bridge). Starting MoH on the bridge will also create two MoH streams: one from the MoH being played on the participant channel, and one from the announcer channel. From the perspective of ARI users, this is counter-intuitive - I would not expect MoH to be started for me. The mixing technology determines how media is shared between participants, not the application experience. This patch does the following: * The Stasis bridge class now inspects channels as they are going into a bridge. If the bridge has a holding capability, and the channel has no roles, we give it a participant role and mark the default behaviour to have no entertainment. This allows addChannel operations to continue to set a participant role with an entertainment option if it felt like it (or could do it). * The music on hold channel is now Stasis approved (tm) Review: https://reviewboard.asterisk.org/r/3929/ ASTERISK-24264 #close Reported by: Samuel Galarneau Tested by: Samuel Galarneau ........ Merged revisions 422503 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 422504 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422505 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Jonathan Rose	33835e17a0	ARI: Fix a crash caused by hanging during playback to a channel in a bridge ASTERISK-24147 #close Reported by: Edvin Vidmar Review: https://reviewboard.asterisk.org/r/3908/ ........ Merged revisions 421879 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 421880 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421881 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	6f735288b0	Stasis: Allow internal channels directly into bridges The patch to catch channels being shoehorned into Stasis() via external mechanisms also happens to catch Announcer and Recorder channels because they aren't known to be stasis-controlled channels in the usual sense. This marks those channels as Stasis()-internal channels and allows them directly into bridges. Review: https://reviewboard.asterisk.org/r/3903/ ........ Merged revisions 420795 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 420796 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420797 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	0ac7f96057	Stasis: Convey transfer information to applications This fixes a class of issues where Stasis applications were not made aware that their channels were being manipulated or replaced by external entitiessuch as transfers, AMI commands, or dialplan applications such as Bridge(). Inconsistent information such as StasisEnd events with unknown channels as a result of masquerades has also been corrected. To accomplish these fixes, several new fields were added to blind and attended transfer messages as well as StasisStart and BridgeAttendedTransfer Stasis events. ASTERISK-23941 #close Review: https://reviewboard.asterisk.org/r/3865/ Review: https://reviewboard.asterisk.org/r/3857/ Review: https://reviewboard.asterisk.org/r/3852/ Review: https://reviewboard.asterisk.org/r/3816/ Review: https://reviewboard.asterisk.org/r/3731/ Review: https://reviewboard.asterisk.org/r/3729/ Review: https://reviewboard.asterisk.org/r/3728/ ........ Merged revisions 420325 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420338 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	f962448eee	ARI: Make mixing bridges propagate linkedids and accountcodes. * Create a Stasis bridge sub-class to propagate linkedids and accountcodes. * Fixed the basic bridge sub-class to update peeraccount codes when the number of channels in the bridge drops back down to two parties. * Refactored ast_bridge_channel_update_accountcodes() to handle channels joining/leaving the bridge. * Fixed the basic bridge sub-class to not call the base bridge class pull method twice. AFS-105 #close ASTERISK-23852 #close Reported by: Richard Mudgett Review: https://reviewboard.asterisk.org/r/3720/ ........ Merged revisions 418225 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418226 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago

16 Commits (dac5e3a0df5d76967ef581984e79e0d5543c6a89)