161 Commits (0b625fcc697329af3ff1af426bd61d51830b7e40)

Author	SHA1	Message	Date
Joshua Colp	7cfd95ac44	When serializing CDR variables (like for "core show channels") don't output an error if CDRs aren't enabled. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400442 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	1d5b70a564	Only create Stasis subscriptions when enabled ... Subscribing to Stasis isn't free. As such, this patch makes AMI, CDR, and CEL - the "big 3" - only subscribe when enabled. Toggling their availability via a .conf file will unsubscribe/subscribe as appropriate. Review: https://reviewboard.asterisk.org/r/2888/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400312 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	3ccb6a9ea5	Fix the CDR CLI command 'cdr show active {channel}' ... When the switch from channel names to channel unique IDs happened, the poor CLI command got left in the dust. This fixes the command so that users can once again see how Asterisk is messing up your billing information. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400286 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	2efa0948dc	Filter out internal channels for bridge leave messages and parked call messages ... Granted, if you manage to park a Conference announcer channel, something has gone horrifically wrong. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400217 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	fa0d221bd3	Remove spurious event raised when CDRs are reloaded ... The Reload event is now raised by the module loading core. As such, the Reload event in the CDR engine was a duplicate and not needed. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400194 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	516dbe86a0	Remove dispatch object allocation from Stasis publishing ... While looking for areas for performance improvement, I realized that an unused feature in Stasis was negatively impacting performance. When a message is sent to a subscriber, a dispatch object is allocated for the dispatch, containing the topic the message was published to, the subscriber the message is being sent to, and the message itself. The topic is actually unused by any subscriber in Asterisk today. And the subscriber is associated with the taskprocessor the message is being dispatched to. First, this patch removes the unused topic parameter from Stasis subscription callbacks. Second, this patch introduces the concept of taskprocessor local data, data that may be set on a taskprocessor and provided along with the data pointer when a task is pushed using the ast_taskprocessor_push_local() call. This allows the task to have both data specific to that taskprocessor, in addition to data specific to that invocation. With those two changes, the dispatch object can be removed completely, and the message is simply refcounted and sent directly to the taskprocessor. Review: https://reviewboard.asterisk.org/r/2884/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400181 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	9d21631aee	Optimize how Stasis forwards are dispatched ... This patch optimizes how forwards are dispatched in Stasis. Originally, forwards were dispatched as subscriptions that are invoked on the publishing thread. This did not account for the vast number of forwards we would end up having in the system, and the amount of work it would take to walk though the forward subscriptions. This patch modifies Stasis so that rather than walking the tree of forwards on every dispatch, when forwards and subscriptions are changed, the subscriber list for every topic in the tree is changed. This has a couple of benefits. First, this reduces the workload of dispatching messages. It also reduces contention when dispatching to different topics that happen to forward to the same aggregation topic (as happens with all of the channel, bridge and endpoint topics). Since forwards are no longer subscriptions, the bulk of this patch is simply changing stasis_subscription objects to stasis_forward objects (which, admittedly, I should have done in the first place.) Since this required me to yet again put in a growing array, I finally abstracted that out into a set of ast_vector macros in asterisk/vector.h. Review: https://reviewboard.asterisk.org/r/2883/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400180 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	0b97ac8e87	CDR: Improve handling of parking; resolve assertion when originating into park ... This patch covers two problems: 1) Currently, when a call is transferred into a parking lot from a bridge (using either the blind transfer or one touch parking mechanisms), the application fails to be set to "Park" in the resulting CDR record for the parked channel. This is due to the ParkedCall message arriving before the BridgeEnter for the channel entering the parking bridge. The ParkedCall message isn't handled as the CDR for the channel has already been finalized (due to the channel having left its two party bridge), and the BridgeEnter - which creates the new CDR - doesn't have the parking information. This patch modifies the behavior so that reception of a ParkedCall message will - if not handled by a CDR chain - cause a new CDR to be created and put into the Parking state. 2) It fixes a FRACK that occurred when a channel is originated into a parking space. The DialedPending state - which occurs for both Dialed and Originated channels - assumed that it couldn't handle the parking transitions due to it having a Party B; however, Originated channels don't have a Party B. As such, the existing CDR needs to transition into the parking state - this patch does that. Review: https://reviewboard.asterisk.org/r/2877/ (closes issue ASTERISK-22482) Reported by: Richard Mudgett git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400062 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	c0576c7816	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/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@399666 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	5cf1cae533	Filter internal channels out of bridge enter/leave message handling ... Some channels exist merely as an implementation detail in Asterisk, such as ConfBridge's announcer/recorder channels. These channels should never be exposed to the outside world, or to interfaces that report on Asterisk. We already filter out such channels in snapshot processing; however, we failed to filter out bridge related messages that involved these channels. This patch filters out bridge related messages that are for such channels. This prevents a spurious WARNING message from being displayed when those channels move in and out of bridges. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@399146 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	83d741f85e	cdr: Change the number of container buckets to be similar to the channels container. ... * Fix the temporary cdr candidate containers to use a prime number of buckets. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@398579 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	334329de07	cdr: Fix some ref leaks. ... * Added missing unregister of the cdr container in cdr_engine_shutdown(). * Fixed ref leak in off nominal path of cdr_object_alloc(). * Removed some unnecessary NULL checks in cdr_object_dtor(). git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@398562 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	994a0da4d9	astobj2: Add warn unused attribute to some functions. ... * Fixed resulting warnings with improper use of ao2_global_obj_replace(). * Made a couple uses of ao2_global_obj_replace_unref(x, NULL) into the equivalent and more appropriate ao2_global_obj_release() call. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@398533 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kevin Harwell	4017609f8f	Memory leaks fix ... (closes ASTERISK-22376) Reported by: John Hardin Patches: memleak.patch uploaded by jhardin (license 6512) memleak2.patch uploaded by jhardin (license 6512) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397946 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	4fb3ae9ecf	Fix some uninitialized buffers for CDR handling valgrind found. ... * Made ast_strftime_locale() ensure that the output buffer is initialized. The std library strftime() returns 0 and does not touch the buffer if it has an error. However, the function can also return 0 without an error. (closes issue ASTERISK-22412) Reported by: rmudgett git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397902 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	45453100e9	Fixed problems with ast_cdr_serialize_variables(). ... * Fixed return value of ast_cdr_serialize_variables() on error. It needs to return 0 indicating no CDR variables found. * Made ast_cdr_serialize_variables() check the return value of cdr_object_format_property() and assert if nonzero. A member of the cdr_readonly_vars[] was not handled. * Removed unused elements from cdr_readonly_vars[]: total_duration, total_billsec, first_start, and first_answer. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397900 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	1b4793bb5e	Made the on/off in CLI "cdr set debug [on|off]" case insensitive. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397898 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	8c7c10010f	Make CDR variable name chandling consistently case insensitive. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397896 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	986911fa04	Make CDR code deal with channel names case insensitively. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397894 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	fa3370fdee	Some CDR code optimization. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397892 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	e47d3db365	Doxygen comment tweaks. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396857 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	8b75a68f13	Handle Surrogate channels in Dial message processing ... Depending on when a Surrogate channel replaces an existing channel, it is possible to get a Dial message for the Surrogate channel. When this occurs, no CDR will exist for the channel as Surrogate channels are ignored. Safely handle the case when a CDR doesn't exist for a Dial message. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396371 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	2e23bec461	Fix memory leaks in the CDR engine ... Fix refcount bugs and a possible locking problem in the CDR engine relating to use of ao2_iterators. Review: https://reviewboard.asterisk.org/r/2724/ (closes issue ASTERISK-22126) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396320 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Walter Doekes	ccdfe67bf2	Check result of ast_var_assign() calls for memory allocation failure. ... We try to keep the system running even when all available memory is spent. Review: https://reviewboard.asterisk.org/r/2734/ ........ Merged revisions 396279 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 396287 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396309 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	38236e54a8	Remove dead code from features.c; refactor pickup code into pickup.c ... 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	13 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	13 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	13 years ago
David M. Lee	fec667646f	Fix bridge/channel AMI event ordering issues ... The stasis_cache_update messages are somewhat cumbersome to handle with the stasis_message_router. Since all updates have the same message type, they are normally handled with the same route. Since caching itself is a first class component of stasis-core, it makes sense for the router to handle the cache update messages itself. This patch adds stasis_message_router_add_cache_update() and stasis_message_router_remove_cache_update() to handle the routing of stasis_cache_update messages. This patch also corrects an issue with manager_{bridging,channels}.c, where events might be reordered. The reordering occurs because the components use different message routers, which they needed because they both needed to route cache update messages. They now both use manager's router, and add cache routes for just the cache updates they are interested in. (closes issue ASTERISK-22038) Review: https://reviewboard.asterisk.org/r/2677/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395118 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	b4c2eecca6	Fix unbalanced lock when serializing CDR variables ... I'm only surprised that this didn't cause larger problems. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395089 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 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	13 years ago
Matthew Jordan	957f863dba	Re-order cleanup ... This patch attempts to fix some possible race conditions in shutdown of the CDR engine. It: * Adds a cleanup handler to only unsubscribe and join on stasis messages during graceful shutdown. The cleanup handler should execute before the regular atexit handler, as we want to unsubscribe for any further messages before dispatching the CDRs. * The CDRs are now locked when we dispatch them on shutdown. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394469 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	70decd0abe	Fix FRACK message from external redirects; handle outbound channels better ... This patch does the following: * It simplifies the Dial handling in CDRs. As a rule, the caller in a dial relationship is always the Party A. There was some logic present in the handling of the dial message that could, conceivably, pick the caller as Party A for the beginning of the dial and the peer as Party A for the end of the dial. This shouldn't have happened if the code in the bridging framework was doing its job; however, that was broken and it led to the FRACK. As it is, this code was overly ocmplex and not needed: the caller, if present, should always be Party A. Period. * It properly checks to see if a channel will continue on in the dialplan. ast_check_hangup - much like cake at the end - is a lie. It will tell you that you are hungup when you are not. Do not believe it. I would make this function tell the truth, but I'm nervous that we've been depending on it sitting on its throne of lies for far too long, and it would probably break lots of things. So I'm just checking the "internal" soft hangup flags, like everyone else. (closes issue ASTERISK-22060) Reported by: Mark Michelson (issue ASTERISK-21831) Reported by: Matt Jordan git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394290 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 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	13 years ago
Matthew Jordan	a981de9adb	Fix some bugs in CDRs; add some CLI commands to help debugging ... This patch fixes a few minor bugs and one major one: the CDR by bridge container was less than helpful. The mechanism previously used to try and find all of the CDRs in a particular bridge ended up missing CDRs, resulting in incorrect records. When looking up CDRs in a bridge, we now just bite the bullet and do a selection across all existing CDRs. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393599 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	ca61a05506	Handle an originated channel being sent into a non-empty bridge ... Originated channels are a bit odd - they are technically a dialed channel (thus the party B or peer) but, since there is no caller, they are treated as the party A. When entering into a bridge that already contains participants, the CDR engine - if the CDR record is in the Dial state - attempts to match the person entering the bridge with an existing participant. The idea is that if you dialed someone and the person you dialed is already in the bridge, you don't need a new CDR record, the existing CDR record describes the relationship. Unfortunately, for an originated channel, there is no Party B. If no one was in the bridge this didn't cause any issues; however, if participants were in the bridge the CDR engine would attempt to match a non-existant Party B on the channel's CDR record and explode. This patch fixes that, and a unit test has been added to cover this case. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393164 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	6cc03db642	Better handle parking in CDRs ... Parking typically occurs when a channel is transferred to a parking extension. When this occurs, the channel never actually hits the dialplan if the extension it was transferred to was a "parking extension", that is, the extension in the first priority calls the Park application. Instead, the channel is immediately sent into the holding bridge acting as the parking bridge. This is problematic. Because we never go out to the dialplan, the CDRs won't transition properly and the application field will not be set to "Park". CDRs typically swallow holding bridges, so the CDR itself won't even be generated. This patch handles this by pulling out the holding bridge handling into its own CDR state. CDRs now have an explicit parking state that accounts for this specific subclass of the holding bridge. In addition, we handle the parking stasis message to set application specific data on the CDR such that the last known application for the CDR properly reflects "Park". This is a bit sad since we're working around the odd internal implementation of parking that exists in Asterisk (and that we had to maintain in order to continue to meet some odd use cases of parking), but at least the code to handle that is where it belongs: in CDRs as opposed to sprinkled liberally throughout the codebase. This patch also properly clears the OUTBOUND channel flag from a channel when it leaves a bridge, and tweaks up dialing handling to properly compare the correct CDR with the channel calling/being dialed. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393130 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	91217ac3c1	Fix a variety of memory leaks ... This patch addresses the following memory/ref counting leaks: * main/devicestate.c - unsubscribe and join our devicestate message subscription * main/cel.c - clean up the datastore and config objects on exist * main/parking.c - cleanup memory leak of retriever snapshot on message payload destruction * res/parking/parking_bridge.c - cleanup memory leak of retrieve snapshot on message payload destruction * main/presencestate.c - unsubscribe and join the caching topic on exit * manager.c - properly unregister the manager action "BlindTransfer" * sorcery.c - shutdown the threadpool on exit and dispose of any wizards (issue ASTERISK-21906) Reported by: John Hardin patches: cel.patch uploaded by jhardin (license #6512) devicestate.patch uploaded by jhardin (license #6512) manager.patch uploaded by jardin (license #6512) presencestate.patch uploaded by jhardin (license #6512) retriever-channel-snapshot.patch uploaded by jhardin (license #6512) sorcery.patch uploaded by jhardin (license #6512) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392797 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	4aa47d6893	Fix build warnings related to printf/scanf of tv_usec. ... The type of tv_usec is suseconds_t. On Linux, this is usually a long int, but the specification is actually pretty lax on what it might actually be. And, sadly, there's no printf/scanf width specifier for suseconds_t. So it could bit an int or a long, but there's not a great way to tell which it is. This patch fixes scanf by reading into a long temporary variable that's then stored into the tv_usec. It fixes printf by casting the tv_usec to a long first. This patch also adds some missing width specifiers for some debug statements, which would cause ".000001" to be displayed at ".1". git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392076 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Joshua Colp	2e541ec265	Fix build warning (which is transmogrified into an error) with my compiler due to uninitialized variable. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391982 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 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	13 years ago
Matthew Jordan	06be8463b6	Migrate a large number of AMI events over to Stasis-Core ... This patch moves a number of AMI events over to the Stasis-Core message bus. This includes: * ChanSpyStart/Stop * MonitorStart/Stop * MusicOnHoldStart/Stop * FullyBooted/Reload * All Voicemail/MWI related events In addition, it adds some Stasis-Core and AMI support for generic AMI messages, refactors the message router in AMI to use a single router with topic forwarding for the topics that AMI cares about, and refactors MWI message types and topics to be more name compliant. Review: https://reviewboard.asterisk.org/r/2532 (closes issue ASTERISK-21462) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389733 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	ec7de8ed97	Resolve deadlock between pending CDR and batch CDR locks ... r375757 attempted to resolve a race condition between multiple submissions of CDRs while in batch mode from attempting to destroy the scheduled batch submission by extending the batch CDR lock. Unfortunately, this causes a deadlock between the pending CDR lock and the batch CDR lock. This patch resolves the intent of r375757 by simply providing a new lock that protects the scheduling of the batches. The original batch CDR lock is kept to protect manipulation of the batch CDR settings, but has been placed such that it is not held when the pending lock is held. Thanks to Chase Venters for providing lock analysis on the issue. (issue ASTERISK-21162) Reported by: Chase Venters ........ Merged revisions 383839 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 383840 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383841 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	b59c27000a	Cleanup CDR resources on exit. ... * Simplify do_reload() return handling since it never returned anything other than 0. (issue ASTERISK-20649) Reported by: Corey Farrell Patches: cdr-cleanup-1_8.patch (license #5909) patch uploaded by Corey Farrell cdr-cleanup-10-11-trunk.patch (license #5909) patch uploaded by Corey Farrell Modified ........ Merged revisions 377069 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 377070 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 377071 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377072 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	19282f682e	Prevent multiple CDR batches from conflicting when scheduling the CDR write ... The Asterisk Test Suite caught an error condition where a scheduled CDR batch write can be deleted twice if two channels attempt to post their CDRs at the same time. The batch CDR mutex is locked while the CDRs are appended to the current batch list; however, it is unlocked prior to actually scheduling the CDR write. As such, two threads can attempt to remove the currently scheduled batch write at the same time, resulting in an assertion error. This patch extends the time that the mutex is locked to encompass actually scheduling the write. This prevents two threads from unscheduling the currently scheduled write at the same time. ........ Merged revisions 375727 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 375728 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 375729 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375730 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Andrew Latham	6c20cf2d8a	Doxygen Updates - Title update ... Update and extend the configuration_file group and enable linking. Commit other cleanups from multi-version Doxygen testing. Update title that was left behind many years ago. (issue ASTERISK-20259) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375182 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Matthew Jordan	5ac43a08ad	Fix incorrect billing duration reported when batch mode is enabled ... Similar to r369351, the billing duration can be skewed when batch mode is enabled. This happened much more rarely than the duration, as it only occured when the call was answered (thereby indicating an actual answer time) and immediately hung up on (indicating a billsec of 0). Since a billing time of '0' can either mean that the call immediately ended or that the CDR was improperly answered, we have to use additional information to know whether or not we can trust the CDR billsec value. Prior to this patch, we looked to see if we had a valid answer time. If we did, and billsec was zero, we used the current time to calculate what billsec value we could from the CDR being written. If batch mode is enabled, this will incorrectly report a billsec value being much greater than the actual duration of the call. Instead of relying on the presence of an answer time to know whether or not we can re-calculate the billsec for the CDR, we now also use the presence of the CDR's end time to know if we need to re-calculate or whether we can trust the billsec value that we have. This prevents erroneous jumps in the billsec value, while still making sure that in the worst case, some billing time will be calculated. (closes issue AST-1016) Reported by: Thomas Arimont Tested by: Thomas Arimont ........ Merged revisions 374843 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 374844 from http://svn.asterisk.org/svn/asterisk/branches/10 ........ Merged revisions 374845 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374846 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Matthew Jordan	8018b879a2	Clean up doxygen warnings ... This patch fixes numerous doxygen warnings across Asterisk. It also updates the makefile to regenerate the doxygen configuration on the local system before running doxygen to help prevent warnings/errors on the local system. Much thanks to Andrew for tackling one of the Asterisk janitor projects! (issue ASTERISK-20259) Reported by: Andrew Latham Patches: doxygen_partial.diff uploaded by Andrew Latham (license 5985) make_progdocs.diff uploaded by Andrew Latham (license 5985) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371989 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Matthew Jordan	9bc2127d7b	Fix validation errors when producing documentation using default build script ... The awk script parses out the first instance of the DOCUMENTATION tag that it finds within a file. If a file did not previously have a DOCUMENTATION tag but received one due to it having an AMI event, then the XML fragment associated with the AMI event was erroneously placed in the resulting XML file. Without the python scripts, these XML fragments will not validate. This patch adds DOCUMENTATION tags at the top of those files that did not previously have them to prevent the awk script from pulling AMI event documentation. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369910 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Matthew Jordan	2ffae5745d	Add some additional documentation for core AMI events ... This patch adds some basic documentation for a number of modules. This includes core source files in Asterisk (those in main), as well as chan_agent, chan_dahdi, chan_local, sig_analog, and sig_pri. The DTD has also been updated to allow referencing of AMI commands. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369905 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Matthew Jordan	bebdbf3381	Fix incorrect duration reporting in CDRs created in batch mode ... Certain places in core/cdr.c would, if the duration value were 0, calculate the duration as being the delta between the current time and the time at which the CDR record was started. While this does not typically cause a problem in non-batch mode, this can cause an issue in batch mode where CDR records are gathered and written long after those calls have ended. In particular, this affects calls that were never answered, as those are expected to have a duration of 0. Often, this would result in CDR logs with a significant number of calls with lengthy durations, but dispositions of "BUSY". Note that this does not affect cdr_csv, as that backend does not use ast_cdr_getvar and instead directly reports the duration value. The affected core backends include cdr_apative_odbc and cdr_custom; other extended or deprecated CDR backends may potentially still directly manipulate the duration values. (issue ASTERISK-19860) Reported by: Thomas Arimont (issue AST-883) Reported by: Thomas Arimont Tested by: Matt Jordan Review: https://reviewboard.asterisk.org/r/1996/ ........ Merged revisions 369351 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 369369 from http://svn.asterisk.org/svn/asterisk/branches/10 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369370 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago