summaryrefslogtreecommitdiff
path: root/main/features.c
AgeCommit message (Collapse)Author
2016-08-13manager: Add <see-also> tags to relate Bridge related events,actions, and appsMatt Jordan
Change-Id: I67e6b79fa3102e494b5fe6cc7510472249080e85
2016-07-14features.c: Remove unneeded adsi.h include.Corey Farrell
adsi.h is no longer used by features.c since parking was moved to a module. Change-Id: I2248b8a455225a17cb6ddaafd6c20c511a1eaf59
2016-06-30features: Fix channel datastore access.Richard Mudgett
Found as a result of the testsuite tests/callparking test crashing. Several calls to ast_get_chan_featuremap_config() and ast_get_chan_features_xfer_config() did not lock the channel before calling so the channel's datastore list was accessed without the lock's protection. Apparently another thread deleted a datastore on the channel's list while the crashing thread was walking the list. Crash at 0xdeaddead due to MALLOC_DEBUG's memory filler value as a result. * Add missing channel locks to calls that were not already protected as the doxygen for those calls indicates. Change-Id: Id273b3d305cc616406c353cbc841b2b7655efaa1
2016-04-22Bridge system: Fix memory leaks and double frees on impart failure.Richard Mudgett
You cannot reference the passed in features struct after calling ast_bridge_impart(). Even if the call fails. Change-Id: I902b88ba0d5d39520e670fb635078a367268ea21
2015-05-02Remove unneeded uses of optional_api providers.Corey Farrell
A few cases exist where headers of optional_api provders are included but not needed. This causes unneeded calls to ast_optional_api_use. * Don't include optional_api.h from sip_api.h. * Move 'struct ast_channel_monitor' to channel.h. * Don't include monitor.h from chan_sip.c, channel.c or features.c. The move of struct ast_channel_monitor is needed since channel.c depends on it. This has no effect on users of monitor.h since channel.h is included from monitor.h. ASTERISK-25051 #close Reported by: Corey Farrell Change-Id: I53ea65a9fc9693c89f8bcfd6120649bfcfbc3478
2015-04-17Detect potential forwarding loops based on count.Mark Michelson
A potential problem that can arise is the following: * Bob's phone is programmed to automatically forward to Carol. * Carol's phone is programmed to automatically forward to Bob. * Alice calls Bob. If left unchecked, this results in an endless loops of call forwards that would eventually result in some sort of fiery crash. Asterisk's method of solving this issue was to track which interfaces had been dialed. If a destination were dialed a second time, then the attempt to call that destination would fail since a loop was detected. The problem with this method is that call forwarding has evolved. Some SIP phones allow for a user to manually forward an incoming call to an ad-hoc destination. This can mean that: * There are legitimate use cases where a device may be dialed multiple times, or * There can be human error when forwarding calls. This change removes the old method of detecting forwarding loops in favor of keeping a count of the number of destinations a channel has dialed on a particular branch of a call. If the number exceeds the set number of max forwards, then the call fails. This approach has the following advantages over the old: * It is much simpler. * It can detect loops involving local channels. * It is user configurable. The only disadvantage it has is that in the case where there is a legitimate forwarding loop present, it takes longer to detect it. However, the forwarding loop is still properly detected and the call is cleaned up as it should be. Address review feedback on gerrit. * Correct "mfgium" to "Digium" * Decrement max forwards by one in the case where allocation of the max forwards datastore is required. * Remove irrelevant code change from pjsip_global_headers.c ASTERISK-24958 #close Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23
2015-03-28clang compiler warnings: Fix a variety of "unused" warningsMatthew Jordan
This patch fixes the -Wunused-value -Wunused-variable -Wunused-const-variable errors caught by clang. Specifically: * apps/app_queue.c: removed unused qpm_cmd_usage[], qum_cmd_usage[], qsmp_cmd_usage[] * cel/cel_sqlite3_custom.c: removed unused name[] = "cel_sqlite3_custom" * channels/chan_pjsip.c: removed unused desc[] = "PJSIP Channel" * codecs/gsm/src/gsm_create.c: removed unused ident[] = "$Header$" * funcs/func_env.c:729: Fixed ast_str_append_substr. * main/editline/np/strlcat.c: removed unused rcsid variable * main/editline/np/strlcpy.c: removed unused rcsid variable * main/security_events.c: removed unused TIMESTAMP_STR_LEN * utils/conf2ael.c: removed unused cfextension_states * utils/extconf.c: removed unused cfextension_states Review: https://reviewboard.asterisk.org/r/4526 ASTERISK-24917 Reported by: dkdegroot patches: rb4526.patch submitted by dkdegroot (License 6600) ........ Merged revisions 433693 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-03-26Replace most uses of ast_register_atexit with ast_register_cleanup.Corey Farrell
Since 'core stop now' and 'core restart now' do not stop modules, it is unsafe for most of the core to run cleanups. Originally all cleanups used ast_register_atexit, and were only changed when it was shown to be unsafe. ast_register_atexit is now used only when absolutely required to prevent corruption and close child processes. Exceptions that need to use ast_register_atexit: * CDR: Flush records. * res_musiconhold: Kill external applications. * AstDB: Close the DB. * canary_exit: Kill canary process. ASTERISK-24142 #close Reported by: David Brillert ASTERISK-24683 #close Reported by: Peter Katzmann ASTERISK-24805 #close Reported by: Badalian Vyacheslav ASTERISK-24881 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4500/ Review: https://reviewboard.asterisk.org/r/4501/ ........ Merged revisions 433495 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-09app_bridge: return to the next dialplan priorityScott Griepentrog
When app_bridge grabs a channel and puts it into a bridge, the channel should then continue where it left off in the dialplan after the bridge has ended. Although it stores the current dialplan location as an after bridge goto on the channel, it was executing the same priority again instead of going to the next priority. By swapping the "specific" version of bridge_set_after_goto with bridge_set_after_go_on, the next priority in the dialplan is executed instead. ASTERISK-24637 #close Review: https://reviewboard.asterisk.org/r/4322/ Reported by: John Bigelow git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-12Fix leak in AMI Action BridgeCorey Farrell
Add missing reference cleanup for newly created bridge. ASTERISK-24281 Reported by: Stefan Engström Review: https://reviewboard.asterisk.org/r/4154/ ........ Merged revisions 427736 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427737 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-10-06features.c: Fix lingering channel ref while Bridge() application is active.Richard Mudgett
Using the Bridge application to bridge a channel that is executing an applicaiton such as Wait results in a lingering Surrogate channel in the CLI "core show channels" output even though it has already hungup. * Fix bridge_exec() to not hold onto the current_dest_chan ref once it has been put into the bridge. * Eliminated bridge_exec()'s use of RAII_VAR(). ASTERISK-24224 #close Reported by: Mark Michelson Review: https://reviewboard.asterisk.org/r/4041/ ........ Merged revisions 424668 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424669 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-01-17Documentation: doc fixes across various parts of the code for ASTERISK ↵Rusty Newton
issues 23061,23028,23046,23027 Fixes typos of "transfered" instead of "transferred" in various code. Fixes incorrect gosub param help text for app_queue. Fixes Asterisk man pages containing unquoted minus signs. Adds note about the "textsupport" option in sip.conf.sample. (issue ASTERISK-23061) (issue ASTERISK-23028) (issue ASTERISK-23046) (issue ASTERISK-23027) (closes issue ASTERISK-23061) (closes issue ASTERISK-23028) (closes issue ASTERISK-23046) (closes issue ASTERISK-23027) Reported by: Eugene, Jeremy Laine, Denis Pantsyrev Patches: transferred.patch uploaded by Jeremy Laine (license 6561) hyphen.patch uploaded by Jeremy Laine (license 6561) sip.conf.sample.patch uploaded by Eugene (license 6360) ........ Merged revisions 405791 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 405792 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 405829 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-13Restore Dial, Queue, and FollowMe 'I' option support.Richard Mudgett
The Dial, Queue, and FollowMe applications need to inhibit the bridging initial connected line exchange in order to support the 'I' option. * Replaced the pass_reference flag on ast_bridge_join() with a flags parameter to pass other flags defined by enum ast_bridge_join_flags. * Replaced the independent flag on ast_bridge_impart() with a flags parameter to pass other flags defined by enum ast_bridge_impart_flags. * Since the Dial, Queue, and FollowMe applications are now the only callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the calling contract to require the initial COLP exchange to already have been done by the caller. * Made all callers of ast_bridge_impart() check the return value. It is important. As a precaution, I also made the compiler complain now if it is not checked. * Did some cleanup in parking_tests.c as a result of checking the ast_bridge_impart() return value. An independent, but associated change is: * Reduce stack usage in ast_indicate_data() and add a dropping redundant connected line verbose message. (closes issue ASTERISK-22072) Reported by: Joshua Colp Review: https://reviewboard.asterisk.org/r/2845/ ........ Merged revisions 399136 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-22Bridge API: Set a cause code on a channel when it is ejected from a bridge.Richard Mudgett
The cause code needs to be passed from the disconnecting channel to the bridge peers if the disconnecting channel dissolves the bridge. * Made the call to an app_agent_pool agent disconnect with the busy cause code if the agent does not ack the call in time or hangs up before acking the call. (closes issue ASTERISK-22042) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2772/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397472 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-22Massively clean up app_queue.Mark Michelson
This essentially makes app_queue usable again. From reviewboard: * Reporting of transfers and call completion is done by creating stasis subscriptions and listening for specific events in order to determine when the call is finished (either via a transfer or hangup). * Dial end messages have been added where they were previously missing. * Queue stats are properly being updated again once calls have finished. * AgentComplete stasis messages and AMI events are now occurring again. * Mixmonitor starting has been factored into its own function and uses the Mixmonitor API now instead of using ast_pbx_run() In addition to the changes in app_queue, there are several supplementary changes as well: * Queue logging now differentiates between attended and blind transfers. A note about this is in the CHANGES file. * Local channel optimization events now report more information. This includes which of the two local channels involved is the destination of the optimization, the channel that is replacing the destination local channel, and an identifier so that begin and end events can be matched to each other. The end events are now sent whether the optimization was successful or not and includes an indicator of whether the optimization was successful. * Changes were made to features and bridging_basic so that additional flags may be set on a bridge. This is necessary because the queue requires that its bridge only allows move-swap local channel optimizations into the bridge. (closes issue ASTERISK-21517) Reported by Matt Jordan (closes issue ASTERISK-21943) Reported by Matt Jordan Review: https://reviewboard.asterisk.org/r/2694 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-21* Move ast_bridge_channel_setup_features() into bridge_basic.c.Richard Mudgett
* Made application map hooks be removed on a basic bridge personality change. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397355 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-21Fix several interrelated issues dealing with the holding bridge technology.Richard Mudgett
* Added an option flags parameter to interval hooks. Interval hooks now can specify if the callback will affect the media path or not. * Added an option flags parameter to the bridge action custom callback. The action callback now can specify if the callback will affect the media path or not. * Made the holding bridge technology reexamine the participant idle mode option whenever the entertainment is restarted. * Fixed app_agent_pool waiting agents needlessly starting and stopping MOH every second by specifying the heartbeat interval hook as not affecting the media path. * Fixed app_agent_pool agent alert from restarting the MOH after the alert beep. The agent entertainment is now changed from MOH to silence after the alert beep. * Fixed holding bridge technology to defer starting the entertainment. It was previously a mixture of immediate and deferred. * Fixed holding bridge technology to immediately stop the entertainment. It was previously a mixture of immediate and deferred. If the channel left the bridging system, any deferred stopping was discarded before taking effect. * Miscellaneous holding bridge technology rework coding improvements. Review: https://reviewboard.asterisk.org/r/2761/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397294 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-16Doxygen comment tweaks.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396857 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-15Minor parking cleanup.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396812 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-15Remove early bridge BUGBUG comments. Remove some unneeded features.c comments.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-15Resolve some BUGBUG comments.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-15Remove some dead code dealing with: AST_BRIDGE_REC_CHANNEL_0, ↵Richard Mudgett
AST_BRIDGE_REC_CHANNEL_1, and AST_BRIDGE_IGNORE_SIGS. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396734 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-15Fix feature_attended_transfer testKinsey Moore
The feature_attended_transfer test is failing due to Asterisk not passing DTMF in the bridges created for internal attended transfers. This sets the features initialization routine to set this flag by default and adjusts the basic bridge and confbridge's use of the bridging system accordingly as per Richard's suggestion instead of adjusting this individual case. This change allows the necessary DTMF to pass through the attended transfer bridge and complete the test successfully. Review: https://reviewboard.asterisk.org/r/2759/ (closes issue ASTERISK-22222) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396724 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-12Fix two race conditions and ref counting issue when joining a bridgeMatthew Jordan
These problems were all caught by a test in the Asterisk Test Suite that originated some Local channels and attempted to move the ;2 half of the Local channel into a bridge using the Bridge AMI action. (1) When originating a channel, the Newchannel event is emitted quickly; however, the ;2 channel will not have a pbx thread assigned to it until after the outbound 'dialing' for the ;1 is complete. Thus, there is a period of time where the outside world "knows" of the channel's existence and can influence it but Asterisk has not yet started the dialplan execution thread. If a Bridge AMI action is taken on the channel, the channel appears to be a Dialed channel with no PBX thread; hence, the channel will be imparted into the Bridge by first 'yanking' the channel. At the same time, a race condition can occur after the yank (but before entering the bridge) when ;1 answers and starts a PBX on the ;2. The end result currently is an assertion failure in the Bridging API, as a channel with a PBX is imparted into the Bridge. There's no way to prevent AMI from attempting to Bridge a channel immediately after creation; likewise, holding the channel lock through the entire Dial operation is unwise (and impossible). Instead of treating the presence of a PBX thread as an error, we simply bail out of the adding the channel to the bridge through ast_bridge_impart. The Bridge action will then fail - but we avoid a situation where the channel is both executing a PBX thread and simultaneously being given a separate thread in the bridging system (which would be a "bad thing"). Since imparting a channel with a PBX *can* occur and is not a programming error, the asserts have been removed. (2) When the first condition occurs, we have to take one of two actions: either hangup the yanked channel as it did not enter the bridge, or deref it because we don't own it. We can determine if we own it or not by testing for the presence of the PBX thread. If we hung it up directly, we'd crash. (3) bridge_find_channel does not increase the reference count of the ast_bridge_channel object. The RAII_VAR usage in ast_bridge_add_channel thus created a ticking time bomb in whatever bridge the channel moved into, as the destructor for the ast_bridge_channel object would be called. Review: https://reviewboard.asterisk.org/r/2741/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-08Remove some resolved or obsolete BUGBUG comments.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-05bridge features: Dial and Queue add features instead of replace them.Jonathan Rose
Dial and Queue would previously apply a new set of features whenever bridging. These options would be based purely on the options supplied to the dial/queue applications. This patch changes the function those applications use to bridge calls so that the features will be added to the set of existing features for each channel rather than having them override the existing features. (closes issue ASTERISK-22209) Reported by: Jonathan Rose Review: https://reviewboard.asterisk.org/r/2713/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396245 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-02Remove dead code from features.c; refactor pickup code into pickup.cMatthew Jordan
This patch does the following: * It moves the pickup code out of features.c and into pickup.c * It removes the vast majority of dead code out of features.c. In particular, this includes the parking code. (issue ASTERISK-22134) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-01Support externally initiated parking requests; remove some dead codeMatthew Jordan
This patch does the following: * It adds support for externally initiated parking requests. In particular, chan_skinny has a protocol level message that initiates a call park. This patch now supports that option, as well as the protocol specific mechanisms in chan_dahdi/sig_analog and chan_mgcp. * A parking bridge features virtual table has been added that provides access to the parking functionality that the Bridging API needs. This includes requests to park an entire 'call' (with little or no additional information, thank you chan_skinny), perform a blind transfer to a parking extension, determine if an extension is a parking extension, as well as the actual "do the parking" request from the Bridging API. * Refactoring in chan_mgcp, chan_skinny, and chan_dahdi to make use of the new functions * The removal of some - but not all - dead parking code from features.c This also fixed blind transferring a multi-party bridge to a parking lot (which was implemented, but had at least one code path where using the parking features kK might not have worked) Review: https://reviewboard.asterisk.org/r/2710 (closes issue ASTERISK-22134) Reported by: Matt Jordan git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-01Fix documentation replication issuesKinsey Moore
This prevents XML documentation duplication by expanding channel and bridge snapshot tags into channel and bridge snapshot parameter sets with a given prefix or defaulting to no prefix. This also prevents documentation from becoming fractured and out of date by keeping all variations of the documentation in template form such that it only needs to be updated once and keeps maintenance to a minimum. Review: https://reviewboard.asterisk.org/r/2708/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-26Remove the unsafe bridge parameter from ast_bridge_hook_callback's.Richard Mudgett
Most hook callbacks did not need the bridge parameter. The pointer value could become invalid if the channel is moved to another bridge while it is executing. * Fixed some issues in feature_attended_transfer() as a result. * Reduce the bridge inhibit count in attended_transfer_properties_shutdown() after it has restored the bridge channel hooks. * Removed basic bridge requirement on feature_blind_transfer(). It does not require the basic bridge like feature_attended_transfer(). git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-25Remove some dead parking callMatthew Jordan
Since nothing is using these global parking functions, remove them! The first of many. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-25Remove dead bridging code from featuresMatthew Jordan
This removes the previously #if 0'd code. The functionality removed has either been subsumed by the Bridging API or is no longer applicable. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-25A great big renaming patchMatthew Jordan
This patch renames the bridging* files to bridge*. This may seem pedantic and silly, but it fits better in line with current Asterisk naming conventions: * channel is not "channeling" * monitor is not "monitoring" etc. A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is the act of using a bridge on a set of channels - and the API that fulfills that role is more than just the action. (closes issue ASTERISK-22130) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-25Move after bridge callbacks into their own fileMatthew Jordan
One more major refactoring to go. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395367 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-24* Refactor setup_bridge_features_builtin().Richard Mudgett
* Add an error message so you know when a feature is not available and you tried to use it. It usually means the module has not been loaded. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-24Perform the initial renaming of the Bridging APIMatthew Jordan
This patch does the following: * It pulls out bridge_channel and puts it into its own translation unit * It adds public and protected headers for bridging_channel. Protected functions are appropriate only for the Bridging API and sub-classes of a bridge. (issue ASTERISK-22130) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395253 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-23Make DTMF attended transfer support feature-complete.Mark Michelson
This greatly modifies the operation of DTMF attended transfers so that the full range of options from features.conf applies. In addition, a new option has been added that allows for a transferer to switch between bridges during a transfer before completing the transfer. (closes issue ASTERISK-21543) reported by Matt Jordan Review: https://reviewboard.asterisk.org/r/2654 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395151 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-20Add transfer support to CELKinsey Moore
This adds CEL support for blind and attended transfers and call pickup. During the course of adding this functionality I noticed that CONF_ENTER, CONF_EXIT, and BRIDGE_TO_CONF events are particularly useless without a bridge identifier, so I added that as well. This adds tests for blind transfers, several types of attended transfers, and call pickup. The extra field in CEL records now consists of a JSON blob whose fields are defined on a per-event basis. Review: https://reviewboard.asterisk.org/r/2658/ (closes issue ASTERISK-21565) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-17Change ast_hangup() to return void and be NULL safe.Richard Mudgett
Since ast_hangup() is effectively a channel destructor, it should be a void function. * Make the few silly callers checking the return value no longer do so. Only the CDR and CEL unit tests checked the return value. * Make all callers take advantage of the NULL safe change and remove the NULL check before the call. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-17Remove some completed and no longer relevant BUGBUG notes.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394600 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-04res_parking: Replace Parker snapshots with ParkerDialStringJonathan Rose
This process also involved a large amount of rework regarding how to redial the Parker when a channel leaves a parking lot due to timeout. An attended transfer channel variable has been added to attended transfers to extensions that will eventually park (but haven't at the time of transfer) as well. This resolves one of the two BUGBUG comments remaining in res_parking. (issues ASTERISK-21877) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2638/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-06-28features: call pickup stasis refactoringJonathan Rose
(issue ASTERISK-21544) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2588/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-06-26AMI Bridge action: Get channel xfer config after we have found the second ↵Richard Mudgett
channel. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392933 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-06-25res_parking: Add Parking manager action to the new parking systemJonathan Rose
(closes issue ASTERISK-21641) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2573/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-06-21Change several bridge functions to return error status.Richard Mudgett
The bridge frame queue functions need to return an error status if the frame failed to be queued because of an error condition. The main calls that needed to return the status are: ast_bridge_channel_queue_action_data() and ast_bridge_channel_write_action_data(). The other return changes are ripple effects. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-06-20Fix potential bridge hook resource leak if the hook install fails.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-06-17Update Asterisk's CDRs for the new bridging frameworkMatthew Jordan
This patch is the initial push to update Asterisk's CDR engine for the new bridging framework. This patch guts the existing CDR engine and builds the new on top of messages coming across Stasis. As changes in channel state and bridge state are detected, CDRs are built and dispatched accordingly. This fundamentally changes CDRs in a few ways. (1) CDRs are now *very* reflective of the actual state of channels and bridges. This means CDRs track well with what an actual channel is doing - which is useful in transfer scenarios (which were previously difficult to pin down). It does, however, mean that CDRs cannot be 'fooled'. Previous behavior in Asterisk allowed for CDR applications, channels, and other properties to be spoofed in parts of the code - this no longer works. (2) CDRs have defined behavior in multi-party scenarios. This behavior will not be what everyone wants, but it is a defined behavior and as such, it is predictable. (3) The CDR manipulation functions and applications have been overhauled. Major changes have been made to ResetCDR and ForkCDR in particular. Many of the options for these two applications no longer made any sense with the new framework and the (slightly) more immutable nature of CDRs. There are a plethora of other changes. For a full description of CDR behavior, see the CDR specification on the Asterisk wiki. (closes issue ASTERISK-21196) Review: https://reviewboard.asterisk.org/r/2486/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-06-13Refactor CEL bridge events on top of Stasis-CoreKinsey Moore
This pulls bridge-related CEL event triggers out of the code in which they were residing and pulls them into cel.c where they are now triggered by changes in bridge snapshots. To get access to the Stasis-Core parking topic in cel.c, the Stasis-Core portions of parking init have been pulled into core Asterisk init. This also adds a new CEL event (AST_CEL_BRIDGE_TO_CONF) that indicates a two-party bridge has transitioned to a multi-party conference. The reverse cannot occur in CEL terms even though it may occur in actuality and two party bridges which receive a AST_CEL_BRIDGE_TO_CONF will be treated as multi-party conferences for the duration of the bridge. Review: https://reviewboard.asterisk.org/r/2563/ (closes issue ASTERISK-21564) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391643 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-06-07res_parking: Automatically generate extensions, hints, etc.Jonathan Rose
(closes issue ASTERISK-21645) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2545/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390849 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-06-06Reimplement bridging and DTMF features related channel variables in the ↵Richard Mudgett
bridging core. * The channel variable ATTENDED_TRANSFER_COMPLETE_SOUND is no longer channel driver specific. If the channel variable is set on the transferrer channel, the sound will be played to the target of an attended transfer. * The channel variable BRIDGEPEER becomes a comma separated list of peers in a multi-party bridge. The BRIDGEPEER value can have a maximum of 10 peers listed. Any more peers in the bridge will not be included in the list. BRIDGEPEER is not valid in holding bridges like parking since those channels do not talk to each other even though they are in a bridge. * The channel variable BRIDGEPVTCALLID is only valid for two party bridges and will contain a value if the BRIDGEPEER's channel driver supports it. * The channel variable DYNAMIC_PEERNAME is redundant with BRIDGEPEER and is removed. The more useful DYNAMIC_WHO_ACTIVATED gives the channel name that activated the dynamic feature. * The channel variables DYNAMIC_FEATURENAME and DYNAMIC_WHO_ACTIVATED are set only on the channel executing the dynamic feature. Executing a dynamic feature on the bridge peer in a multi-party bridge will execute it on all peers of the activating channel. (closes issue ASTERISK-21555) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2582/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390771 65c4cc65-6c06-0410-ace0-fbb531ad65f3