72 Commits (6fb811a5905a54a07a901b25f8f3af0ad9d3f7c9)

Author	SHA1	Message	Date
Sven Kube	f0ac136a8b	ARI: Add command to indicate progress to a channel ... Adds an ARI command to send a progress indication to a channel. DeveloperNote: A new ARI endpoint is available at `/channels/{channelId}/progress` to indicate progress to a channel.	2 months ago
Mike Bradeen	8924258639	stasis/control.c: Set Hangup Cause to No Answer on Dial timeout ... Other Dial operations (dial, app_dial) use Q.850 cause 19 when a dial timeout occurs, but the Dial command via ARI did not set an explicit reason. This resulted in a CANCEL with Normal Call Clearing and corresponding ChannelDestroyed. This change sets the hangup cause to AST_CAUSE_NO_ANSWER to be consistent with the other operations. Fixes: #963 UserNote: A Dial timeout on POST /channels/{channelId}/dial will now result in a CANCEL and ChannelDestroyed with cause 19 / User alerting, no answer. Previously no explicit cause was set, resulting in a cause of 16 / Normal Call Clearing.	6 months ago
George Joseph	f302c116b4	Prequisites for ARI Outbound Websockets ... stasis: * Added stasis_app_is_registered(). * Added stasis_app_control_mark_failed(). * Added stasis_app_control_is_failed(). * Fixed res_stasis_device_state so unsubscribe all works properly. * Modified stasis_app_unregister() to unsubscribe from all event sources. * Modified stasis_app_exec to return -1 if stasis_app_control_is_failed() returns true. http: * Added ast_http_create_basic_auth_header(). md5: * Added define for MD5_DIGEST_LENGTH. tcptls: * Added flag to ast_tcptls_session_args to suppress connection log messages to give callers more control over logging. http_websocket: * Add flag to ast_websocket_client_options to suppress connection log messages to give callers more control over logging. * Added username and password to ast_websocket_client_options to support outbound basic authentication. * Added ast_websocket_result_to_str().	6 months ago
Mike Bradeen	a824a0cdb4	res_stasis: fix intermittent delays on adding channel to bridge ... Previously, on command execution, the control thread was awoken by sending a SIGURG. It was found that this still resulted in some instances where the thread was not immediately awoken. This change instead sends a null frame to awaken the control thread, which awakens the thread more consistently. Resolves: #801	1 year ago
Fabrice Fontaine	7fc25285fa	res/stasis/control.c: include signal.h ... Include signal.h to avoid the following build failure with uclibc-ng raised since 2694792e13: stasis/control.c: In function 'exec_command_on_condition': stasis/control.c:313:3: warning: implicit declaration of function 'pthread_kill'; did you mean 'pthread_yield'? [-Wimplicit-function-declaration] 313 | pthread_kill(control->control_thread, SIGURG); | ^~~~~~~~~~~~ | pthread_yield stasis/control.c:313:41: error: 'SIGURG' undeclared (first use in this function) 313 | pthread_kill(control->control_thread, SIGURG); | ^~~~~~ cherry-pick-to: 18 cherry-pick-to: 20 cherry-pick-to: 21 Fixes: #729	1 year ago
Mike Bradeen	2694792e13	res_stasis: signal when new command is queued ... res_statsis's app loop sleeps for up to .2s waiting on input to a channel before re-checking the command queue. This can cause delays between channel setup and bridge. This change is to send a SIGURG on the sleeping thread when a new command is enqueued. This exits the sleeping thread out of the ast_waitfor() call triggering the new command being processed on the channel immediately. Resolves: #362 UserNote: Call setup times should be significantly improved when using ARI.	2 years ago
Jean Aunis	034ac357ad	ARI: Ability to inhibit COLP frames when adding channels to a bridge ... This patch adds a new flag "inhibitConnectedLineUpdates" to the 'addChannel' operation in the Bridges REST API. When set, this flag avoids generating COLP frames when the specified channels enter the bridge. ASTERISK-28629 Change-Id: Ib995d4f0c6106279aa448b34b042b68f0f2ca5dc	6 years ago
Kevin Harwell	bdd785d31c	various files - fix some alerts raised by lgtm code analysis ... This patch fixes several issues reported by the lgtm code analysis tool: https://lgtm.com/projects/g/asterisk/asterisk Not all reported issues were addressed in this patch. This patch mostly fixes confirmed reported errors, potential problematic code points, and a few other "low hanging" warnings or recommendations found in core supported modules. These include, but are not limited to the following: * innapropriate stack allocation in loops * buffer overflows * variable declaration "hiding" another variable declaration * comparisons results that are always the same * ambiguously signed bit-field members * missing header guards Change-Id: Id4a881686605d26c94ab5409bc70fcc21efacc25	6 years ago
agupta	85242a9bb9	stasis: Hangup channel for Local channel No such extension error ... When we use early bridge with create and dial from stasis using Local channel and the dialplan does not any entry the it is returned from core_local.c with No such extension . In such case asterisk locks up till the channel is not hangup with the error Exceptionally long voice queue length * Found that in such case app_control_dial fails on ast_call method and return -1 * Since it is called from stasis_app_send_command_async and return -1 does not cause resources to be freed and since no PBX exist it is not able to read from channel causing exceptionally long queue * After putting this code found that the channel was releasing immediately and resources were freed. ASTERISK-28399 Reported by: Abhay Gupta Tested by: Abhay Gupta Change-Id: I0a55c923fc6995559f808d63b9488762b4489318	7 years ago
agupta	71040078a3	stasis: Only place stasis created and dialed channels into dial bridge. ... The dial bridge is meant to hold channels which have been created and dialed in stasis. It handles the frames coming from them and raises the appropriate events. It was possible for the code to mistakenly place calls which came from the dialplan into the dial bridge if they were not in an answered state. These channels are not outgoing channels and should not be placed into the dial bridge. The code now checks to ensure that only stasis created channels are placed into the dial bridge by checking that a PBX does not exist on the channel. ASTERISK-27756 Change-Id: Ideee69ff06c9a0b31f7ed61165f5c055f51d21b6	7 years ago
Joshua Colp	1d074debfb	stasis: Allow empty application arguments to move. ... Change-Id: I1e4d37415f3034abe36496dc30209c2303e6af5c	7 years ago
Ben Ford	6626df586e	res_stasis: Add ability to switch applications. ... Added the ability to move between Stasis applications within Stasis. This can be done by calling 'move' in an application, providing (at minimum) the channel's id and the application to switch to. If the application is not registered or active, nothing will happen and the channel will remain in the current application, and an event will be triggered to let the application know that the move failed. The event name is "ApplicationMoveFailed", and provides the "destination" that the channel was attempting to move to, as well as the usual channel information. Optionally, a list of arguments can be passed to the function call for the receiving application. A full example of a 'move' call would look like this: client.channels.move(channelId, app, appArgs) The control object used to control the channel in Stasis can now switch which application it belongs to, rather than belonging to one Stasis application for its lifetime. This allows us to use the same control object instead of having to tear down the current one and create another. ASTERISK-28267 #close Change-Id: I43d12b10045a98a8d42541889b85695be26f288a	7 years ago
Joshua Colp	d0ccbb3377	stasis: Use an implementation specific channel snapshot cache. ... Channels no longer use the Stasis cache for channel snapshots. Instead they are stored in a hash table in stasis_channels which reduces the number of Stasis messages created and allows better storage. As a result the following APIs are no longer available since the stasis cache is no longer used: ast_channel_topic_cached() ast_channel_topic_all_cached() The ast_channel_cache_all() and ast_channel_cache_by_name() functions now return an ao2_container of ast_channel_snapshots rather than a container of stasis_messages therefore you can't (and don't need to) call stasis_cache functions on it. The ast_channel_topic_all() function now returns a normal topic not a cached one so you can't use stasis cache functions on it either. The ast_channel_snapshot_type() stasis message now has the ast_channel_snapshot_update structure as it's data. It contains the last snapshot and the new one. ast_channel_snapshot_get_latest() still returns the latest snapshot. The latest snapshot is now stored on the channel itself to eliminate cache hits when Stasis messages that have the snapshot as a payload are created. ASTERISK-28102 Change-Id: I9334febff60a82d7c39703e49059fa3a68825786	7 years ago
Richard Mudgett	da54605b8a	ARI POST DTMF: Make not compete with channel's media thread. ... There can be one and only one thread handling a channel's media at a time. Otherwise, we don't know which thread is going to handle the media frames. ASTERISK-27625 Change-Id: I4d6a2fe7386ea447ee199003bf8ad681cb30454e	7 years ago
Joshua Colp	f2c583624b	Merge "res_stasis: Reduce RAII_VAR usage."	8 years ago
Corey Farrell	55a540272f	res_stasis: Reduce RAII_VAR usage. ... In addition to being a micro-optimization (RAII_VAR has overhead), this change improves output of REF_DEBUG. Unfortunately when RAII_VAR calls ao2_cleanup it does so from a generated _dtor_varname function. For example this caused _dtor_app to release a reference instead of __stasis_app_unregister. Change-Id: I4ce67120583a446babf9adeec678b71d37fcd9e5	8 years ago
Corey Farrell	8b3083cac5	res_stasis: Fix dial bridge unload. ... If the dial bridge has been created it must be released by calling ast_bridge_destroy, simply releasing the ao2 reference is not enough. Also move stasis_app_control_shutdown earlier in unload to ensure the bridge cannot be created or grabbed after the app_bridges container is released. Change-Id: I372302de94ca63876069e2585a049c5060e5e767	8 years ago
Corey Farrell	1b80ffa495	Fix Common Typo's. ... Fix instances of: * Retreive * Recieve * other then * different then * Repeated words ("the the", "an an", "and and", etc). * othterwise, teh ASTERISK-24198 #close Change-Id: I3809a9c113b92fd9d0d9f9bac98e9c66dc8b2d31	8 years ago
Seán C McCord	e8bde6916a	ari/bridge: Add mute, dtmf suppression controls ... Add bridge_features structure to bridge creation. Specifically, this implements mute and DTMF suppression, but others should be able to be easily added to the same structure. ASTERISK-27322 #close Reported by: Darren Sessions Sponsored by: AVOXI Change-Id: Id4002adfb65c9a8027ee9e1a5f477e0f01cf9d61	8 years ago
Jenkins2	2f03e11b0e	Merge "stasis/control.c: Fix set_interval_hook() ref leak."	8 years ago
Richard Mudgett	23571f31ac	stasis/control.c: Fix set_interval_hook() ref leak. ... Change-Id: Ia0edb7dc0dbbb879c079ff7000f1b722d86ce7dc	8 years ago
George Joseph	94091c7b96	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
Corey Farrell	a6e5bae3ef	Remove ASTERISK_REGISTER_FILE. ... ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes all traces of it. Previously exported symbols removed: * __ast_register_file * __ast_unregister_file * ast_complete_source_filename This also removes the mtx_prof static variable that was declared when MTX_PROFILE was enabled. This variable was only used in lock.c so it is now initialized in that file only. ASTERISK-26480 #close Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966	9 years ago
George Joseph	886f2cab23	rest_api/channels: Fix multiple issues with create and dial ... * We weren't properly subscribing to the channel and it's originator on create. * We weren't doing a publish_dial after calling ast_call on dial. * We weren't calling depart_bridge when a channel left the dial bridge. The first 2 issues were causing events to not be generated and the third was actually causing channels to not get properly destroyed when hung up. Together these 3 issues were causing the new rest_apichannels/create_dial_bridge tests to fail. As a result of the fixes, the cdr state machine had to be slightly tweaked to allow bridge leave events without asserting and the tests themselves had to be updated to account for the channels now cleaning themselves up. Change-Id: Ibf23abf5a62de76e82afb4461af5099c961b97d8	9 years ago
Mark Michelson	88d997913f	ARI: Re-implement the ARI dial command, allowing for early bridging. ... ARI dial had been implemented using the Dial API. This made great sense when dialing was 100% separate from bridging. However, if a channel were to be added to a bridge during the dial attempt, there would be a conflict between the dialing thread and the bridging thread. Each would be attempting to read frames from the dialed channel and act on them. The initial attempt to make the two play nice was to have the Dial API suspend the channel in the bridge and stay in charge of the channel until the dial was complete. The problem with this was that it was riddled with potential race conditions. It also was not well-suited for the case where the channel changed which bridge it was in during the dial. This new approach removes the use of the Dial API altogether. Instead, the channel we are dialing is placed into an invisible ARI dialing bridge. The bridge channel thread handles incoming frames from the channel. If the channel is added to a real bridge, it is departed from the invisible bridge and then added to the real bridge. Similarly, if the channel is removed from the real bridge, it is automatically added back to the invisible bridge if the dial attempt is still active. This approach keeps the threading simple by always having the channel being handled by bridge channel threads. ASTERISK-25925 Change-Id: I7750359ddf45fcd45eaec749c5b3822de4a8ddbb	10 years ago
Richard Mudgett	6b1a632290	res_stasis: Handle re-enter stasis bridge with swap channel. ... We lose the fact that there is a swap channel if there is one. We currently wind up rejoining the stasis bridge as a normal join after the swap channel has already been kicked from the bridge. This patch preserves the swap channel so the AMI/ARI events can note that the channel joining the bridge is swapping with another channel. Another benefit to swaqpping in one operation is if there are any channels that get lonely (MOH, bridge playback, and bridge record channels). The lonely channels won't leave before the joining channel has a chance to come back in under stasis if the swap channel is the only reason the lonely channels are staying in the bridge. ASTERISK-25947 #close Reported by: Richard Mudgett ASTERISK-24649 Reported by: John Bigelow ASTERISK-24782 Reported by: John Bigelow Change-Id: If37ea508831d1fed6dbfac2f191c638fc0a850ee	10 years ago
Joshua Colp	72ef79dc2d	Merge "ARI: Add method to Dial a created channel."	10 years ago
Mark Michelson	abbb2edd4c	ARI: Add method to Dial a created channel. ... This adds a new ARI method that allows for you to dial a channel that you previously created in ARI. By combining this with the create method for channels, it allows for a workflow where a channel can be created, manipulated, and then dialed. The channel is under control of the ARI application during all stages of the Dial and can even be manipulated based on channel state changes observed within an ARI application. The overarching goal for this is to eventually be able to add a dialed channel to a Stasis bridge earlier than the "Up" state. However, at the moment more work is needed in the Dial and Bridge APIs in order to facilitate that. ASTERISK-25889 #close Change-Id: Ic6c399c791e66c4aa52454222fe4f8b02483a205	10 years ago
Richard Mudgett	0ea742d33a	res_stasis: Add control ref to playback and recording structs. ... The stasis_app_playback and stasis_app_recording structs need to have a struct stasis_app_control ref. Other threads can get a reference to the playback and recording structs from their respective global container. These other threads can then use the control pointer they contain after the control struct has gone. * Add control ref to stasis_app_playback and stasis_app_recording structs. With the refs added, the control command queue can now have a circular control reference which will cause the control struct to never get released if the control's command queue is not flushed when the channel leaves the Stasis application. Also the command queue needs better protection from adding commands if the control->is_done flag is set. * Flush the control command queue on exit. ASTERISK-25882 #close Change-Id: I3cf1fb59cbe6f50f20d9e35a2c07ac07d7f4320d	10 years ago
Richard Mudgett	53f63ad770	res_stasis: Fix crash on a hanging up channel. ... * Give the struct stasis_app_control ao2 object a ref to the channel held in the object. Now the channel will still be around if a thread needs to post a stasis message instead of crash because the topic was destroyed. * Moved stopping any lingering silence generator out of the struct stasis_app_control destructor and made it a part of exiting the Stasis application. Who knows which thread the destructor will be called under so it cannot affect the channel's silence generator. Not only was the channel unprotected when the silence generator was stopped, stasis may no longer even control the channel. ASTERISK-25882 Change-Id: I21728161b5fe638cef7976fa36a605043a7497e4	10 years ago
Mark Michelson	a706ad44e6	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	8c75371589	Merge "Stasis: Use control queue to prevent crash."	10 years ago
Mark Michelson	959f7436cc	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	a45eacebf3	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
Mark Michelson	d7a1e84a1e	Resolve race conditions involving Stasis bridges. ... This resolves two observed race conditions. First, a bit of background on what the Stasis application does: 1a Creates a stasis_app_control structure. This structure is linked into a global container and can be looked up using a channel's unique ID. 2a Puts the channel in an event loop. The event loop can exit either because the stasis_app_control structure has been marked done, or because of some other factor, such as a hangup. In the event loop, the stasis_app_control determines if any specific ARI commands need to be run on the channel and will run them from this thread. 3a Checks if the channel is bridged. If the channel is bridged, then ast_bridge_depart() is called since channels that are added to Stasis bridges are always imparted as departable. 4a Unlink the stasis_app_control from the container. When an ARI command is received by Asterisk, the following occurs 1b A thread is spawned to handle the HTTP request 2b The stasis_app_control(s) that corresponds to the channel(s) in the request is/are retrieved. If the stasis_app_control cannot be retrieved, then it is assumed that the channel in question has exited the Stasis app or perhaps was never in Stasis in the first place. 3b A command is queued onto the stasis_app_control, and the channel's event loop thread is signaled to run the command. 4b While most ARI commands do nothing further, some, such as adding or removing channels from a bridge, will block until the command they issued has been completed by the channel's event loop. The first race condition that is solved by this patch involves a crash that can occur due to faulty detection of the channel's bridged status in step 3a. What can happen is that in step 2a, the event loop may run the ast_bridge_impart() function to asynchronously place the channel into a bridge, then immediately exit the event loop because the channel has hung up. In step 3a, we would detect that the channel was not bridged and would not call ast_bridge_depart(). The reason that the channel did not appear to be bridged was that the depart_thread that is spawned by ast_bridge_impart() had not yet started. That is the thread where the channel is marked as being bridged. Since we did not call ast_bridge_depart(), the Stasis application would exit, and then the channel would be destroyed Then the depart_thread would start up and try to manipulate the destroyed channel, causing a crash. The fix for this is to switch from using ast_channel_is_bridged() to checking the NULLity of ast_channel_internal_bridge_channel() to determine if ast_bridge_depart() needs to be called. The channel's internal bridge_channel is set when ast_bridge_impart() is called and is NULLed by the call to ast_bridge_depart(). If the channel's internal bridge_channel is non-NULL, then the channel must have been imparted into the bridge and needs to be departed, even if the actual bridging operation has not yet started. By departing the channel when necessary, the thread that is running the Stasis application will block until the bridge gives the okay that the depart_thread has exited. The second race condition that is solved by this patch involves a leak of HTTP handler threads. The problem was that step 2b would successfully retrieve a stasis_app_control structure. Then step 2a would exit the channel from the event loop due to a hangup. Steps 3a and 4a would execute, and then finally steps 3b and 4b would. The problem is that at step 4b, when attempting to add a channel to a bridge, the thread would block forever since the channel would never execute the queued command since it was finished with the event loop. This meant that the HTTP handling thread would be leaked, along with any references that thread may have owned (in my case, I was seeing bridges leaked). The fix for this is to hone in better on when the channel has exited the event loop. The stasis_app_control structure has an is_done field that is now set at each point where the channel may exit the event loop. If step 2b retrieves a valid stasis_app_control structure but the control is marked as done, then the attempted operation exits immediately since there will be nothing to service the attempted command. ASTERISK-25091 #close Reported by Ilya Trikoz Change-Id: If66265b73b4c9f8f58599124d777fedc54576628	10 years ago
Joerg Sonnenberger	9472bbaa95	Remove const cast from leaf functions. ... app_control_register_rule and app_control_unregister_rule lock/unlock the queue, which is a mutating operation according to the ao2_lock/_unlock prototype. Depending on the specific (implicit) casts in SCOPED_LOCK and RAII_VAR, the compiler may warn or not. As the only callers of those functions do not have the const, get consistent results by just dropping it. Change-Id: Ib9e6296155a39bc5d627142a3828180c3cfe8fbb	11 years ago
Matt Jordan	4a58261694	git migration: Refactor the ASTERISK_FILE_VERSION macro ... Git does not support the ability to replace a token with a version string during check-in. While it does have support for replacing a token on clone, this is somewhat sub-optimal: the token is replaced with the object hash, which is not particularly easy for human consumption. What's more, in practice, the source file version was often not terribly useful. Generally, when triaging bugs, the overall version of Asterisk is far more useful than an individual SVN version of a file. As a result, this patch removes Asterisk's support for showing source file versions. Specifically, it does the following: * Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and remove passing the version in with the macro. Other facilities than 'core show file version' make use of the file names, such as setting a debug level only on a specific file. As such, the act of registering source files with the Asterisk core still has use. The macro rename now reflects the new macro purpose. * main/asterisk: - Refactor the file_version structure to reflect that it no longer tracks a version field. - Remove the "core show file version" CLI command. Without the file version, it is no longer useful. - Remove the ast_file_version_find function. The file version is no longer tracked. - Rename ast_register_file_version/ast_unregister_file_version to ast_register_file/ast_unregister_file, respectively. * main/manager: Remove value from the Version key of the ModuleCheck Action. The actual key itself has not been removed, as doing so would absolutely constitute a backwards incompatible change. However, since the file version is no longer tracked, there is no need to attempt to include it in the Version key. * UPGRADE: Add notes for: - Modification to the ModuleCheck AMI Action - Removal of the "core show file version" CLI command Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e	11 years ago
Matthew Jordan	29f66b0429	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 ........ Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Jonathan Rose	33835e17a0	ARI: Fix a crash caused by hanging during playback to a channel in a bridge ... ASTERISK-24147 #close Reported by: Edvin Vidmar Review: https://reviewboard.asterisk.org/r/3908/ ........ Merged revisions 421879 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 421880 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421881 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	56a1d4930a	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 ........ Merged revisions 421794 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421795 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	ba5d5da60b	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 ........ Merged revisions 420794 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421310 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
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	12 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	12 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	12 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	12 years ago
Kevin Harwell	ce18946de4	ARI: Adding a channel to a bridge while a live recording is active blocks ... Added the ability to have rules that are checked when adding and/or removing channels to/from a bridge. In this case, if a channel is currently recording and someone attempts to add it to a bridge an "is recording" rule is checked, fails, and a 409 conflict is returned. Also command functions now return an integer value that can be descriptive of what kind of problems, if any, occurred before or during execution. (closes issue ASTERISK-22624) Reported by: Joshua Colp Review: https://reviewboard.asterisk.org/r/2947/ ........ Merged revisions 403749 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403750 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	fc70db3a81	ari: Fix deadlock problem with functions that use autoservice. ... The code for getting channel variables from ARI assumed that you needed to lock the channel in order to properly execute functions and read channel variables. Apparently, this is not the case, since any dialplan function that puts the channel into autoservice deadlocks when attempting to remove the channel from autoservice. ........ Merged revisions 403342 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403403 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	d1ad4a95f8	ari: Add silence generator controls ... This patch adds the ability to start a silence generator on a channel via ARI. This generator will play silence on the channel (avoiding audio timeouts on the peer) until it is stopped, or some other media operation is started (like playing media, starting music on hold, etc.). (closes issue ASTERISK-22514) Review: https://reviewboard.asterisk.org/r/3019/ ........ Merged revisions 402926 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402928 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	67b650543c	res_ari_channels: Add the ability to stop locally generated ringing on a channel. ... Using the 'ring' operation it is possible to start locally generated ringback if the channel is answered. This change adds the ability to stop it by using DELETE. ........ Merged revisions 402804 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402805 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago