65 Commits (812f5b51cb56a36668decc6dfc83adeca185429e)

Author	SHA1	Message	Date
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
Kevin Harwell	f5d5aa67dc	AMI: Escape string values. ... So this issue is a bit complicated. Since it is possible to pass values to AMI that contain a '\r\n' (or other similar sequences) these values need to be escaped. One way to solve this is to escape the values and then pass the escaped values to the AMI variable parameter string building function. However, this puts the onus on the pre-build function to escape all string values. This potentially requires a fair amount of changes along with a lot of string allocations/freeing for all values. Surely there is a way to push this complexity down a level into the string building function itself? This of course is possible, but ends up requiring a way to distinguish between strings that need to be escaped and those that don't. The best way to handle this is by introducing a new format specifier in the format string. For instance a %s (no escape) and %S (escape). However, that is a bit weird and unexpected. So faced with those possibilities this patch implements a limited version of the first option. Instead of attempting to escape all string values this patch only escapes those values that make sense. This approach limits the number of changes and doesn't suffer from the odd format specifier problem. ASTERISK-24934 #close Reported by: warren smith Change-Id: Ib55a5b84fe0481b0f2caaaab68c566f392c0aac0	10 years ago
Joshua Colp	181ae3b8d9	stasis: Fix dial masquerade datastore lifetime ... A recent change went into Asterisk which added reference counts to the channels stored in a dial masquerade datastore. Unfortunately this included a reference to the caller in a dialing operation. While all of the dialed targets have the datastore removed from them upon dialing completion this did not occur for the caller, causing it to have a reference to itself that could go never go away (as it depended on the destruction of the datastore which only happened when the channel was destroyed). This resulted in the caller channel remaining on the system despite it having hung up. This change does the following to fix this issue: 1. The dial masquerade datastore is now removed from the caller upon dialing completion, just like the dialed targets. 2. Upon destruction of the caller all the dialed targets are also removed from the dial masquerade datastore (just in case). 3. The reference to the caller has been removed as it should not be possible for the datastore to now be valid/useful after the lifetime of the caller has ended. ASTERISK-25025 #close Change-Id: I1ef4ca5ca04980028604cc2af5d2992ac3431b3f	10 years ago
Mark Michelson	077979618b	Prevent potential crash on blond transfer. ... Scenario: Alice calls Bob. Bob performs a blond transfer to Carol. Carol rejects the incoming call (or some other immediate circumstance causes Carol not to answer the call) What occurs in this case is that when the bridge between Alice and Bob breaks, Alice is told to masquerade into Bob's channel that had placed the call to Carol. The actual masquerade goes down without a hitch. However, a channel fixup callback that attempts to publish dial events over Stasis has a crash. The reason for this crash is that the datastore on Bob's channel that placed the outbound call to Carol only had a bare pointer to Carol's channel. Since Carol rejected the incoming call, Carol's channel has been hung up and freed, meaning accessing her channel results in a crash. The fix here is simple. The dial fixup code has been altered to hold references to the involved channels and to drop those references when freeing data. ASTERISK-25025 #close Reported by Chet Stevens Change-Id: I54eedda207b8ec7a69263353b43abe5746aea197	10 years ago
Matthew Jordan	ab803ec342	ARI: Add the ability to intercept hold and raise an event ... For some applications - such as SLA - a phone pressing hold should not behave in the fashion that the Asterisk core would like it to. Instead, the hold action has some application specific behaviour associated with it - such as disconnecting the channel that initiated the hold; only playing MoH to channels in the bridge if the channels are of a particular type, etc. One way of accomplishing this is to use a framehook to intercept the hold/unhold frames, raise an event, and eat the frame. Tasty. This patch accomplishes that using a new dialplan function, HOLD_INTERCEPT. In addition, some general cleanup of raising hold/unhold Stasis messages was done, including removing some RAII_VAR usage. Review: https://reviewboard.asterisk.org/r/4549/ ASTERISK-24922 #close git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434216 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Joshua Colp	bc357c1d7e	core: Don't create snapshots with locks. ... Snapshots are immutable and are never changed. Allocating them with a lock is wasteful. Review: https://reviewboard.asterisk.org/r/4469/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432742 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Mark Michelson	43dd42d8ae	Fix some memory leaks. ... These memory leaks were found and fixed by John Hardin. I'm just committing them for him. ASTERISK-24736 #close Reported by Mark Michelson Review: https://reviewboard.asterisk.org/r/4389 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431468 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Kevin Harwell	2f21f85c37	ARI/AMI: Include language in standard channel snapshot output ... The channel "language" was already part of a channel snapshot, however is was not sent out over AMI or ARI. This patch makes it so the channel "language" is included in the appropriate AMI or ARI events. ASTERISK-24553 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/4245/ ........ Merged revisions 429204 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429206 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
Richard Mudgett	9a7fb8ee6c	stasis_channels.c: Resolve unfinished Dials when doing masquerades (Part 2) ... Masquerades into and out of channels that are involved in a dial operation don't create the expected dial end event. The missing dial end event goes against the model for things like CDRs and generating Dial end manager actions and such. There are four cases: 1) A channel masquerades into the caller channel. The case happens when performing a blonde transfer using the channel driver's protocol. 2) A channel masquerades into a callee channel. The case happens when performing a directed call pickup. 3) The caller channel masquerades out of dial. The case happens when using the Bridge application on the caller channel. 4) A callee channel masquerades out of dial. The case happens when using the Bridge application on a peer channel. As it turned out, all four cases need to be handled instead of just the first one. ASTERISK-24237 Reported by: Richard Mudgett ASTERISK-24394 #close Reported by: Richard Mudgett Review: https://reviewboard.asterisk.org/r/4066/ ........ Merged revisions 425430 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425455 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Jonathan Rose	d1b1e911bf	Stasis_channels: Resolve unfinished Dials when doing masquerades ... Masquerades into channels that are in the dialing state don't end their dial and this goes against the model for things like CDRs and generating Dial end manager actions and such. ASTERISK-24237 #close Reported by: Richard Mudgett Review: https://reviewboard.asterisk.org/r/3990/ ........ Merged revisions 423525 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423530 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	f1036f40dc	Stasis: Allow message types to be blocked ... This introduces stasis.conf and a mechanism to prevent certain message types from being published. Internally, this works by preventing the chosen message types from being created which ensures that those message types can never be published. This patch also adjusts message publishers such that message payloads are not created if the related message type is not available. ASTERISK-23943 #close Review: https://reviewboard.asterisk.org/r/3823/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420124 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	a965613cf7	stasis_channels: Update the stasis cache if manager variables are needed ... In r416211, the publishing of variable changes was modified such that a cached channel snapshot was used if manager variables were not requested with each AMI event. This was done to reduce the amount of channel snapshots created. However, an assumption was made that generating a channel snapshot and publishing the snapshot to the channel topic was sufficient to ensure that the cache would be updated; this is not the case. The channel snapshot type must be used to force a snapshot update. This patch updates the publication of channel variables such that the cache is updated prior to publication of the channel variable message if manager variables are in use. This ensures that all AMI events receive the variable update when they are supposed to. Note that this issue was caught by the Asterisk Test Suite (go go testing) ........ Merged revisions 416557 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416561 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	9cc1a8e893	stasis: Reduce creation of channel snapshots to improve performance ... During some performance testing of Asterisk with AGI, ARI, and lots of Local channels, we noticed that there's quite a hit in performance during channel creation and releasing to the dialplan (ARI continue). After investigating the performance spike that occurs during channel creation, we discovered that we create a lot of channel snapshots that are technically unnecessary. This includes creating snapshots during: * AGI execution * Returning objects for ARI commands * During some Local channel operations * During some dialling operations * During variable setting * During some bridging operations And more. This patch does the following: - It removes a number of fields from channel snapshots. These fields were rarely used, were expensive to have on the snapshot, and hurt performance. This included formats, translation paths, Log Call ID, callgroup, pickup group, and all channel variables. As a result, AMI Status, "core show channel", "core show channelvar", and "pjsip show channel" were modified to either hit the live channel or not show certain pieces of data. While this is unfortunate, the performance gain from this patch is worth the loss in behaviour. - It adds a mechanism to publish a cached snapshot + blob. A large number of publications were changed to use this, including: - During Dial begin - During Variable assignment (if no AMI variables are emitted - if AMI variables are set, we have to make snapshots when a variable is changed) - During channel pickup - When a channel is put on hold/unhold - When a DTMF digit is begun/ended - When creating a bridge snapshot - When an AOC event is raised - During Local channel optimization/Local bridging - When endpoint snapshots are generated - All AGI events - All ARI responses that return a channel - Events in the AgentPool, MeetMe, and some in Queue - Additionally, some extraneous channel snapshots were being made that were unnecessary. These were removed. - The result of ast_hashtab_hash_string is now cached in stasis_cache. This reduces a large number of calls to ast_hashtab_hash_string, which reduced the amount of time spent in this function in gprof by around 50%. #ASTERISK-23811 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3568/ ........ Merged revisions 416211 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416216 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	53968c00b3	TALK_DETECT: A channel function that raises events when talking is detected ... This patch adds a new channel function TALK_DETECT that, when set on a channel, causes events indicating the start/stop of talking on a channel to be emitted to both AMI and ARI clients. The function allows setting both the silence threshold (the length of silence after which we decide no one is talking) as well as the talking threshold (the amount of energy that counts as talking). Parameters can be updated on a channel after talk detection has been enabled, and talk detection can be removed at any time. The events raised by the function use a nomenclature similar to existing AMI/ARI events. For AMI: ChannelTalkingStart/ChannelTalkingStop For ARI: ChannelTalkingStarted/ChannelTalkingFinished Review: https://reviewboard.asterisk.org/r/3563/ #ASTERISK-23786 #close Reported by: Matt Jordan ........ Merged revisions 414934 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414935 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
Richard Mudgett	cbe7f65674	app_dial and app_queue: Make lock the forwarding channel while taking the channel snapshot. ... * Fixed ast_channel_publish_dial_forward() not locking the forwarded channel when taking the channel snapshot. * Fixed app_dial.c:do_forward() using the wrong channel to get the original call forwarding string. * Removed unnecessary locking when calling ast_channel_publish_dial() and ast_channel_publish_dial_forward() in app_dial and app_queue. Holding channel locks when calling ast_channel_publish_dial_forward() with a forwarded channel could result in pausing the system while the stasis bus completes processsing a forwarded channel subscription. Review: https://reviewboard.asterisk.org/r/3451/ ........ Merged revisions 412579 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412580 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	ba1db5d8f5	Eliminate some more unnecessary RAII_VAR() uses. ... RAII_VAR() is not a hammer appropriate to pound all nails. ........ Merged revisions 412413 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412414 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
Richard Mudgett	7542361f4a	stasis_channels.c: Eliminate another overuse of RAII_VAR(). ... ........ Merged revisions 411636 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411637 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	d277f3ec3e	json: Fix off-nominal json ref counting issues. ... * Fixed off-nominal json ref counting issue with using the following API calls: ast_json_object_set() and ast_json_array_append(). * Fixed off-nominal error reporting in ast_ari_endpoints_list(). * Fixed some miscellaneous off-nominal json ref counting issues in report_receive_fax_status() and dial_to_json(). ........ Merged revisions 408713 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408714 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kevin Harwell	28c0cb28d0	channel locking: Add locking for channel snapshot creation ... Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	3a5cc054ed	res_stasis: Expose event for call forwarding and follow forwarded channel. ... This change adds an event for when an originated call is redirected to another target. This event contains the original channel and the newly created channel. If a stasis subscription exists on the original originated channel for a stasis application then a new subscription will also be created on the stasis application to the redirected channel. This allows the application to follow the call path completely. (closes issue ASTERISK-22719) Reported by: Joshua Colp Review: https://reviewboard.asterisk.org/r/3054/ ........ Merged revisions 403808 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403810 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	aff0faf6ba	stasis_channels: Don't give preference to ANI info in channel snapshots ... When publishing channel snapshots, we currently compute the caller ID name and number by giving preference first to ani.{name|number}, then to id.{name|number}. However, when a channel driver (such as chan_sip) updates the caller ID, it typically only updates the caller ID stored in id.{name|number}. This means that we are currently giving preference to stale information. When looking at the rest of the code base, the only other place where we appear to use this same logic is in app_amd. Everywhere else, we treat the party information in ani as being separate to the party information in id. This patch publishes only the caller ID name and number in the snapshot field for caller_name and caller_num. Note that the information in ANI is still available in caller_ani. Review: https://reviewboard.asterisk.org/r/2992/ ........ Merged revisions 402501 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402502 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	c1235f2639	Reduce channel snapshot creation and publishing by up to 50%. ... This change introduces the ability to stage channel snapshot creation and publishing by suppressing the implicit creation and publishing that some functions have. Once all operations are executed the staging is marked as done and a single snapshot is created and published. Review: https://reviewboard.asterisk.org/r/2889/ ........ Merged revisions 400265 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400266 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	3d9c5e61af	Fix error in using ast_channel_snapshot_type before initialization ... Starting Asterisk would kick back an ERROR message stating that the Stasis message type ast_channel_snapshot_type was used prior to initialization. This occurred due to the caching topic being created prior to the message type that it depended on. This patch re-orders the start up such that the message type is initialized prior to the caching topic. It also checks the return value of the initialization of the agent login/logoff types. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397585 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	e47d3db365	Doxygen comment tweaks. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396857 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	f29d969a79	Stasis: address refcount races; implementation comments ... Change r395954 reordered some stasis object destruction, which should have been fine. Unfortunately, it caused some hard to reproduce issues related to objects being accessed after they had been destroyed. The patch in r396329 fixed the destruction order problem; this patch addresses the underlying issue. A few other stasis-related fixes were also added. * Add ref-bumps around areas where objects may get transitively destroyed. (For example, where we lock a topic, unref a subscription, which unrefs the topic, which explodes the topic when we try to unlock it.) * Wrote an extensive doxygen page about Stasis implementation, relationships between objects, lifecycles of objects, how the refcounting works, etc. Many other comments were added, corrected, or cleaned up. * Added an assert to the topic dtor to catch extra ref decrements. * Fixed type used after destruction errors for graceful shutdown in stasis_channels.c. * I added two unit tests in an attempt to catch destruction order issues. Since the underlying cause is a race condition, though, the tests rarely failed even when the code was wrong. * Fixed a leak in stasis_cache_pattern.c. (closes issue ASTERISK-22243) Review: https://reviewboard.asterisk.org/r/2746/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396842 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	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
Kinsey Moore	5a8f32703c	Filter channels used as internal mechanisms ... This adds new flags to the channel tech properties that flag it as different types of implementation detail used exclusively to provide a feature. Examples of channels that would have these flags include the announcement and recording channels used by confbridge which are the only two marked as such by this patch. Review: https://reviewboard.asterisk.org/r/2633/ (closes issue ASTERISK-21873) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394808 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	d43b17a872	Replace chan_agent with app_agent_pool. ... The ill conceived chan_agent is no more. It is now replaced by app_agent_pool. Agents login using the AgentLogin() application as before. The AgentLogin() application no longer does any authentication. Authentication is now the responsibility of the dialplan. (Besides, the authentication done by chan_agent did not match what the voice prompts asked for.) Sample extensions.conf [login] ; Sample agent 1001 login ; Set COLP for in between calls so the agent does not see the last caller COLP. exten => 1001,1,Set(CONNECTEDLINE(all)="Agent Waiting" <1001>) ; Give the agent DTMF transfer and disconnect features when connected to a caller. same => n,Set(CHANNEL(dtmf-features)=TX) same => n,AgentLogin(1001) same => n,NoOp(AGENT_STATUS is ${AGENT_STATUS}) same => n,Hangup() [caller] ; Sample caller direct connect to agent 1001 exten => 800,1,AgentRequest(1001) same => n,NoOp(AGENT_STATUS is ${AGENT_STATUS}) same => n,Hangup() ; Sample caller going through a Queue to agent 1001 exten => 900,1,Queue(agent_q) same => n,Hangup() Sample queues.conf [agent_q] member => Local/800@caller,,SuperAgent,Agent:1001 Under the hood operation overview: 1) Logged in agents wait for callers in an agents holding bridge. 2) Caller requests an agent using AgentRequest() 3) A basic bridge is created, the agent is notified, and caller joins the basic bridge to wait for the agent. 4) The agent is either automatically connected to the caller or must ack the call to connect. 5) The agent is moved from the agents holding bridge to the basic bridge. 6) The agent and caller talk. 7) The connection is ended by either party. 8) The agent goes back to the agents holding bridge. To avoid some locking issues with the agent holding bridge, I needed to make some changes to the after bridge callback support. The after bridge callback is now a list of requested callbacks with the last to be added the only active callback. The after bridge callback for failed callbacks will always happen in the channel thread when the channel leaves the bridging system or is destroyed. (closes issue ASTERISK-21554) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2657/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394417 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	7c044acbd9	Refactor operations to access the stasis cache instead of objects directly when retrieving information. ... (closes issue ASTERISK-21883) Review: https://reviewboard.asterisk.org/r/2645/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393831 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	b193c2873d	Handle hangup logic in the Stasis message bus and consumers of Stasis messages ... This patch does the following: * It adds a new soft hangup flag AST_SOFTHANGUP_HANGUP_EXEC that is set when a channel is executing dialplan hangup logic, i.e., the 'h' extension or a hangup handler. Stasis messages now also convey the soft hangup flag so consumers of the messages can know when a channel is executing said hangup logic. * It adds a new channel flag, AST_FLAG_DEAD, which is set when a channel is well and truly dead. Not just a zombie, but dead, Jim. Manager, CEL, CDRs, and other consumers of Stasis have been updated to look for this flag to know when the channel should by lying six feet under. * The CDR engine has been updated to better handle a channel entering and leaving a bridge. Previously, a new CDR was automatically created when a channel left a bridge and put into the 'Pending' state; however, this way of handling CDRs made it difficult for the 'endbeforehexten' logic to work correctly - there was always a new CDR waiting in the hangup logic and, even if 'ended', wouldn't be the CDR people wanted to inspect in the hangup routine. This patch completely removes the Pending state and instead defers creation of the new CDR until it gets a new message that requires a new CDR. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393777 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	4123b27f6f	Remove parkinglot from the channel snapshot ... Legacy channel drivers often include the ability to set a default parking lot on an endpoint basis; when channels are created for that endpoint, they inherit the parkinglot option. Parking used to use this option more frequently; while it is still supported, other options (such as using channel variables or creation of a custom parkinglot) are supported. More importantly, conveying the parkinglot information through a channel snapshot isn't terribly useful - it is rarely (if ever) changed on a channel and some consumers of channel snapshots, such as ARI, will never use the information. (closes issue ASTERISK-21968) Reported by: Matt Jordan git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393716 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	02f55a36a0	Revert accidental overcommit. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393632 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	b4e9a3fc2f	Add BUGBUG note for ASTERISK-22009 ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393631 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	c9a3d4562d	Update events to use Swagger 1.3 subtyping, and related aftermath ... This patch started with the simple idea of changing the /events data model to be more sane. The original model would send out events like: { "stasis_start": { "args": [], "channel": { ... } } } The event discriminator was the field name instead of being a value in the object, due to limitations in how Swagger 1.1 could model objects. While technically sufficient in communicating event information, it was really difficult to deal with in terms of client side JSON handling. This patch takes advantage of a proposed extension[1] to Swagger which allows type variance through the use of a discriminator field. This had a domino effect that made this a surprisingly large patch. [1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ In changing the models, I also had to change the swagger_model.py processor so it can handle the type discriminator and subtyping. I took that a big step forward, and using that information to generate an ari_model module, which can validate a JSON object against the Swagger model. The REST and WebSocket generators were changed to take advantage of the validators. If compiled with AST_DEVMODE enabled, JSON objects that don't match their corresponding models will not be sent out. For REST API calls, a 500 Internal Server response is sent. For WebSockets, the invalid JSON message is replaced with an error message. Since this took over about half of the job of the existing JSON generators, and the .to_json virtual function on messages took over the other half, I reluctantly removed the generators. The validators turned up all sorts of errors and inconsistencies in our data models, and the code. These were cleaned up, with checks in the code generator avoid some of the consistency problems in the future. * The model for a channel snapshot was trimmed down to match the information sent via AMI. Many of the field being sent were not useful in the general case. * The model for a bridge snapshot was updated to be more consistent with the other ARI models. Another impact of introducing subtyping was that the swagger-codegen documentation generator was insufficient (at least until it catches up with Swagger 1.2). I wanted it to be easier to generate docs for the API anyways, so I ported the wiki pages to use the Asterisk Swagger generator. In the process, I was able to clean up many of the model links, which would occasionally give inconsistent results on the wiki. I also added error responses to the wiki docs, making the wiki documentation more complete. Finally, since Stasis-HTTP will now be named Asterisk REST Interface (ARI), any new functions and files I created carry the ari_ prefix. I changed a few stasis_http references to ari where it was non-intrusive and made sense. (closes issue ASTERISK-21885) Review: https://reviewboard.asterisk.org/r/2639/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	a1e219ef51	CEL refactoring cleanup ... This change removes AST_CEL_BRIDGE_UPDATE since it should no longer be used because masquerade situations are now accounted for in other ways. This also refactors usage of AST_CEL_FORWARD to be produced by a Dial message which has been extended with a "forward" field. (closes issue ASTERISK-21566) Review: https://reviewboard.asterisk.org/r/2635/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392829 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	6258bbe7bd	Update Asterisk's CDRs for the new bridging framework ... 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	12 years ago
Kinsey Moore	4f84e48028	Refactor CEL channel events on top of Stasis-Core ... This uses the channel state change events from Stasis-Core to determine when channel-related CEL events should be raised. Those refactored in this patch are: * AST_CEL_CHANNEL_START * AST_CEL_ANSWER * AST_CEL_APP_START * AST_CEL_APP_END * AST_CEL_HANGUP * AST_CEL_CHANNEL_END Retirement of Linked IDs is also refactored. CEL configuration has been refactored to use the config framework. Note: Some HANGUP events are not generated correctly because the bridge layer does not propagate hangupcause/hangupsource information yet. Review: https://reviewboard.asterisk.org/r/2544/ (closes issue ASTERISK-21563) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391622 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	41e4282751	Fix memory leaks in stasis_channels and bridge_native_rtp ... This patch fixes two memory leaks: * A memory leak in packing channels into a multi-channel blob payload when publishing dial messages. The multi-channel blob payload does not steal the references - this approach was chosen because it works well with the RAII_VAR macro. Unfortunately, this does mean that you actually have to use the RAII_VAR macro (or manually deref it yourself) * RTP instances returned as a result of one of the glue operations are ref counted and have to be de-ref'd appropriately. We now do that, as saying that we should do it and then not would be silly. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391479 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	dbdb2b1b3a	Add vtable and methods for to_json and to_ami for Stasis messages ... When a Stasis message type is defined in a loadable module, handling those messages for AMI and res_stasis events can be cumbersome. This patch adds a vtable to stasis_message_type, with to_ami and to_json virtual functions. These allow messages to be handled abstractly without putting module-specific code in core. As an example, the VarSet AMI event was refactored to use the to_ami virtual function. (closes issue ASTERISK-21817) Review: https://reviewboard.asterisk.org/r/2579/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391403 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	759a7e4a30	Rework stasis cache clear events ... Stasis cache clear message payloads now consist of a stasis_message representative of the message to be cleared from the cache. This allows multiple parallel caches to coexist and be cleared properly by the same cache clear message even when keyed on different fields. This change fixes a bug where multiple cache clears could be posted for channels. The cache clear is now produced in the destructor instead of ast_hangup. Additionally, dummy channels are no longer capable of producing channel snapshots. Review: https://reviewboard.asterisk.org/r/2596 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390830 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	1458a20e47	Refactor code and fix a reference leak ... Refactor some channel blob publishing code to use ast_channel_publish_blob now that it is available and fix a JSON reference leak that was occurring during varset publishing. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390317 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago