82 Commits (a66fa4db24553d6ec6c8978c528081a94b1715a1)

Author	SHA1	Message	Date
Corey Farrell	17480f6ea4	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	3d79c34350	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
George Joseph	edfdb4dff5	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	f882ca2572	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	17f4989d49	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	8 years ago
Joshua Colp	dc04c1725f	Merge "res_stasis: Don't unsubscribe from a NULL bridge." into 13	9 years ago
Matt Jordan	7a83196985	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
Joshua Colp	3a1f9c5dab	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	29692d4aa4	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
Mark Michelson	cfebe3b94a	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
zuul	e8c6cf8947	Merge "res_stasis: Add control ref to playback and recording structs." into 13	9 years ago
Joshua Colp	cb9b7f6b1b	Merge "res_stasis: Fix crash on a hanging up channel." into 13	9 years ago
Richard Mudgett	5f73c2ef0a	res_stasis.c: Protect channel datastore list from stasis end. ... Change-Id: Ifadc469590bd4d5368e19d3763db3bd1f80fdb95	9 years ago
Richard Mudgett	ecf4102d02	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	a179aba65e	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
Joshua Colp	a9d6fc571d	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	90165e306d	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	4c9f613309	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	9015bb4c8c	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
Matthew Jordan	09b681e344	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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433747 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Kevin Harwell	630eea087d	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/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430999 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Kinsey Moore	8f3c60cee7	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/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430355 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	55c9a46abd	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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429062 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	5013659972	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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427789 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	d5309929be	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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426996 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	2d8c38cf9a	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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422504 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Jonathan Rose	712907eec6	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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421880 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	6e5ca3fe5b	Fix compilation error on certain versions of GCC. ... ........ Merged revisions 421447 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421448 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Jonathan Rose	5c35544a23	ARI: Fix a bug where /channels/{channelID}/continue doesn't execute PBX ... If /channels/{channelID}/continue is called on a channel that was originated without a PBX (such as the ARI command POST channel with a stasis application argument), the channel will not start dialplan execution. This patch will now run the PBX out of the stasis execution if the channel doesn't currently have an active PBX upon continuing. ASTERISK-24043 #close Reported by: Krandon Bruse Review: https://reviewboard.asterisk.org/r/3917/ Patches: stasis-continue.diff submitted by Krandon Bruse (license 6631) ........ Merged revisions 421416 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421423 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	ccb2f94691	Stasis: Use the correct return value ... Return the correct value instead of always returning 0 when setting internal status on unreal channels. Reported by: Richard Mudgett ........ Merged revisions 420802 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420803 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	406dded64c	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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420796 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
Kinsey Moore	f1036f40dc	Stasis: Allow message types to be blocked ... 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	11 years ago
Matthew Jordan	47bf7efc4d	Multiple revisions 420089-420090,420097 ... ........ r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines ARI: Add channel technology agnostic out of call text messaging This patch adds the ability to send and receive text messages from various technology stacks in Asterisk through ARI. This includes chan_sip (sip), res_pjsip_messaging (pjsip), and res_xmpp (xmpp). Messages are sent using the endpoints resource, and can be sent directly through that resource, or to a particular endpoint. For example, the following would send the message "Hello there" to PJSIP endpoint alice with a display URI of sip:asterisk@mycooldomain.org: ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There This is equivalent to the following as well: ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@mycooldomain.org&body=Hello+There Both forms are available for message technologies that allow for arbitrary destinations, such as chan_sip. Inbound messages can now be received over ARI as well. An ARI application that subscribes to endpoints will receive messages from those endpoints: { "type": "TextMessageReceived", "timestamp": "2014-07-12T22:53:13.494-0500", "endpoint": { "technology": "PJSIP", "resource": "alice", "state": "online", "channel_ids": [] }, "message": { "from": "\"alice\" <sip:alice@127.0.0.1>", "to": "pjsip:asterisk@127.0.0.1", "body": "Watson, come here.", "variables": [] }, "application": "testsuite" } The above was made possible due to some rather major changes in the message core. This includes (but is not limited to): - Users of the message API can now register message handlers. A handler has two callbacks: one to determine if the handler has a destination for the message, and another to handle it. - All dialplan functionality of handling a message was moved into a message handler provided by the message API. - Messages can now have the technology/endpoint associated with them. Various other properties are also now more easily accessible. - A number of ao2 containers that weren't really needed were replaced with vectors. Iteration over ao2_containers is expensive and pointless when the lifetime of things is well defined and the number of things is very small. res_stasis now has a new file that makes up its structure, messaging. The messaging functionality implements a message handler, and passes received messages that match an interested endpoint over to the app for processing. Note that inadvertently while testing this, I reproduced ASTERISK-23969. res_pjsip_messaging was incorrectly parsing out the 'to' field, such that arbitrary SIP URIs mangled the endpoint lookup. This patch includes the fix for that as well. Review: https://reviewboard.asterisk.org/r/3726 ASTERISK-23692 #close Reported by: Matt Jordan ASTERISK-23969 #close Reported by: Andrew Nagy ........ r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines Remove automerge properties :-( ........ r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines test_message: Fix strict-aliasing compilation issue ........ Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	dcf1ad14da	Add module support level to ast_module_info structure. Print it in CLI "module show" . ... ASTERISK-23919 #close Reported by Malcolm Davenport Review: https://reviewboard.asterisk.org/r/3802 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	a2c912e997	media formats: re-architect handling of media for performance improvements ... In the old times media formats were represented using a bit field. This was fast but had a few limitations. 1. Asterisk was limited in how many formats it could handle. 2. Formats, being a bit field, could not include any attribute information. A format was strictly its type, e.g., "this is ulaw". This was changed in Asterisk 10 (see https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for notes on that work) which led to the creation of the ast_format structure. This structure allowed Asterisk to handle attributes and bundle information with a format. Additionally, ast_format_cap was created to act as a container for multiple formats that, together, formed the capability of some entity. Another mechanism was added to allow logic to be registered which performed format attribute negotiation. Everywhere throughout the codebase Asterisk was changed to use this strategy. Unfortunately, in software, there is no free lunch. These new capabilities came at a cost. Performance analysis and profiling showed that we spend an inordinate amount of time comparing, copying, and generally manipulating formats and their related structures. Basic prototyping has shown that a reasonably large performance improvement could be made in this area. This patch is the result of that project, which overhauled the media format architecture and its usage in Asterisk to improve performance. Generally, the new philosophy for handling formats is as follows: * The ast_format structure is reference counted. This removed a large amount of the memory allocations and copying that was done in prior versions. * In order to prevent race conditions while keeping things performant, the ast_format structure is immutable by convention and lock-free. Violate this tenet at your peril! * Because formats are reference counted, codecs are also reference counted. The Asterisk core generally provides built-in codecs and caches the ast_format structures created to represent them. Generally, to prevent inordinate amounts of module reference bumping, codecs and formats can be added at run-time but cannot be removed. * All compatibility with the bit field representation of codecs/formats has been moved to a compatibility API. The primary user of this representation is chan_iax2, which must continue to maintain its bit-field usage of formats for interoperability concerns. * When a format is negotiated with attributes, or when a format cannot be represented by one of the cached formats, a new format object is created or cloned from an existing format. That format may have the same codec underlying it, but is a different format than a version of the format with different attributes or without attributes. * While formats are reference counted objects, the reference count maintained on the format should be manipulated with care. Formats are generally cached and will persist for the lifetime of Asterisk and do not explicitly need to have their lifetime modified. An exception to this is when the user of a format does not know where the format came from *and* the user may outlive the provider of the format. This occurs, for example, when a format is read from a channel: the channel may have a format with attributes (hence, non-cached) and the user of the format may last longer than the channel (if the reference to the channel is released prior to the format's reference). For more information on this work, see the API design notes: https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite Finally, this work was the culmination of a large number of developer's efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the work in the Asterisk core, chan_sip, and was an invaluable resource in peer reviews throughout this project. There were a substantial number of patches contributed during this work; the following issues/patch names simply reflect some of the work (and will cause the release scripts to give attribution to the individuals who work on them). Reviews: https://reviewboard.asterisk.org/r/3814 https://reviewboard.asterisk.org/r/3808 https://reviewboard.asterisk.org/r/3805 https://reviewboard.asterisk.org/r/3803 https://reviewboard.asterisk.org/r/3801 https://reviewboard.asterisk.org/r/3798 https://reviewboard.asterisk.org/r/3800 https://reviewboard.asterisk.org/r/3794 https://reviewboard.asterisk.org/r/3793 https://reviewboard.asterisk.org/r/3792 https://reviewboard.asterisk.org/r/3791 https://reviewboard.asterisk.org/r/3790 https://reviewboard.asterisk.org/r/3789 https://reviewboard.asterisk.org/r/3788 https://reviewboard.asterisk.org/r/3787 https://reviewboard.asterisk.org/r/3786 https://reviewboard.asterisk.org/r/3784 https://reviewboard.asterisk.org/r/3783 https://reviewboard.asterisk.org/r/3778 https://reviewboard.asterisk.org/r/3774 https://reviewboard.asterisk.org/r/3775 https://reviewboard.asterisk.org/r/3772 https://reviewboard.asterisk.org/r/3761 https://reviewboard.asterisk.org/r/3754 https://reviewboard.asterisk.org/r/3753 https://reviewboard.asterisk.org/r/3751 https://reviewboard.asterisk.org/r/3750 https://reviewboard.asterisk.org/r/3748 https://reviewboard.asterisk.org/r/3747 https://reviewboard.asterisk.org/r/3746 https://reviewboard.asterisk.org/r/3742 https://reviewboard.asterisk.org/r/3740 https://reviewboard.asterisk.org/r/3739 https://reviewboard.asterisk.org/r/3738 https://reviewboard.asterisk.org/r/3737 https://reviewboard.asterisk.org/r/3736 https://reviewboard.asterisk.org/r/3734 https://reviewboard.asterisk.org/r/3722 https://reviewboard.asterisk.org/r/3713 https://reviewboard.asterisk.org/r/3703 https://reviewboard.asterisk.org/r/3689 https://reviewboard.asterisk.org/r/3687 https://reviewboard.asterisk.org/r/3674 https://reviewboard.asterisk.org/r/3671 https://reviewboard.asterisk.org/r/3667 https://reviewboard.asterisk.org/r/3665 https://reviewboard.asterisk.org/r/3625 https://reviewboard.asterisk.org/r/3602 https://reviewboard.asterisk.org/r/3519 https://reviewboard.asterisk.org/r/3518 https://reviewboard.asterisk.org/r/3516 https://reviewboard.asterisk.org/r/3515 https://reviewboard.asterisk.org/r/3512 https://reviewboard.asterisk.org/r/3506 https://reviewboard.asterisk.org/r/3413 https://reviewboard.asterisk.org/r/3410 https://reviewboard.asterisk.org/r/3387 https://reviewboard.asterisk.org/r/3388 https://reviewboard.asterisk.org/r/3389 https://reviewboard.asterisk.org/r/3390 https://reviewboard.asterisk.org/r/3321 https://reviewboard.asterisk.org/r/3320 https://reviewboard.asterisk.org/r/3319 https://reviewboard.asterisk.org/r/3318 https://reviewboard.asterisk.org/r/3266 https://reviewboard.asterisk.org/r/3265 https://reviewboard.asterisk.org/r/3234 https://reviewboard.asterisk.org/r/3178 ASTERISK-23114 #close Reported by: mjordan media_formats_translation_core.diff uploaded by kharwell (License 6464) rb3506.diff uploaded by mjordan (License 6283) media_format_app_file.diff uploaded by kharwell (License 6464) misc-2.diff uploaded by file (License 5000) chan_mild-3.diff uploaded by file (License 5000) chan_obscure.diff uploaded by file (License 5000) jingle.diff uploaded by file (License 5000) funcs.diff uploaded by file (License 5000) formats.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) bridges.diff uploaded by file (License 5000) mf-codecs-2.diff uploaded by file (License 5000) mf-app_fax.diff uploaded by file (License 5000) mf-apps-3.diff uploaded by file (License 5000) media-formats-3.diff uploaded by file (License 5000) ASTERISK-23715 rb3713.patch uploaded by coreyfarrell (License 5909) rb3689.patch uploaded by mjordan (License 6283) ASTERISK-23957 rb3722.patch uploaded by mjordan (License 6283) mf-attributes-3.diff uploaded by file (License 5000) ASTERISK-23958 Tested by: jrose rb3822.patch uploaded by coreyfarrell (License 5909) rb3800.patch uploaded by jrose (License 6182) chan_sip.diff uploaded by mjordan (License 6283) rb3747.patch uploaded by jrose (License 6182) ASTERISK-23959 #close Tested by: sgriepentrog, mjordan, coreyfarrell sip_cleanup.diff uploaded by opticron (License 6273) chan_sip_caps.diff uploaded by mjordan (License 6283) rb3751.patch uploaded by coreyfarrell (License 5909) chan_sip-3.diff uploaded by file (License 5000) ASTERISK-23960 #close Tested by: opticron direct_media.diff uploaded by opticron (License 6273) pjsip-direct-media.diff uploaded by file (License 5000) format_cap_remove.diff uploaded by opticron (License 6273) media_format_fixes.diff uploaded by opticron (License 6273) chan_pjsip-2.diff uploaded by file (License 5000) ASTERISK-23966 #close Tested by: rmudgett rb3803.patch uploaded by rmudgetti (License 5621) chan_dahdi.diff uploaded by file (License 5000) ASTERISK-24064 #close Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose rb3814.patch uploaded by rmudgett (License 5621) moh_cleanup.diff uploaded by opticron (License 6273) bridge_leak.diff uploaded by opticron (License 6273) translate.diff uploaded by file (License 5000) rb3795.patch uploaded by rmudgett (License 5621) tls_fix.diff uploaded by mjordan (License 6283) fax-mf-fix-2.diff uploaded by file (License 5000) rtp_transfer_stuff uploaded by mjordan (License 6283) rb3787.patch uploaded by rmudgett (License 5621) media-formats-explicit-translate-format-3.diff uploaded by file (License 5000) format_cache_case_fix.diff uploaded by opticron (License 6273) rb3774.patch uploaded by rmudgett (License 5621) rb3775.patch uploaded by rmudgett (License 5621) rtp_engine_fix.diff uploaded by opticron (License 6273) rtp_crash_fix.diff uploaded by opticron (License 6273) rb3753.patch uploaded by mjordan (License 6283) rb3750.patch uploaded by mjordan (License 6283) rb3748.patch uploaded by rmudgett (License 5621) media_format_fixes.diff uploaded by opticron (License 6273) rb3740.patch uploaded by mjordan (License 6283) rb3739.patch uploaded by mjordan (License 6283) rb3734.patch uploaded by mjordan (License 6283) rb3689.patch uploaded by mjordan (License 6283) rb3674.patch uploaded by coreyfarrell (License 5909) rb3671.patch uploaded by coreyfarrell (License 5909) rb3667.patch uploaded by coreyfarrell (License 5909) rb3665.patch uploaded by mjordan (License 6283) rb3625.patch uploaded by coreyfarrell (License 5909) rb3602.patch uploaded by coreyfarrell (License 5909) format_compatibility-2.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 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
Matthew Jordan	d4b436d0ea	ARI/res_stasis: Subscribe to both Local channel halves when originating to app ... This patch fixes two bugs: 1. When originating a channel into a Stasis application, we already create a subscription for the channel that is going into our Stasis app. Unfortunately, when you create a Local channel and pass it off to a Stasis app, you really aren't creating just one channel: you're creating two. This patch snags the second half of the Local channel pair (assuming it is a Local channel pair, but luckily core_local is kind about such assumptions) and subscribes to it as well. 2. Subscriptions are a bit sticky right now. If a subscription is made, the 'interest' count gets bumped on the Stasis subscription - but unless something explicitly unsubscribes the channel, said subscription sticks around. This is not much of a problem is a user is creating the subscription - if they made it, they must want it. However, when we are creating implicit subscriptions, we need to make sure something clears them out. This patch takes a pessimistic approach: it watches the cache updates coming from Stasis and, if we notice that the cache just cleared out an object, we delete our subscription object. This keeps our ao2 container of Stasis forwards in an application from growing out of hand; it also is a bit more forgiving for end users who may not realize they were supposed to unsubscribe from that channel that just hung up. Review: https://reviewboard.asterisk.org/r/3710/ #ASTERISK-23939 #close ........ Merged revisions 418089 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418090 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Scott Griepentrog	cf21644d6a	ARI: Add ability to raise arbitrary User Events ... User events can now be generated from ARI. Events can be signalled with arbitrary json variables, and include one or more of channel, bridge, or endpoint snapshots. An application must be specified which will receive the event message (other applications can subscribe to it). The message will also be delivered via AMI provided a channel is attached. Dialplan generated user event messages are still transmitted via the channel, and will only be received by a stasis application they are attached to or if the channel is subscribed to. This change also introduces the multi object blob mechanism used to send multiple snapshot types in a single message. The dialplan app UserEvent was also changed to use multi object blob, and a new stasis message type created to handle them. ASTERISK-22697 #close Review: https://reviewboard.asterisk.org/r/3494/ ........ Merged revisions 414405 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414406 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Jonathan Rose	b9d7dfcc62	ARI: Make bridges/{bridgeID}/play queue sound files ... Previously multiple play actions against a bridge at one time would cause the sounds to play simultaneously on the bridge. Now if a sound is already playing, the play action will queue playback to occur after the completion of other sounds currently on the queue. (closes issue ASTERISK-22677) Reported by: John Bigelow Review: https://reviewboard.asterisk.org/r/3379/ ........ Merged revisions 412639 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412641 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	62e2bf68f0	Stasis: Fix Stasis() bridge refcount issue ... The Stasis() dialplan application monitors what bridge a channel is in and so necessarily holds on to a bridge pointer. This change ensures that it also holds on to a reference for that bridge to prevent the bridge pointer from becoming a dangling pointer. ........ Merged revisions 411804 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411806 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Jonathan Rose	eb0a982f8c	ARI: Resolve a subscription leak against implicit bridge subscriptions ... When a channel in a stasis application is joined to a bridge, a subscription for that bridge is created implicitly for the stasis application serving the channel. Prior to this patch, subsequent removals of the channel from the bridge would leave the subscription open. Review: https://reviewboard.asterisk.org/r/3380/ ........ Merged revisions 411086 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411090 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	326153d949	res_stasis: Fix a bug where the default bridge type was not set. ... ........ Merged revisions 410918 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410919 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	1cf74b8776	res_stasis: Extend bridge type to be a comma separated list of bridge attributes. ... This change turns the bridge type field into a comma separated list of attributes. These attributes include: mixing, holding, dtmf_events, and proxy_media. By setting the various attributes a user can control the type of bridge created with the behavior they need for their application. (closes issue ASTERISK-23437) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3359/ ........ Merged revisions 410904 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410905 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	5247a0d990	ARI: Ensure managing application receives ChannelEnteredBridge messages ... This fixes an issue where a Stasis application running over ARI and subscribed to ari/events could miss the ChannelEnteredBridge event because it did not subscribe to the new bridge fast enough. To accomplish this, it subscribes the application controlling the channel to the new bridge before adding it to that bridge which required the stasis_app_control structure to maintain a reference to the stasis_app. (closes issue ASTERISK-23295) Review: https://reviewboard.asterisk.org/r/3336/ ........ Merged revisions 410527 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410528 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Scott Griepentrog	80ef9a21b9	uniqueid: channel linkedid, ami, ari object creation with id's ... Much needed was a way to assign id to objects on creation, and much change was necessary to accomplish it. Channel uniqueids and linkedids are split into separate string and creation time components without breaking linkedid propgation. This allowed the uniqueid to be specified by the user interface - and those values are now carried through to channel creation, adding the assignedids value to every function in the chain including the channel drivers. For local channels, the second channel can be specified or left to default to a ;2 suffix of first. In ARI, bridge, playback, and snoop objects can also be created with a specified uniqueid. Along the way, the args order to allocating channels was fixed in chan_mgcp and chan_gtalk, and linkedid is no longer lost as masquerade occurs. (closes issue ASTERISK-23120) Review: https://reviewboard.asterisk.org/r/3191/ ........ Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	e5899852cc	res_stasis: Enable transfers and provide events when they occur. ... This change enables transfers within ARI created bridges and adds events for when they occur. Unlike other events these will be received if *any* subscribed object is involved in the transfer. (closes issue ASTERISK-22984) Reported by: David M. Lee Review: https://reviewboard.asterisk.org/r/3120/ ........ Merged revisions 407153 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407154 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kevin Harwell	28c0cb28d0	channel locking: Add locking for channel snapshot creation ... Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	b0bb03e916	bridging: Give bridges a name and a known creator ... Bridges have two new optional properties, a creator and a name. Certain consumers of bridges will automatically provide bridges that they create with these properties. Examples include app_bridgewait, res_parking, app_confbridge, and app_agent_pool. In addition, a name may now be provided as an argument to the POST function for creating new bridges via ARI. (closes issue AFS-47) Review: https://reviewboard.asterisk.org/r/3070/ ........ Merged revisions 404042 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404043 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	1212906351	Reverting r403311. It's causing ARI tests to hang. ... ........ Merged revisions 403398 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403404 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago