asterisk

Commit Graph

Author	SHA1	Message	Date
Joshua Colp	e5899852cc	res_stasis: Enable transfers and provide events when they occur. This change enables transfers within ARI created bridges and adds events for when they occur. Unlike other events these will be received if any subscribed object is involved in the transfer. (closes issue ASTERISK-22984) Reported by: David M. Lee Review: https://reviewboard.asterisk.org/r/3120/ ........ Merged revisions 407153 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407154 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kevin Harwell	28c0cb28d0	channel locking: Add locking for channel snapshot creation Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	b0bb03e916	bridging: Give bridges a name and a known creator Bridges have two new optional properties, a creator and a name. Certain consumers of bridges will automatically provide bridges that they create with these properties. Examples include app_bridgewait, res_parking, app_confbridge, and app_agent_pool. In addition, a name may now be provided as an argument to the POST function for creating new bridges via ARI. (closes issue AFS-47) Review: https://reviewboard.asterisk.org/r/3070/ ........ Merged revisions 404042 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404043 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	1212906351	Reverting r403311. It's causing ARI tests to hang. ........ Merged revisions 403398 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403404 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	8e8b329e14	Add channel locking for channel snapshot creation. This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such. ........ Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	d9015a5356	ARI: Don't leak implementation details This change prevents channels used as implementation details from leaking out to ARI. It does this by preventing creation of JSON blobs of channel snapshots created from those channels and sanitizing JSON blobs of bridge snapshots as they are created. This introduces a framework for excluding information from output targeted at Stasis applications on a consumer-by-consumer basis using channel sanitization callbacks which could be extended to bridges or endpoints if necessary. This prevents unhelpful error messages from being generated by ast_json_pack. This also corrects a bug where BridgeCreated events would not be created. (closes issue ASTERISK-22744) Review: https://reviewboard.asterisk.org/r/2987/ Reported by: David M. Lee ........ Merged revisions 403069 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403070 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	e7d49d28ea	Fix a performance problem CDRs There is a large performance price currently in the CDR engine. We currently perform two ao2_callback calls on a container that has an entry for every channel in the system. This is done to create matching pairs between channels in a bridge. As such, the portion of the CDR logic that this patch deals with is how we make pairings when a channel enters a mixing bridge. In general, when a channel enters such a bridge, we need to do two things: (1) Figure out if anyone in the bridge can be this channel's Party B. (2) Make pairings with every other channel in the bridge that is not already our Party B. This is a two step process. In the first step, we look through everyone in the bridge and see if they can be our Party B (single_state_process_bridge_enter). If they can - yay! We mark our CDR as having gotten a Party B. If not, we keep searching. If we don't find one, we wait until someone joins who can be our Party B. Step 2 is where we changed the logic (handle_bridge_pairings and bridge_candidate_process). Previously, we would first find candidates - those channels in the bridge with us - from the active_cdrs_by_channel container. Because a channel could be a candidate if it was Party B to an item in the container, the code implemented multiple ao2_container callbacks to get all the candidates. We also had to store them in another container with some other meta information. This was rather complex and costly, particularly if you have 300 Local channels (600 channels!) going at once. Luckily, none of it is needed: when a channel enters a bridge (which is when we're figuring all this stuff out), the bridge snapshot tells us the unique IDs of everyone already in the bridge. All we need to do is: For all channels in the bridge: If the channel is us or our Party B that we got in step 1, skip it Compare us and the candidate to figure out who is Party A (based on some specific rules) If we are Party A: Make a new CDR for us, append it to our chain, and set the candidate as Party B If they are Party A: If they don't have a Party B: Make a new CDR for them, append us to their chain, and us as Party B Otherwise: Copy us over as Party B on their existing CDR. This patch does that. Because we now use channel unique IDs to find the candidates during bridging, active_cdrs_by_channel now looks up things using uniqueid instead of channel name. This makes the more complex code simpler; it does, however, have the drawback that dialplan applications and functions will be slightly slower as they have to iterate through the container looking for the CDR by name. That's a small price to pay however as the bridging code will be called a lot more often. This patch also does two other minor changes: (1) It reduces the container size of the channels in a bridge snapshot to 1. In order to be predictable for multi-party bridges, the order of the channels in the container must be stable; that is, it must always devolve to a linked list. (2) CDRs and the multi-party test was updated to show the relationship between two dialed channels. You still want to know if they talked - previously, dialed channels were always ignored, which is wrong when they have managed to get a Party B. (closes issue ASTERISK-22488) Reported by: Richard Mudgett Review: https://reviewboard.asterisk.org/r/2861/ ........ Merged revisions 399666 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399667 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	0bc2a77365	Multiple revisions 397921-397922 ........ r397921 \| mmichelson \| 2013-08-29 10:42:10 -0500 (Thu, 29 Aug 2013) \| 6 lines Resolve assumptions that bridge snapshots would be non-NULL for transfer stasis events. Attempting to transfer an unbridged call would result in crashes in either CEL code or in the conversion to AMI messages. ........ r397922 \| mmichelson \| 2013-08-29 10:42:29 -0500 (Thu, 29 Aug 2013) \| 3 lines Remove extra debug message. ........ Merged revisions 397921-397922 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397923 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	451993f4f5	ARI: WebSocket event cleanup Stasis events (which get distributed over the ARI WebSocket) are created by subscribing to the channel_all_cached and bridge_all_cached topics, filtering out events for channels/bridges currently subscribed to. There are two issues with that. First was a race condition, where messages in-flight to the master subscribe-to-all-things topic would get sent out, even though the events happened before the channel was put into Stasis. Secondly, as the number of channels and bridges grow in the system, the work spent filtering messages becomes excessive. Since r395954, individual channels and bridges have caching topics, and can be subscribed to individually. This patch takes advantage, so that channels and bridges are subscribed to on demand, instead of filtering the global topics. The one case where filtering is still required is handling BridgeMerge messages, which are published directly to the bridge_all topic. Other than the change to how subscriptions work, this patch mostly just moves code around. Most of the work generating JSON objects from messages was moved to .to_json handlers on the message types. The callback functions handling app subscriptions were moved from res_stasis (b/c they were global to the model) to stasis/app.c (b/c they are local to the app now). (closes issue ASTERISK-21969) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2754/ ........ Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	0b9ab0c61a	Remove extra CR/LF from AMI event. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396462 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	3f724fa493	Make bridge snapshots use prefixes. * Changed ast_manager_build_bridge_state_string() to assume an empty prefix string just like ast_manager_build_channel_state_string(). * Created ast_manager_build_bridge_state_string_prefix() to work just like ast_manager_build_channel_state_string_prefix(). * Made BridgeMerge AMI event use To/From prefixes. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396417 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	309d7e08f0	Clean up ast_json with ast_json_unref git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396143 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	328e99f41d	Make a couple of changes to help AMI events to be more clear in what is occurring. * BridgeEnter now contains the unique ID of the channel that is to be swapped out, if applicable. * There is a ParkedCallSwap event that is sent when a parked channel has a new channel take its place. (closes issue ASTERISK-22193) reported by Mark Michelson Review: https://reviewboard.asterisk.org/r/2712 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396107 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	03090a88ba	Fix documentation replication issues 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	12 years ago
David M. Lee	e1b959ccbb	Split caching out from the stasis_caching_topic. In working with res_stasis, I discovered a significant limitation to the current structure of stasis_caching_topics: you cannot subscribe to cache updates for a single channel/bridge/endpoint/etc. To address this, this patch splits the cache away from the stasis_caching_topic, making it a first class object. The stasis_cache object is shared amongst individual stasis_caching_topics that are created per channel/endpoint/etc. These are still forwarded to global whatever_all_cached topics, so their use from most of the code does not change. In making these changes, I noticed that we frequently used a similar pattern for bridges, endpoints and channels: single_topic ----------------> all_topic ^ \| single_topic_cached ----+----> all_topic_cached \| +----> cache This pattern was extracted as the 'Stasis Caching Pattern', defined in stasis_caching_pattern.h. This avoids a lot of duplicate code between the different domain objects. Since the cache is now disassociated from its upstream caching topics, this also necessitated a change to how the 'guaranteed' flag worked for retrieving from a cache. The code for handling the caching guarantee was extracted into a 'stasis_topic_wait' function, which works for any stasis_topic. (closes issue ASTERISK-22002) Review: https://reviewboard.asterisk.org/r/2672/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	56a90d435c	Fix incorrect reference to stasis/bridging.h git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395381 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	cafc115896	A great big renaming patch 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	12 years ago

17 Commits (15140883d0b9312e0c298d1f4a76ed3aa84fd6b5)