106 Commits (16)

Author	SHA1	Message	Date
Alexander Traud	14736ae6d4	res: Fix for Doxygen. ... These are the remaining issues found in /res. ASTERISK-29761 Change-Id: I572e6019c422780dde5ce8448b6c85c77af6046d	4 years ago
Josh Soref	923c836886	res: Spelling fixes ... Correct typos of the following word families: identifying structures actcount initializer attributes statement enough locking declaration userevent provides unregister session execute searches verification suppressed prepared passwords recipients event because brief unidentified redundancy character the module reload operation backslashes accurate incorrect collision initializing instance interpreted buddies omitted manually requires queries generator scheduler configuration has owner resource performed masquerade apparently routable ASTERISK-29714 Change-Id: I88485116d2c59b776aa2e1f8b4ce8239a21decda	4 years ago
Michal Hajek	f7285140b4	res_stasis.c: Add compare function for bridges moh container ... Sometimes not play MOH on bridge. ASTERISK-29081 Reported-by: Michal Hajek <michal.hajek@daktela.com> Change-Id: I760c73e0c9be1d340303b5d1c18a00c4759e8232	5 years ago
Sungtae Kim	af339d0adb	res_stasis.c: Added video_single option for bridge creation ... Currently, it was not possible to create bridge with video_mode single. This made hard to put the bridge in a vidoe_single mode. So, added video_single option for Bridge creation using the ARI. This allows create a bridge with video_mode single. ASTERISK-29055 Change-Id: I43e720e5c83fc75fafe10fe22808ae7f055da2ae	5 years ago
sungtae kim	15a3318f1f	stasis_bridge.c: Fixed wrong video_mode shown ... Currently, if the bridge has created by the ARI, the video_mode parameter was not shown in the BridgeCreated event correctly. Fixed it and added video_mode shown in the 'bridge show <bridge id>' cli. ASTERISK-28987 Change-Id: I8c205126724e34c2bdab9380f523eb62478e4295	5 years ago
Kevin Harwell	dc9875815c	res_stasis: trigger cleanup after update ... The cleanup code in stasis shuts down applications if they are in a deactivated state, and no longer have explicit subscriptions. When registering an app the cleanup code was running before calling 'update'. When it should be executed after 'update' since a call to register may re-activate the app. We don't want it to shutdown before the 'update' otherwise the app won't be re-activated, or registered. This patch makes it so the cleanup code is executed post 'update'. ASTERISK-28679 #close Change-Id: I8f2c0b17e33bb8128441567b97fd4c7bf74a327b	5 years ago
George Joseph	40c49ec64f	stasis: Don't hold app_registry and session locks unnecessarily ... resource_events:stasis_app_message_handler() was locking the session, then attempting to determine if the app had debug enabled which locked the app_registry container. res_stasis:__stasis_app_register was locking the app_registry container then calling app_update which caused app_handler (which locks the session) to run. The result was a deadlock. * Updated resource_events:stasis_app_message_handler() to determine if debug was set (which locks the app_registry) before obtaining the session lock. * Updated res_stasis:__stasis_app_register to release the app_registry container lock before calling app_update (which locks the sesison). ASTERISK-28423 Reported by Ross Beer Change-Id: I58c69d08cb372852a63933608e4d6c3e456247b4	6 years ago
sungtae kim	6d455487d9	res/res_ari: Added timestamp as a requirement for all ARI events ... Changed to requirement to having timestamp for all of ARI events. The below ARI events were changed to having timestamp. PlaybackStarted, PlaybackContinuing, PlaybackFinished, RecordingStarted, RecordingFinished, RecordingFailed, ApplicationReplaced, ApplicationMoveFailed ASTERISK-28326 Change-Id: I382c2fef58f5fe107e1074869a6d05310accb41f	6 years ago
sungtae kim	9e36707dca	res/res_stasis: Fixed wrong StasisEnd timestamp ... Because StasisEnd's timestamp created it's own timestamp, it makes wrong timestamp, compare to other channel event(ChannelDestroyed). Fixed to getting a timestamp from the Channel's timestamp. ASTERISK-28333 Change-Id: I5eb8380fc472f1100535a6bc4983c64767026116	6 years ago
Ben Ford	50a4b618fc	res_stasis: Add ability to switch applications. ... Added the ability to move between Stasis applications within Stasis. This can be done by calling 'move' in an application, providing (at minimum) the channel's id and the application to switch to. If the application is not registered or active, nothing will happen and the channel will remain in the current application, and an event will be triggered to let the application know that the move failed. The event name is "ApplicationMoveFailed", and provides the "destination" that the channel was attempting to move to, as well as the usual channel information. Optionally, a list of arguments can be passed to the function call for the receiving application. A full example of a 'move' call would look like this: client.channels.move(channelId, app, appArgs) The control object used to control the channel in Stasis can now switch which application it belongs to, rather than belonging to one Stasis application for its lifetime. This allows us to use the same control object instead of having to tear down the current one and create another. ASTERISK-28267 #close Change-Id: I43d12b10045a98a8d42541889b85695be26f288a	6 years ago
Kevin Harwell	1c5def4b18	ARI event type filtering ... Event type filtering is now enabled, and configurable per application. An app is now able to specify which events are sent to the application by configuring an allowed and/or disallowed list(s). This can be done by issuing the following: PUT /applications/{applicationName}/eventFilter And then enumerating the allowed/disallowed event types as a body parameter. ASTERISK-28106 Change-Id: I9671ba1fcdb3b6c830b553d4c5365aed5d588d5b	6 years ago
Corey Farrell	ed7a5664b6	astobj2: Eliminate usage of legacy ao2_container_alloc routine. ... Replace usage of ao2_container_alloc with ao2_container_alloc_hash or ao2_container_alloc_list. ao2_container_alloc is now restricted to modules only and is being removed from Asterisk 17. Change-Id: I0907d78bc66efc775672df37c8faad00f2f6c088	7 years ago
Moritz Fain	1f68614f3c	res_stasis: Fix stale data in ARI bridges ... Fixed an issue that resulted in "Allocation failed" each time an ARI request was made to start playing MOH on a bridge. In bridge_moh_create() we were attaching the after bridge callbacks to chan which is the ;1 channel of the unreal channel pair. We should have attached them to the ;2 channel which is pushed into the bridge by ast_unreal_channel_push_to_bridge(). The callbacks are called when the specific channel leaves the bridging system. Since the ;1 channel is never put into a bridge the callbacks never get called. The callbacks then never remove the moh_wrapper from the app_bridges_moh container. As a result we cannot find the channel associated with the wrapper to start MOH because it has hungup. This is the reason causing the reported issue. * Rather than using after bridge callbacks to cleanup, we now have moh_channel_thread() doing the cleanup when the channel hangs up. * Fixed moh_channel_thread() accumulating control frames on the stasis bridge MOH channel until MOH is stopped. Control frames are no longer accumulated while MOH is playing. * Fixed channel ref counting issue. stasis_app_bridge_moh_channel() may or may not return a channel ref. As a result ast_ari_bridges_start_moh() wouldn't know it may have a channel ref to release. stasis_app_bridge_moh_channel() will now return a ref with the channel it returns. * Eliminated RAII_VAR in bridge_moh_create(). ASTERISK-26094 #close Change-Id: Ibff479e167b3320c68aaabfada7e1d0ef7bd548c	7 years ago
Corey Farrell	7b0dbda936	json: Take advantage of new API's. ... * Use "o*" format specifier for optional fields in ast_json_party_id. * Stop using ast_json_deep_copy on immutable objects, it is now thread safe to just use ast_json_ref. Additional changes to ast_json_pack calls in the vicinity: * Use "O" when an object needs to be bumped. This was previously avoided as it was not thread safe. * Use "o?" and "O?" to replace NULL with ast_json_null(). The "?" is a new feature of ast_json_pack starting with Asterisk 16. Change-Id: I8382d28d7d83ee0ce13334e51ae45dbc0bdaef48	7 years ago
Corey Farrell	527cf5a570	Remove redundant module checks and references. ... This removes references that are no longer needed due to automatic references created by module dependencies. In addition this removes most calls to ast_module_check as they were checking modules which are listed as dependencies. Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e	7 years ago
Joshua Colp	f2c583624b	Merge "res_stasis: Reduce RAII_VAR usage."	7 years ago
Corey Farrell	55a540272f	res_stasis: Reduce RAII_VAR usage. ... In addition to being a micro-optimization (RAII_VAR has overhead), this change improves output of REF_DEBUG. Unfortunately when RAII_VAR calls ao2_cleanup it does so from a generated _dtor_varname function. For example this caused _dtor_app to release a reference instead of __stasis_app_unregister. Change-Id: I4ce67120583a446babf9adeec678b71d37fcd9e5	7 years ago
Corey Farrell	8b3083cac5	res_stasis: Fix dial bridge unload. ... If the dial bridge has been created it must be released by calling ast_bridge_destroy, simply releasing the ao2 reference is not enough. Also move stasis_app_control_shutdown earlier in unload to ensure the bridge cannot be created or grabbed after the app_bridges container is released. Change-Id: I372302de94ca63876069e2585a049c5060e5e767	7 years ago
Corey Farrell	e2dbc26376	res_stasis and res_speech: Fix load order. ... res_stasis was missing AST_MODFLAG_LOAD_ORDER. Set res_stasis and res_speech to start at (AST_MODPRI_APP_DEPEND - 1) so they are ready for dependent modules. Change-Id: I27f4f3810a95b6be8a5bfbf62be2ace6bfab6ff3	8 years ago
Joshua Colp	f21408c866	res_stasis: Add 'video_sfu' as a requested bridge type. ... This change adds 'video_sfu' as a requested bridge type when creating a bridge. By specifying this a mixing type bridge is created that exchanges video in an SFU fashion. Change-Id: I2ada47cf5f3fc176518b647c0b4aa39d55339606	8 years ago
George Joseph	854a6de819	res_stasis: Plug reference leak on stolen channels ... When a stasis channel is stolen by another app, the control structure is unreffed but never unlinked from the app_controls container. This causes the channel reference to leak. Added OBJ_UNLINK to the callback in channel_stolen_cb. Also added some additional channel lifecycle debug messages to channel.c. ASTERISK-27059 #close Repoorted-by: George Joseph Change-Id: Ib820936cd49453f20156971785e7f4f182c56e14	8 years ago
George Joseph	747beb1ed1	modules: change module LOAD_FAILUREs to LOAD_DECLINES ... In all non-pbx modules, AST_MODULE_LOAD_FAILURE has been changed to AST_MODULE_LOAD_DECLINE. This prevents asterisk from exiting if a module can't be loaded. If the user wishes to retain the FAILURE behavior for a specific module, they can use the "require" or "preload-require" keyword in modules.conf. A new API was added to logger: ast_is_logger_initialized(). This allows asterisk.c/check_init() to print to the error log once the logger subsystem is ready instead of just to stdout. If something does fail before the logger is initialized, we now print to stderr instead of stdout. Change-Id: I5f4b50623d9b5a6cb7c5624a8c5c1274c13b2b25	8 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)	8 years ago
Joshua Colp	3019dfd49f	Merge "res_stasis: Don't unsubscribe from a NULL bridge."	9 years ago
Joshua Colp	d30415bfa1	res_stasis: Don't unsubscribe from a NULL bridge. ... A NULL bridge has special meaning in res_stasis for unsubscribing. It means that a subscription to ALL bridges should be removed. This should not be done as part of the normal subscription management in the res_stasis channel loop. ASTERISK-26468 Change-Id: I6d5bea8246dd13a22ef86b736aefbf2a39c15af0	9 years ago
Matt Jordan	7a449b6819	res_stasis: Set a video source mode on Stasis created bridges ... When a bridge is created via ARI (through res_stasis), no video source mode is set by default. As a result, any endpoint sending video media won't ever see any video reflected back to it. This patch defaults a bridge to a 'follow the talker' video mode. Further work can be done to add routes that allow for the video mode to be controlled through the /bridges resource. Change-Id: I7e9d530a5d7a97a4524a9ee4e468e1a6b3443866	9 years ago
Matt Jordan	c30d677333	res/stasis: Add CLI commands for displaying/debugging ARI apps ... This patch adds three new CLI commands: - ari show apps: list the registered ARI applications - ari show app: show detailed information about an ARI application - ari set debug: dump events being sent to an ARI application Note that while these CLI commands live in the res_stasis module, we use the 'ari' family for these commands. This was done as most users of Asterisk aren't aware of the semantic differences between ARI and res_stasis, and some 'ari' CLI commands already exist. ASTERISK-26488 #close Change-Id: I51ad6ff0cabee0d69db06858c13f18b1c513c9f5	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
Mark Michelson	11caa10cf5	ARI: Ensure announcer channels are destroyed. ... Announcer channels were not being destroyed because the stasis_app_control structure that referenced them was not being destroyed. The control structure was not being destroyed because it was not being unlinked from its container. It was not being unlinked from its container because the after bridge callback for the announcer channel was not being run. The after bridge callback was not being run because the after bridge datastore was not being removed from the channel on destruction. The channel was not being destroyed because the hangup that used to destroy the channel was now only reducing the reference count to one. The reference count of the channel was only being reduced to one because the stasis_app_control structure was holding the final reference... The control structure used to not keep a reference to the channel, so that loop described above did not happen. The solution is to manually remove the control structure from its container when the playback on a bridge is complete. ASTERISK-26083 #close Reported by Joshua Colp Change-Id: I0ddc0f64484ea0016245800b409b567dfe85cfb4	9 years ago
Mark Michelson	88d997913f	ARI: Re-implement the ARI dial command, allowing for early bridging. ... ARI dial had been implemented using the Dial API. This made great sense when dialing was 100% separate from bridging. However, if a channel were to be added to a bridge during the dial attempt, there would be a conflict between the dialing thread and the bridging thread. Each would be attempting to read frames from the dialed channel and act on them. The initial attempt to make the two play nice was to have the Dial API suspend the channel in the bridge and stay in charge of the channel until the dial was complete. The problem with this was that it was riddled with potential race conditions. It also was not well-suited for the case where the channel changed which bridge it was in during the dial. This new approach removes the use of the Dial API altogether. Instead, the channel we are dialing is placed into an invisible ARI dialing bridge. The bridge channel thread handles incoming frames from the channel. If the channel is added to a real bridge, it is departed from the invisible bridge and then added to the real bridge. Similarly, if the channel is removed from the real bridge, it is automatically added back to the invisible bridge if the dial attempt is still active. This approach keeps the threading simple by always having the channel being handled by bridge channel threads. ASTERISK-25925 Change-Id: I7750359ddf45fcd45eaec749c5b3822de4a8ddbb	9 years ago
Joshua Colp	72ef79dc2d	Merge "ARI: Add method to Dial a created channel."	9 years ago
Mark Michelson	abbb2edd4c	ARI: Add method to Dial a created channel. ... This adds a new ARI method that allows for you to dial a channel that you previously created in ARI. By combining this with the create method for channels, it allows for a workflow where a channel can be created, manipulated, and then dialed. The channel is under control of the ARI application during all stages of the Dial and can even be manipulated based on channel state changes observed within an ARI application. The overarching goal for this is to eventually be able to add a dialed channel to a Stasis bridge earlier than the "Up" state. However, at the moment more work is needed in the Dial and Bridge APIs in order to facilitate that. ASTERISK-25889 #close Change-Id: Ic6c399c791e66c4aa52454222fe4f8b02483a205	9 years ago
zuul	e2a8033d09	Merge "res_stasis: Add control ref to playback and recording structs."	9 years ago
zuul	cd6d478d3f	Merge "res_stasis: Fix crash on a hanging up channel."	9 years ago
Richard Mudgett	0ea742d33a	res_stasis: Add control ref to playback and recording structs. ... The stasis_app_playback and stasis_app_recording structs need to have a struct stasis_app_control ref. Other threads can get a reference to the playback and recording structs from their respective global container. These other threads can then use the control pointer they contain after the control struct has gone. * Add control ref to stasis_app_playback and stasis_app_recording structs. With the refs added, the control command queue can now have a circular control reference which will cause the control struct to never get released if the control's command queue is not flushed when the channel leaves the Stasis application. Also the command queue needs better protection from adding commands if the control->is_done flag is set. * Flush the control command queue on exit. ASTERISK-25882 #close Change-Id: I3cf1fb59cbe6f50f20d9e35a2c07ac07d7f4320d	9 years ago
Richard Mudgett	53f63ad770	res_stasis: Fix crash on a hanging up channel. ... * Give the struct stasis_app_control ao2 object a ref to the channel held in the object. Now the channel will still be around if a thread needs to post a stasis message instead of crash because the topic was destroyed. * Moved stopping any lingering silence generator out of the struct stasis_app_control destructor and made it a part of exiting the Stasis application. Who knows which thread the destructor will be called under so it cannot affect the channel's silence generator. Not only was the channel unprotected when the silence generator was stopped, stasis may no longer even control the channel. ASTERISK-25882 Change-Id: I21728161b5fe638cef7976fa36a605043a7497e4	9 years ago
Richard Mudgett	2fab4d7da8	res_stasis.c: Protect channel datastore list from stasis end. ... Change-Id: Ifadc469590bd4d5368e19d3763db3bd1f80fdb95	9 years ago
Joshua Colp	d17d9a9288	json: Audit ast_json_* usage for thread safety. ... The JSON library Asterisk uses, jansson, is not thread safe for us in a few ways. To help with this wrappers for JSON object reference count increasing and decreasing were added which use a global lock to ensure they don't clobber over each other. This does not extend to reference count manipulation within the jansson library itself. This means you can't safely use the object borrowing specifier (O) in ast_json_pack and you can't share JSON instances between objects. This change removes uses of the O specifier and replaces them with the o specifier and an explicit ast_json_ref. Some cases of instance sharing have also been removed. ASTERISK-25601 #close Change-Id: I06550d8b0cc1bfeb56cab580a4e608ae4f1ec7d1	10 years ago
Matt Jordan	9402f80726	res/res_stasis: Fix accidental subscription to 'all' bridge topic ... When b99a705262 was merged, subscribing to a NULL bridge will now cause app_subscribe_bridge to implicitly subscribe to all bridges. Unfortunately, the res_stasis control loop did not check that a bridge changing on a channel's control object was actually also non-NULL. As a result, app_subscribe_bridge will be called with a NULL bridge when a channel leaves a bridge. This causes a new subscription to be made to the bridge. If an application has also subscribed to the bridge, the application will now have two subscriptions: (1) The explicit one created by the app (2) The implicit one accidentally created by the control structure As a result, the 'BridgeDestroyed' event can be sent multiple times. This patch corrects the control loop such that it only subscribes an application to a new bridge if the bridge pointer is non-NULL. ASTERISK-24870 Change-Id: I3510e55f6bc36517c10597ead857b964463c9f4f	10 years ago
Matt Jordan	b99a705262	ARI: Add the ability to subscribe to all events ... This patch adds the ability to subscribe to all events. There are two possible ways to accomplish this: (1) On initial WebSocket connection. This patch adds a new query parameter, 'subscribeAll'. If present and True, Asterisk will subscribe the applications to all ARI events. (2) Via the applications resource. When subscribing in this manner, an ARI client should merely specify a blank resource name, i.e., 'channels:' instead of 'channels:12354'. This will subscribe the application to all resources of the 'channels' type. ASTERISK-24870 #close Change-Id: I4a943b4db24442cf28bc64b24bfd541249790ad6	10 years ago
Mark Michelson	d7a1e84a1e	Resolve race conditions involving Stasis bridges. ... This resolves two observed race conditions. First, a bit of background on what the Stasis application does: 1a Creates a stasis_app_control structure. This structure is linked into a global container and can be looked up using a channel's unique ID. 2a Puts the channel in an event loop. The event loop can exit either because the stasis_app_control structure has been marked done, or because of some other factor, such as a hangup. In the event loop, the stasis_app_control determines if any specific ARI commands need to be run on the channel and will run them from this thread. 3a Checks if the channel is bridged. If the channel is bridged, then ast_bridge_depart() is called since channels that are added to Stasis bridges are always imparted as departable. 4a Unlink the stasis_app_control from the container. When an ARI command is received by Asterisk, the following occurs 1b A thread is spawned to handle the HTTP request 2b The stasis_app_control(s) that corresponds to the channel(s) in the request is/are retrieved. If the stasis_app_control cannot be retrieved, then it is assumed that the channel in question has exited the Stasis app or perhaps was never in Stasis in the first place. 3b A command is queued onto the stasis_app_control, and the channel's event loop thread is signaled to run the command. 4b While most ARI commands do nothing further, some, such as adding or removing channels from a bridge, will block until the command they issued has been completed by the channel's event loop. The first race condition that is solved by this patch involves a crash that can occur due to faulty detection of the channel's bridged status in step 3a. What can happen is that in step 2a, the event loop may run the ast_bridge_impart() function to asynchronously place the channel into a bridge, then immediately exit the event loop because the channel has hung up. In step 3a, we would detect that the channel was not bridged and would not call ast_bridge_depart(). The reason that the channel did not appear to be bridged was that the depart_thread that is spawned by ast_bridge_impart() had not yet started. That is the thread where the channel is marked as being bridged. Since we did not call ast_bridge_depart(), the Stasis application would exit, and then the channel would be destroyed Then the depart_thread would start up and try to manipulate the destroyed channel, causing a crash. The fix for this is to switch from using ast_channel_is_bridged() to checking the NULLity of ast_channel_internal_bridge_channel() to determine if ast_bridge_depart() needs to be called. The channel's internal bridge_channel is set when ast_bridge_impart() is called and is NULLed by the call to ast_bridge_depart(). If the channel's internal bridge_channel is non-NULL, then the channel must have been imparted into the bridge and needs to be departed, even if the actual bridging operation has not yet started. By departing the channel when necessary, the thread that is running the Stasis application will block until the bridge gives the okay that the depart_thread has exited. The second race condition that is solved by this patch involves a leak of HTTP handler threads. The problem was that step 2b would successfully retrieve a stasis_app_control structure. Then step 2a would exit the channel from the event loop due to a hangup. Steps 3a and 4a would execute, and then finally steps 3b and 4b would. The problem is that at step 4b, when attempting to add a channel to a bridge, the thread would block forever since the channel would never execute the queued command since it was finished with the event loop. This meant that the HTTP handling thread would be leaked, along with any references that thread may have owned (in my case, I was seeing bridges leaked). The fix for this is to hone in better on when the channel has exited the event loop. The stasis_app_control structure has an is_done field that is now set at each point where the channel may exit the event loop. If step 2b retrieves a valid stasis_app_control structure but the control is marked as done, then the attempted operation exits immediately since there will be nothing to service the attempted command. ASTERISK-25091 #close Reported by Ilya Trikoz Change-Id: If66265b73b4c9f8f58599124d777fedc54576628	10 years ago
Rodrigo Ramírez Norambuena	eec010829a	AST_MODULE_INFO: Format corrections to the usages of AST_MODULE_INFO macro. ... Change-Id: Icf88f9f861c6b2a16e5f626ff25795218a6f2723	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	10 years ago
Matthew Jordan	ce59fabd5c	clang compiler warnings: Fix invalid enum conversion ... This patch fixes some invalid enum conversion warnings caught by clang. In particular: * chan_sip: Several functions mixed usage of the st_refresher_param enum and st_refresher enum. This patch corrects the functions to use the right enum. * chan_pjsip: Fixed mixed usage of ast_sip_session_t38state and ast_t38_state. * strings: Fixed incorrect usage of AO2 flags with strings container. * res_stasis: Change a return enumeration to stasis_app_user_event_res. Review: https://reviewboard.asterisk.org/r/4535 ASTERISK-24917 Reported by: dkdegroot patches: rb4535.patch submitted by dkdegroot (License 6600) ........ Merged revisions 433746 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 433747 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433748 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Kevin Harwell	ca02121ef7	Investigate and fix memory leaks in Asterisk ... Fixed memory leaks that were found in Asterisk. ASTERISK-24693 #close Reported by: Kevin Harwell Review: https://reviewboard.asterisk.org/r/4347/ ........ Merged revisions 430999 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431010 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Kinsey Moore	f8c4909eb7	ARI: Allow usage of ASYNCGOTO with Stasis() ... When the AMI Redirect action is used with a channel bridged inside Stasis() and not running a pbx, the channel is hung up instead of proceeding to the desired location in dialplan. This change allows such channels to be Redirected properly by detecting the operation used by Redirect (ASYNCGOTO) and using the code already established for functionality of the ARI channel continue operation. ASTERISK-24591 #close Review: https://reviewboard.asterisk.org/r/4271/ ........ Merged revisions 430355 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430356 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	5db1c978e3	res/res_stasis: Fix crash on module unload while performing operation ... When the res_stasis module is unloaded, it will dispose of the apps_registry container. This is a problem if an ARI operation is in flight that attempts to use the registry, as the shutdown occurs in a separate thread. This patch adds some sanity checks to the various routines that access the registry which cause the operations to fail if the apps_registry does not exist. Crash caught by the Asterisk Test Suite. ........ Merged revisions 426995 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 426996 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426997 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