91 Commits (85ffedabd1306822bf38ad6ad408a586d89ba0fc)

Author	SHA1	Message	Date
Corey Farrell	c1a608f862	res_stasis: Fix multiple leaks. ... * res/stasis/app.c JSON passed to app_send needs to be released. * res/stasis_message.c: objects leak if vector append fails. Change-Id: I8dd5385b9f50a5cadf2b1d16efecffd6ddb4db4a	8 years ago
Richard Mudgett	33d02f5090	stasis/app.c: Optimize stasis_app_get_debug_by_name() ... * Eliminate RAII_VAR() * Short circuit application name lookup if global debug enabled. Change-Id: I5f78b7bd6ca7fd2c3b07cbbe036c6a93b4681123	8 years ago
Richard Mudgett	3bce5a9dfa	Stasis/ARI: Fix off-nominal path json memory leaks. ... Change-Id: Id569c624c426e3b22a99936473c730592d8b83fb	8 years ago
George Joseph	186ef1a657	stasis/control: Fix possible deadlock with swap channel ... If an error occurs during a bridge impart it's possible that the "bridge_after" callback might try to run before control_swap_channel_in_bridge has been signalled to continue. Since control_swap_channel_in_bridge is holding the control lock and the callback needs it, a deadlock will occur. * control_swap_channel_in_bridge now only holds the control lock while it's actually modifying the control structure and releases it while the bridge impart is running. * bridge_after_cb is now tolerant of impart failures. Change-Id: Ifd239aa93955b3eb475521f61e284fcb0da2c3b3	8 years ago
George Joseph	cb504ad6ae	Merge "ari: Implement 'debug all' and request/response logging" into 13	8 years ago
Richard Mudgett	00a227e93d	stasis_bridge.c: Fix off-nominal stasis control ref leak. ... Change-Id: Ib17218343a6596832060180e19386da9df150ac8	9 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	9 years ago
Matt Jordan	d23b4af477	res/ari/resource_bridges: Add the ability to manipulate the video source ... In multi-party bridges, Asterisk currently supports two video modes: * Follow the talker, in which the speaker with the most energy is shown to all participants but the speaker, and the speaker sees the previous video source * Explicitly set video sources, in which all participants see a locked video source Prior to this patch, ARI had no ability to manipulate the video source. This isn't important for two-party bridges, in which Asterisk merely relays the video between the participants. However, in a multi-party bridge, it can be advantageous to allow an external application to manipulate the video source. This patch provides two new routes to accomplish this: (1) setVideoSource: POST /bridges/{bridgeId}/videoSource/{channelId} Sets a video source to an explicit channel (2) clearVideoSource: DELETE /bridges/{bridgeId}/videoSource Removes any explicit video source, and sets the video mode to talk detection ASTERISK-26595 #close Change-Id: I98e455d5bffc08ea5e8d6b84ccaf063c714e6621	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
Matt Jordan	42cfdcd1b7	res/ari: Add the Asterisk EID field to outgoing events ... This patch adds the Asterisk EID field to all outgoing ARI events. Because this field should be added to all events as they are transmitted, it is appended to the JSON message just prior to it being handed off to the application message handler. This makes it somewhat resilient to both new events being added to ARI, as well as other potential event transport mechanisms. ASTERISK-26470 #close Change-Id: Ieff0ecc24464e83f3f44e9c3e7bd9a5d70b87a1d	9 years ago
Richard Mudgett	3c54328c57	Audit ast_json_pack() calls for needed UTF-8 checks. ... Added needed UTF-8 checks before constructing json objects in various files for strings obtained outside the system. In this case string values from a channel driver's peer and not from the user setting channel variables. * aoc.c: Fixed type mismatch in s_to_json() for time and granularity json object construction. ASTERISK-26466 Reported by: Richard Mudgett Change-Id: Iac2d867fa598daba5c5dbc619b5464625a7f2096	9 years ago
Richard Mudgett	a036c35903	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	9 years ago
Richard Mudgett	724acb6ce7	stasis_bridge.c: Update stasis bridge push diagnostic messages. ... Change-Id: I195b14994c9dcccb9452491ca20a885d2a54605a	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
Mark Michelson	4a3275abb9	Stasis: Use custom structure when setting variables. ... A recent change to queue channel variable setting to the Stasis control queue caused a regression. When setting channel variables, it is possible to give a NULL channel variable value in order to unset the variable (i.e. remove it from the channel variable list). The change introduced a call to ast_variable_new(), which is not tolerant of NULL channel variable values. This new change switches from using ast_variable to using a custom channel variable struct that is lighter weight and NULL value-tolerant. Change-Id: I784d7beaaa3c036ea936d103e7caf0bb1562162d	10 years ago
Joshua Colp	fcb6c1737d	Merge "Stasis: Use control queue to prevent crash." into 13	10 years ago
Mark Michelson	1003c2eb05	Stasis: Fix potential memory leak of control data. ... When queuing tasks onto the Stasis control queue, you can pass an arbitrary data pointer and a function to free that data. All ARI commands that use the Stasis control queue made the assumption that the destructor function would be called in all paths, whether the task was queued successfully or not. However, this was not correct. If a task was queued onto a control structure that was already completed, the allocated data would not be freed properly. This patch corrects this by making sure that all return paths call the data destructor. Change-Id: Ibf06522094f8e5c4cce652537dc5d7222b1c4fcb	10 years ago
Mark Michelson	eedd77fda0	Stasis: Use control queue to prevent crash. ... A crash occurred when attempting to set a channel variable on a channel that had already been hung up. This is because there is a small window between when a control is grabbed and when the channel variable is set that the channel can be hung up. The fix here is to queue the setting of the channel variable onto the control queue. This way, the manipulation of the channel happens in a thread where it is safe to be done. In this change, I also noticed that the setting of bridge roles on channels was being done outside of the control queue, so I also changed those operations to be done in the control queue. ASTERISK-25709 #close Reported by Mark Michelson Change-Id: I2a0a4d51bce6fba6f1d9954e40935e42f366ea78	10 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	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
Matt Jordan	5ac65ddfb4	res/ari: Register Stasis application on WebSocket attempt ... Prior to this patch, when a WebSocket connection is made, ARI would not be informed of the connection until after the WebSocket layer had accepted the connection. This created a brief race condition where the ARI client would be notified that it was connected, a channel would be sent into the Stasis dialplan application, but ARI would not yet have registered the Stasis application presented in the HTTP request that established the WebSocket. This patch resolves this issue by doing the following: * When a WebSocket attempt is made, a callback is made into the ARI application layer, which verifies and registers the apps presented in the HTTP request. Because we do not yet have a WebSocket, we cannot have an event session for the corresponding applications. Some defensive checks were thus added to make the application objects tolerant to a NULL event session. * When a WebSocket connection is made, the registered application is updated with the newly created event session that wraps the WebSocket connection. ASTERISK-24988 #close Reported by: Joshua Colp Change-Id: Ia5dc60dc2b6bee76cd5aff0f69dd53b36e83f636	10 years ago
Matthew Jordan	1995baad71	ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app ... This patch adds a new feature to ARI to redirect a channel to another server, and fixes a few bugs in PJSIP's handling of the Transfer dialplan application/ARI redirect capability. *New Feature* A new operation has been added to the ARI channels resource, redirect. With this, a channel in a Stasis application can be redirected to another endpoint of the same underlying channel technology. *Bug fixes* In the process of writing this new feature, two bugs were fixed in the PJSIP stack: (1) The existing .transfer channel callback had the limitation that it could only transfer channels to a SIP URI, i.e., you had to pass 'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is still supported, it is somewhat unintuitive - particularly in a world full of endpoints. As such, we now also support specifying the PJSIP endpoint to transfer to. (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by updating its Contact header. Alas, that resulted in the forwarding destination set by the dialplan application/ARI resource/whatever being rewritten with very incorrect information. Hence, we now don't bother updating an outgoing response if it is a 302. Since this took a looong time to find, some additional debug statements have been added to those modules that update the Contact headers. Review: https://reviewboard.asterisk.org/r/4316/ ASTERISK-24015 #close Reported by: Private Name ASTERISK-24703 #close Reported by: Matt Jordan git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431717 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Scott Griepentrog	f7d23dfcc6	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/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431450 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Scott Griepentrog	bdfdb01bcf	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/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430939 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	93b1df3bf6	Add new AMI and ARI events for connected line changes on a channel. ... The AMI event is called NewConnectedLine and the ARI event is called ChannelConnectedLine. ASTERISK-24554 #close Reported by Matt Jordan Review: https://reviewboard.asterisk.org/r/4231 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429064 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
Mark Michelson	1536b0ecb6	Fix race condition that could result in ARI transfer messages not being sent. ... From reviewboard: "During blind transfer testing, it was noticed that tests were failing occasionally because the ARI blind transfer event was not being sent. After investigating, I detected a race condition in the blind transfer code. When blind transferring a single channel, the actual transfer operation (i.e. removing the transferee from the bridge and directing them to the proper dialplan location) is queued onto the transferee bridge channel. After queuing the transfer operation, the blind transfer Stasis message is published. At the time of publication, snapshots of the channels and bridge involved are created. The ARI subscriber to the blind transfer Stasis message then attempts to determine if the bridge or any of the involved channels are subscribed to by ARI applications. If so, then the blind transfer message is sent to the applications. The way that the ARI blind transfer message handler works is to first see if the transferer channel is subscribed to. If not, then iterate over all the channel IDs in the bridge snapshot and determine if any of those are subscribed to. In the test we were running, the lone transferee channel was subscribed to, so an ARI event should have been sent to our application. Occasionally, though, the bridge snapshot did not have any channels IDs on it at all. Why? The problem is that since the blind transfer operation is handled by a separate thread, it is possible that the transfer will have completed and the channels removed from the bridge before we publish the blind transfer Stasis message. Since the blind transfer has completed, the bridge on which the transfer occurred no longer has any channels on it, so the resulting bridge snapshot has no channels on it. Through investigation of the code, I found that attended transfers can have this issue too for the case where a transferee is transferred to an application." The fix employed here is to decouple the creation of snapshots for the transfer messages from the publication of the transfer messages. This way, snapshots can be created to reflect what they are at the time of the transfer operation. Review: https://reviewboard.asterisk.org/r/4135 ........ Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427870 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	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	5de3fa2c60	Ensure after-bridge behavior is correct when moving from Stasis to a non-Stasis bridge. ... Because of the departable state of channels that enter Stasis bridges, Stasis has to take responsibility for directing the channel to its intended after-bridge destination if the channel moves from a Stasis bridge to a non-Stasis bridge. This change ensures that when such a move occurs, when the channel leaves the bridging system, any after bridge gotos are honored. Review: https://reviewboard.asterisk.org/r/3920 ........ Merged revisions 421792 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421794 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	bc0536e009	Clean up files that do not end with newlines ... Trivial patch to add new lines to several files missing them. This fixes warnings when compiling with gcc 4.1.2 on CentOS 5. ASTERISK-24245 #close Reported by: Shaun Ruffell patches: 0002-Trivial-addition-of-newlines-at-end-of-three-files.patch uploaded by Shaun Ruffell (License 5417) ........ Merged revisions 421677 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421678 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	04f478212c	Stasis: Add information to blind transfer event ... When a blind transfer occurs that is forced to create a local channel pair to satisfy the transfer request, information about the local channel pair is not published. This adds a field to describe that channel to the blind transfer message struct so that this information is conveyed properly to consumers of the blind transfer message. This also fixes a bug in which Stasis() was unable to properly identify the channel that was replacing an existing Stasis-controlled channel due to a blind transfer. Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3921/ ........ Merged revisions 421537 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421538 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	a0b7f2ce42	res/stasis/command.c: Fix recent commit using spaces instead of tabs. ... ........ Merged revisions 420836 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420837 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
Mark Michelson	ef70c08dc7	Improve call forwarding reporting, especially with regards to ARI. ... This patch addresses a few issues: 1) The order of Dial events have been changed when performing a call forward. The order has now been altered to 1) Dial begins dialing channel A. 2) When A forwards the call to B, we issue the dial end event to channel A, indicating the dial is being canceled due to a forward to B. 3) When the call to channel B occurs, we then issue a new dial begin to channel B. 2) Call forwards are now reported on the calling channel, not the peer channel. 3) AMI DialEnd events have been altered to display the extension the call is being forwarded to when relevant. 4) You can now get the values of channel variables for channels that are not currently in the Stasis application. This brings the retrieval of channel variables more in line with the rest of channel read operations since they may be performed on channels not in Stasis. ASTERISK-24134 #close Reported by Matt Jordan ASTERISK-24138 #close Reported by Matt Jordan Patches: forward-shenanigans.diff uploaded by Matt Jordan (License #6283) Review: https://reviewboard.asterisk.org/r/3899 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420794 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
Matthew Jordan	ac5c75b45d	stasis: Fix compilation issue with ao2 tagged objects ... ........ Merged revisions 420099 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420100 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
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
Joshua Colp	10f4d0f65d	res_stasis: Add progress indications to operations which perform media. ... This change fixes operations which did not account for the fact that they may be executed on channels which have not been answered. These operations will now indicate progress when invoked. ASTERISK-23560 #close ASTERISk-23560 #comment Reported by: Jan Svoboda Review: https://reviewboard.asterisk.org/r/3495/ ........ Merged revisions 413121 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413122 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	9b71a87108	res_stasis: Fix crash when handling a failed blind transfer message. ... This changes fixes a crash that occurs when stasis determines if it should send a message out to an application or not. The code incorrectly assumed that a bridge snapshot would always be present when in reality for failure cases it may not be. ASTERISK-23573 #close ........ Merged revisions 412882 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412883 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
Richard Mudgett	45ade68cb4	Remove unused RAII_VAR() declarations. ... * Remove unused RAII_VAR() declarations. The compiler cannot catch these because the cleanup function "references" the unused variable. Some actually allocated and released resources that were never used. * Fixed some whitespace issues in stasis_bridges.c. ........ Merged revisions 412399 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412400 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	2c5484c869	stasis/app.c: Add some extra debugging for subscription counts ... Events are sent to a connected ARI application based on the things that ARI application cares about. These subscriptions can be set up implicitly - such as when that ARI application creates a new object - or explicitly, via the application resource's subscription operations. Debugging *why* something was being sent to an application - or why something was not being sent to an application - was a bit tricky, as there was no debug information for the subscriptions. This patch adds some debug level 3 statements that show the subscription counts for applications. (Level 3 was chosen as it matches the verbose level 3 statements elsewhere) ........ Merged revisions 410650 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410651 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