917 Commits (20ee33e22e3724c35ab3078c5032b87af5b4920c)

Author	SHA1	Message	Date
Ivan Poddubny	87263b47b5	app_queue: Fix queue_log EXITWITHTIMEOUT containing only 1 parameter ... This patch fixes EXITWITHTIMEOUT queue_log entry to always come with 3 parameters: position, original position and waiting time. ASTERISK-25038 #close Reported by: Etienne Lessard Change-Id: I0c62045922e26bee2125e93aee1dee17eee79618	10 years ago
Mark Michelson	4f1a8dbe92	Detect potential forwarding loops based on count. ... A potential problem that can arise is the following: * Bob's phone is programmed to automatically forward to Carol. * Carol's phone is programmed to automatically forward to Bob. * Alice calls Bob. If left unchecked, this results in an endless loops of call forwards that would eventually result in some sort of fiery crash. Asterisk's method of solving this issue was to track which interfaces had been dialed. If a destination were dialed a second time, then the attempt to call that destination would fail since a loop was detected. The problem with this method is that call forwarding has evolved. Some SIP phones allow for a user to manually forward an incoming call to an ad-hoc destination. This can mean that: * There are legitimate use cases where a device may be dialed multiple times, or * There can be human error when forwarding calls. This change removes the old method of detecting forwarding loops in favor of keeping a count of the number of destinations a channel has dialed on a particular branch of a call. If the number exceeds the set number of max forwards, then the call fails. This approach has the following advantages over the old: * It is much simpler. * It can detect loops involving local channels. * It is user configurable. The only disadvantage it has is that in the case where there is a legitimate forwarding loop present, it takes longer to detect it. However, the forwarding loop is still properly detected and the call is cleaned up as it should be. Address review feedback on gerrit. * Correct "mfgium" to "Digium" * Decrement max forwards by one in the case where allocation of the max forwards datastore is required. * Remove irrelevant code change from pjsip_global_headers.c ASTERISK-24958 #close Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23	10 years ago
Matthew Jordan	e05c8ae68e	apps/app_queue: Prevent possible crash when evaluating queue penalty rules ... Although it only occurred once, a crash occurred when a queue attempted to evaluate a queue penalty rule that appeared to have already been destroyed. In many locations in app_queue, a test is done to see if qe->pr is NULL; however, when we dispose of a queue's penalty rules, we don't set the pointer to NULL after free'ing it. This patch does that to prevent any dangling pointers from lingering on the queue object. Review: https://reviewboard.asterisk.org/r/4522 ASTERISK-23319 #close Reported by: Vadim patches: rb4552.patch submitted by Stefan Engström (License 6691) ........ Merged revisions 434448 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434449 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Matthew Jordan	f324870dab	clang compiler warnings: Fix pointer-bool-converesion warnings ... This patch fixes several warnings pointed out by the clang compiler. * chan_pjsip: Removed check for data->text, as it will always be non-NULL. * app_minivm: Fixed evaluation of etemplate->locale, which will always evaluate to 'true'. This patch changes the evaluation to use ast_strlen_zero. * app_queue: - Fixed evaluation of qe->parent->monfmt, which always evaluates to true. Instead, we just check to see if the dereferenced pointer evaluates to true. - Fixed evaluation of mem->state_interface, wrapping it with a call to ast_strlen_zero. * res_smdi: Wrapped search_msg->mesg_desk_term with calls to ast_strlen_zero. Review: https://reviewboard.asterisk.org/r/4541 ASTERISK-24917 Reported by: dkdegroot patches: rb4541.patch submitted by dkdegroot (License 6600) ........ Merged revisions 434285 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434286 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Matthew Jordan	5f8faf16af	clang compiler warnings: Fix -Wabsolute-value warnings ... This patch fixes several warnings caught by clang - in this case, usage of the abs function on non-integer values. This patch uses labs and fabs, as appropriate, in the various affected files. Review: https://reviewboard.asterisk.org/r/4525 ASTERISK-24917 Reported by: dkdegroot patches: rb4525.patch submitted by dkdegroot (License 6600) ........ Merged revisions 433749 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433750 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Matthew Jordan	e126ab9eeb	clang compiler warnings: Fix a variety of "unused" warnings ... This patch fixes the -Wunused-value -Wunused-variable -Wunused-const-variable errors caught by clang. Specifically: * apps/app_queue.c: removed unused qpm_cmd_usage[], qum_cmd_usage[], qsmp_cmd_usage[] * cel/cel_sqlite3_custom.c: removed unused name[] = "cel_sqlite3_custom" * channels/chan_pjsip.c: removed unused desc[] = "PJSIP Channel" * codecs/gsm/src/gsm_create.c: removed unused ident[] = "$Header$" * funcs/func_env.c:729: Fixed ast_str_append_substr. * main/editline/np/strlcat.c: removed unused rcsid variable * main/editline/np/strlcpy.c: removed unused rcsid variable * main/security_events.c: removed unused TIMESTAMP_STR_LEN * utils/conf2ael.c: removed unused cfextension_states * utils/extconf.c: removed unused cfextension_states Review: https://reviewboard.asterisk.org/r/4526 ASTERISK-24917 Reported by: dkdegroot patches: rb4526.patch submitted by dkdegroot (License 6600) ........ Merged revisions 433693 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433694 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Matthew Jordan	a3fe43fbdc	Fix compilations errors on 64-bit OpenBSD systems ... In versiong 5.5, OpenBSD went to 64-bit time values. This requires a cast to (long) when printing members of certain time structs. Review: https://reviewboard.asterisk.org/r/4507 ASTERISK-24879 #close Reported by: snuffy Tested by: snuffy patches: openbsd-time64.diff uploaded by snuffy (License 5024) ........ Merged revisions 433268 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433269 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Richard Mudgett	4b363688d4	AMI: Make AMI actions that generate event lists consistent. ... * Made the following AMI actions use list API calls for consistency: Agents BridgeInfo BridgeList BridgeTechnologyList ConfbridgeLIst ConfbridgeLIstRooms CoreShowChannels DAHDIShowChannels DBGet DeviceStateList ExtensionStateList FAXSessions Hangup IAXpeerlist IAXpeers IAXregistry MeetmeList MeetmeListRooms MWIGet ParkedCalls Parkinglots PJSIPShowEndpoint PJSIPShowEndpoints PJSIPShowRegistrationsInbound PJSIPShowRegistrationsOutbound PJSIPShowResourceLists PJSIPShowSubscriptionsInbound PJSIPShowSubscriptionsOutbound PresenceStateList PRIShowSpans QueueStatus QueueSummary ShowDialPlan SIPpeers SIPpeerstatus SIPshowregistry SKINNYdevices SKINNYlines Status VoicemailUsersList * Incremented the AMI version to 2.7.0. * Changed astman_send_listack() to not use the listflag parameter and always set the value to "Start" so the start capitalization is consistent. i.e., The FAXSessions used "Start" while the rest of the system used "start". The corresponding complete event always used "Complete". * Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the AMI ActionID for all of its list events. * Fixed off-nominal AMI protocol error in manager_bridge_info(), manager_parking_status_single_lot(), and manager_parking_status_all_lots(). Use of astman_send_error() after responding to the original AMI action request violates the action response pattern by sending two responses. * Fixed minor protocol error in action_getconfig() when no requested categories are found. Each line needs to be formatted as "Header: text". * Fixed off-nominal memory leak in manager_build_parked_call_string(). * Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail(). ASTERISK-24049 #close Reported by: Jonathan Rose Review: https://reviewboard.asterisk.org/r/4315/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430434 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	d79c68d3fb	main/stasis: Allow subscriptions to use a threadpool for message delivery ... Prior to this patch, all Stasis subscriptions would receive a dedicated thread for servicing published messages. In contrast, prior to r400178 (see review https://reviewboard.asterisk.org/r/2881/), the subscriptions shared a thread pool. It was discovered during some initial work on Stasis that, for a low subscription count with high message throughput, the threadpool was not as performant as simply having a dedicated thread per subscriber. For situations where a subscriber receives a substantial number of messages and is always present, the model of having a dedicated thread per subscriber makes sense. While we still have plenty of subscriptions that would follow this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into the following two categories: * Large number of subscriptions, specifically those tied to endpoints/peers. * Low number of messages. Some subscriptions exist specifically to coordinate a single message - the subscription is created, a message is published, the delivery is synchronized, and the subscription is destroyed. In both of the latter two cases, creating a dedicated thread is wasteful (and in the case of a large number of peers/endpoints, harmful). In those cases, having shared delivery threads is far more performant. This patch adds the ability of a subscriber to Stasis to choose whether or not their messages are dispatched on a dedicated thread or on a threadpool. The threadpool is configurable through stasis.conf. Review: https://reviewboard.asterisk.org/r/4193 ASTERISK-24533 #close Reported by: xrobau Tested by: xrobau ........ Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428687 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	1536b0ecb6	Fix race condition that could result in ARI transfer messages not being sent. ... From reviewboard: "During blind transfer testing, it was noticed that tests were failing occasionally because the ARI blind transfer event was not being sent. After investigating, I detected a race condition in the blind transfer code. When blind transferring a single channel, the actual transfer operation (i.e. removing the transferee from the bridge and directing them to the proper dialplan location) is queued onto the transferee bridge channel. After queuing the transfer operation, the blind transfer Stasis message is published. At the time of publication, snapshots of the channels and bridge involved are created. The ARI subscriber to the blind transfer Stasis message then attempts to determine if the bridge or any of the involved channels are subscribed to by ARI applications. If so, then the blind transfer message is sent to the applications. The way that the ARI blind transfer message handler works is to first see if the transferer channel is subscribed to. If not, then iterate over all the channel IDs in the bridge snapshot and determine if any of those are subscribed to. In the test we were running, the lone transferee channel was subscribed to, so an ARI event should have been sent to our application. Occasionally, though, the bridge snapshot did not have any channels IDs on it at all. Why? The problem is that since the blind transfer operation is handled by a separate thread, it is possible that the transfer will have completed and the channels removed from the bridge before we publish the blind transfer Stasis message. Since the blind transfer has completed, the bridge on which the transfer occurred no longer has any channels on it, so the resulting bridge snapshot has no channels on it. Through investigation of the code, I found that attended transfers can have this issue too for the case where a transferee is transferred to an application." The fix employed here is to decouple the creation of snapshots for the transfer messages from the publication of the transfer messages. This way, snapshots can be created to reflect what they are at the time of the transfer operation. Review: https://reviewboard.asterisk.org/r/4135 ........ Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427870 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Corey Farrell	7bd256b711	app_queue: fix a couple leaks to struct call_queue in set_member_value ... set_member_value has a couple leaks to references in the variable q found through testsuite tests/queues/set_penalty. Also remove the REF_DEBUG_ONLY_QUEUES compiler declaration, this is no longer possible with the updated REF_DEBUG code. ASTERISK-24466 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4125/ ........ Merged revisions 426805 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 426806 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426807 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Corey Farrell	688edd55c3	app_queue: Cleanup ao2_iterator ... Clean ao2_iterator, resolving reference leak to queue members. ASTERISK-24454 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4111/ ........ Merged revisions 426255 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 426260 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426266 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	95871451f6	app_queue: Add RealTime support for queue rules ... This patch gives the optional ability to keep queue rules in RealTime. It is important to note that with this patch: (a) Queue rules in RealTime are only examined on module load/reload (b) Queue rules are loaded both from the queuerules.conf file as well as the RealTime backend To inform app_queue to examine RealTime for queue rules, a new setting has been added to queuerules.conf's general section "realtime_rules". RealTime queue rules will only be used when this setting is set to "yes". The schema for the database table supports a rule_name, time, min_penalty, and max_penalty columns. min_penalty and max_penalty can be relative, if a '-' or '+' literal is provided. Otherwise, the penalties are treated as constants. For example: rule_name, time, min_penalty, max_penalty 'default', '10', '20', '30' 'test2', '20', '30', '55' 'test2', '25', '-11', '+1111' 'test2', '400', '112', '333' 'test3', '0', '4564', '46546' 'test_rule', '40', '15', '50' which would result in : Rule: default - After 10 seconds, adjust QUEUE_MAX_PENALTY to 30 and adjust QUEUE_MIN_PENALTY to 20 Rule: test2 - After 20 seconds, adjust QUEUE_MAX_PENALTY to 55 and adjust QUEUE_MIN_PENALTY to 30 - After 25 seconds, adjust QUEUE_MAX_PENALTY by 1111 and adjust QUEUE_MIN_PENALTY by -11 - After 400 seconds, adjust QUEUE_MAX_PENALTY to 333 and adjust QUEUE_MIN_PENALTY to 112 Rule: test3 - After 0 seconds, adjust QUEUE_MAX_PENALTY to 46546 and adjust QUEUE_MIN_PENALTY to 4564 Rule: test_rule - After 40 seconds, adjust QUEUE_MAX_PENALTY to 50 and adjust QUEUE_MIN_PENALTY to 15 If you use RealTime, the queue rules will be always reloaded on a module reload, even if the underlying file did not change. With the option disabled, the rules will only be reloaded if the file was modified. Review: https://reviewboard.asterisk.org/r/3607/ ASTERISK-23823 #close Reported by: Michael K patches: app_queue.c_realtime_trunk.patch uploaded by Michael K (License 6621) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420624 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	0ac7f96057	Stasis: Convey transfer information to applications ... This fixes a class of issues where Stasis applications were not made aware that their channels were being manipulated or replaced by external entitiessuch as transfers, AMI commands, or dialplan applications such as Bridge(). Inconsistent information such as StasisEnd events with unknown channels as a result of masquerades has also been corrected. To accomplish these fixes, several new fields were added to blind and attended transfer messages as well as StasisStart and BridgeAttendedTransfer Stasis events. ASTERISK-23941 #close Review: https://reviewboard.asterisk.org/r/3865/ Review: https://reviewboard.asterisk.org/r/3857/ Review: https://reviewboard.asterisk.org/r/3852/ Review: https://reviewboard.asterisk.org/r/3816/ Review: https://reviewboard.asterisk.org/r/3731/ Review: https://reviewboard.asterisk.org/r/3729/ Review: https://reviewboard.asterisk.org/r/3728/ ........ Merged revisions 420325 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420338 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
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
Mark Michelson	dcf1ad14da	Add module support level to ast_module_info structure. Print it in CLI "module show" . ... ASTERISK-23919 #close Reported by Malcolm Davenport Review: https://reviewboard.asterisk.org/r/3802 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	a2ce95d9d2	accountcode: Slightly change accountcode propagation. ... The previous behavior was to simply set the accountcode of an outgoing channel to the accountcode of the channel initiating the call. It was done this way a long time ago to allow the accountcode set on the SIP/100 channel to be propagated to a local channel so the dialplan execution on the Local;2 channel would have the SIP/100 accountcode available. SIP/100 -> Local;1/Local;2 -> SIP/200 Propagating the SIP/100 accountcode to the local channels is very useful. Without any dialplan manipulation, all channels in this call would have the same accountcode. Using dialplan, you can set a different accountcode on the SIP/200 channel either by setting the accountcode on the Local;2 channel or by the Dial application's b(pre-dial), M(macro) or U(gosub) options, or by the FollowMe application's b(pre-dial) option, or by the Queue application's macro or gosub options. Before Asterisk v12, the altered accountcode on SIP/200 will remain until the local channels optimize out and the accountcode would change to the SIP/100 accountcode. Asterisk v1.8 attempted to add peeraccount support but ultimately had to punt on the support. The peeraccount support was rendered useless because of how the CDR code needed to unconditionally force the caller's accountcode onto the peer channel's accountcode. The CEL events were thus intentionally made to always use the channel's accountcode as the peeraccount value. With the arrival of Asterisk v12, the situation has improved somewhat so peeraccount support can be made to work. Using the indicated example, the the accountcode values become as follows when the peeraccount is set on SIP/100 before calling SIP/200: SIP/100 ---> Local;1 ---- Local;2 ---> SIP/200 acct: 100 \/ acct: 200 \/ acct: 100 \/ acct: 200 peer: 200 /\ peer: 100 /\ peer: 200 /\ peer: 100 If a channel already has an accountcode it can only change by the following explicit user actions: 1) A channel originate method that can specify an accountcode to use. 2) The calling channel propagating its non-empty peeraccount or its non-empty accountcode if the peeraccount was empty to the outgoing channel's accountcode before initiating the dial. e.g., Dial and FollowMe. The exception to this propagation method is Queue. Queue will only propagate peeraccounts this way only if the outgoing channel does not have an accountcode. 3) Dialplan using CHANNEL(accountcode). 4) Dialplan using CHANNEL(peeraccount) on the other end of a local channel pair. If a channel does not have an accountcode it can get one from the following places: 1) The channel driver's configuration at channel creation. 2) Explicit user action as already indicated. 3) Entering a basic or stasis-mixing bridge from a peer channel's peeraccount value. You can specify the accountcode for an outgoing channel by setting the CHANNEL(peeraccount) before using the Dial, FollowMe, and Queue applications. Queue adds the wrinkle that it will not overwrite an existing accountcode on the outgoing channel with the calling channels values. Accountcode and peeraccount values propagate to an outgoing channel before dialing. Accountcodes also propagate when channels enter or leave a basic or stasis-mixing bridge. The peeraccount value only makes sense for mixing bridges with two channels; it is meaningless otherwise. * Made peeraccount functional by changing accountcode propagation as described above. * Fixed CEL extracting the wrong ie value for the peeraccount. This was done intentionally in Asterisk v1.8 when that version had to punt on peeraccount. * Fixed a few places dealing with accountcodes that were reading from channels without the lock held. AFS-65 #close Review: https://reviewboard.asterisk.org/r/3601/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419520 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
Scott Griepentrog	fa8c58fefb	app_queue: delayed state can cause early leavewhenempty ringing ... In app_queue, device state changes arrive in event messages and update the queue member status value. That value is checked in get_member_status() to decide that the caller should leave when there are no available members. Although event messages can be delayed by other activity, there is no adverse affect by lagged status except in one specific case: there is only one available member, it was just rung, and leavewhenempty is enabled set for ringing members. This change adds a direct check of the device state only under this condition where the caller may be dropped incorrectly, resolving this issue without affecting performance of app_queue normally. AST-1248 #close Review: https://reviewboard.asterisk.org/r/3595/ Reported by: Thomas Arimont ........ Merged revisions 415833 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 415835 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 415836 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415839 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	abd3e4040b	Allow Asterisk to compile under GCC 4.10 ... This resolves a large number of compiler warnings from GCC 4.10 which cause the build to fail under dev mode. The vast majority are signed/unsigned mismatches in printf-style format strings. ........ Merged revisions 413586 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 413587 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 413588 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413589 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	f2ca3438e7	app_queue: Extend documentation for various Manager actions and events. ... ........ Merged revisions 413485 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 413486 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 413487 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413488 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
Russell Bryant	5b7a769fd8	(mix)monitor: Add options to enable a periodic beep ... Add an option to enable a periodic beep to be played into a call if it is being recorded. If enabled, it uses the PERIODIC_HOOK() function internally to play the 'beep' prompt into the call at a specified interval. This option is provided for both Monitor() and MixMonitor(). Review: https://reviewboard.asterisk.org/r/3424/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412427 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Walter Doekes	76d5c4ed43	app_queue: Re-add HoldTime to QueueCallerAbandon event (simple typo during ast12 refactor). ... Reported by: Ibrahim22 (on IRC) Tested by: Ibrahim22 ........ Merged revisions 411811 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411812 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	c7b8633c26	app_queue: Fix a bug where realtime members would be deleted during reload causing waiting callers to get ejected. ... This patch causes realtime queue members to remain in queues during the reload process. Previously these members would be removed causing any waiting callers to be ejected from the queue with a reason of "EXITEMPTY". ASTERISK-23547 #close ASTERISK-23547 #comment Patch app_queue_fix_realtime_reload_1.8_trunk.patch submitted by Italo Rossi (license 6409) Review: https://reviewboard.asterisk.org/r/3404/ ........ Merged revisions 411584 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 411585 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 411586 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411587 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Scott Griepentrog	80ef9a21b9	uniqueid: channel linkedid, ami, ari object creation with id's ... Much needed was a way to assign id to objects on creation, and much change was necessary to accomplish it. Channel uniqueids and linkedids are split into separate string and creation time components without breaking linkedid propgation. This allowed the uniqueid to be specified by the user interface - and those values are now carried through to channel creation, adding the assignedids value to every function in the chain including the channel drivers. For local channels, the second channel can be specified or left to default to a ;2 suffix of first. In ARI, bridge, playback, and snoop objects can also be created with a specified uniqueid. Along the way, the args order to allocating channels was fixed in chan_mgcp and chan_gtalk, and linkedid is no longer lost as masquerade occurs. (closes issue ASTERISK-23120) Review: https://reviewboard.asterisk.org/r/3191/ ........ Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	abf1d883f7	app_queue: Fix documented AMI event name ... During the rewrite of AMI events to use the Stasis bus, the name of the QueueMemberPaused event was changed to QueueMemberPause. This corrects documentation to reflect that. ........ Merged revisions 409234 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409237 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Rusty Newton	b17c80f4f0	apps/app_queue - Fix incorrect Macro parameter documentation ... Macro is executed on the called channel, not the calling channel. (closes issue ASTERISK-23069) Reported By: Bryan Anderson ........ Merged revisions 408447 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 408448 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 408449 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408450 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Rusty Newton	f6647d2362	Documentation: doc fixes across various parts of the code for ASTERISK issues 23061,23028,23046,23027 ... Fixes typos of "transfered" instead of "transferred" in various code. Fixes incorrect gosub param help text for app_queue. Fixes Asterisk man pages containing unquoted minus signs. Adds note about the "textsupport" option in sip.conf.sample. (issue ASTERISK-23061) (issue ASTERISK-23028) (issue ASTERISK-23046) (issue ASTERISK-23027) (closes issue ASTERISK-23061) (closes issue ASTERISK-23028) (closes issue ASTERISK-23046) (closes issue ASTERISK-23027) Reported by: Eugene, Jeremy Laine, Denis Pantsyrev Patches: transferred.patch uploaded by Jeremy Laine (license 6561) hyphen.patch uploaded by Jeremy Laine (license 6561) sip.conf.sample.patch uploaded by Eugene (license 6360) ........ Merged revisions 405791 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 405792 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 405829 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405830 65c4cc65-6c06-0410-ace0-fbb531ad65f3	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
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	483d127d55	app_queue: Honor penalty limits of 0 ... In the current app_queue code from 1.8 up to trunk the upper and lower penalties can be set to 0 but the value is interpreted to be disabled instead of actually setting limits. This is especially evident if min and max limits are set to 0 and members with penalties of 0 and 1 are in the queue since the member with penalty 1 will still receive calls. This patch adjusts the special disabled value to be INT_MAX instead of 0. (closes issue ASTERISK-20862) Review: https://reviewboard.asterisk.org/r/2995/ Reported by: Schmooze Com ........ Merged revisions 402645 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 402646 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 402647 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402648 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kevin Harwell	cdfbc02df1	app_queue: crash if first agent is "busy" ... If the first agent/member (via CLI "queue show") in a queue is "busy" (dnd, circuit busy, etc...) and no agents answered then app_queue would crash. This occurred because while the calling of agent(s) remained valid the channel on "busy" agent would be set to NULL and then later dereferenced upon a second "rna" function call. The original intention of the code is to have only valid "call attempt" objects (channels != NULL) checked while attempting to call agent(s). It does this by building a "call_next" list of valid "call attempt" objects. In the case of the "busy" agent subsequent builds of the valid "call attempt" list would sometimes include (the case mentioned above) an invalid "call attempt" object. The fix was to make sure the "call attempt" list was appropriately built on every iteration. A NULL sanity check was also added at the original offending spot of the crash just in case another one slipped by somehow. (closes issue ASTERISK-22644) Reported by: Marco Signorini Review: https://reviewboard.asterisk.org/r/2983/ ........ Merged revisions 402517 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402518 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	4ae7a4b1ba	app_queue: Fix CLI "queue remove member" queue_log entry. ... The queue_log entry resulting from CLI "queue remove member" when log_membername_as_agent is enabled is wrong. It always uses the interface name instead of the member name in the queue_log entry. * Get the queue member before removing it from the queue so the member name is available for the queue_log entry. (closes issue ASTERISK-21826) Reported by: Oscar Esteve Patches: fix_membername.diff (license #6505) patch uploaded by Oscar Esteve (modified to fix potential ref leak) ........ Merged revisions 401433 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 401434 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401435 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Walter Doekes	e694a976f6	Don't check all realtime queues when doing "queue show some_queue". ... When using realtime queues, queues have to be fetched from the database every now and then to see if any info has been changed or to see if the queue has been removed. When fetching info for an individual queue, the pruning of other queues is unnecessarily costly. Review: https://reviewboard.asterisk.org/r/2907/ ........ Merged revisions 401049 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 401076 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 401077 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401079 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	8eec8fbf83	Make app_queue and res_agi independent of AMI being enabled. ... The https://reviewboard.asterisk.org/r/2888/ review changes manager to not subscribe to stasis when it is disabled for performance reasons. When manager is disabled app_queue and res_agi decline to load and fail to clean up what they have already allocated. * Made app_queue and res_agi clean up allocated resources when they decline to load. * Made app_queue and res_agi use their own subscriptions to the stasis topics instead of borrowing manager's message router structure inappropriately. (closes issue ASTERISK-22604) Reported by: rmudgett Review: https://reviewboard.asterisk.org/r/2902/ ........ Merged revisions 400671 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400672 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	96d27333d2	Miscellaneous stand alone comment cleanups. ... ........ Merged revisions 400661 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400662 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Michael L. Young	0e218f76e2	app_queue: Fix Queuelog EXITWITHKEY only logging two of four fields ... Commit r62462 added two extra fields for logging "the original position the caller entered the queue at, and the amount of time the caller was waiting in the queue." But when r75969 was merged from 1.4 into trunk (r75977), these two fields disappeared. Those two extra fields were not logged in 1.4 and when the patch was merged, those fields went away. Therefore, this is a regression and was caught by the reporter because he was reading the awesome "Asterisk: The Definitive Guide" book. (closes issue ASTERISK-22197) Reported by: Dalius M. Tested by: Dalius M. Patches: asterisk-22197-q-log-exitwithkey.diff uploaded by Michael L. Young (license 5026) Review: https://reviewboard.asterisk.org/r/2901/ ........ Merged revisions 400622 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 400623 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 400624 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400625 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	2de42c2a25	Multiple revisions 399887,400138,400178,400180-400181 ... ........ r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line Minor performance bump by not allocate manager variable struct if we don't need it ........ r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines Stasis performance improvements This patch addresses several performance problems that were found in the initial performance testing of Asterisk 12. The Stasis dispatch object was allocated as an AO2 object, even though it has a very confined lifecycle. This was replaced with a straight ast_malloc(). The Stasis message router was spending an inordinate amount of time searching hash tables. In this case, most of our routers had 6 or fewer routes in them to begin with. This was replaced with an array that's searched linearly for the route. We more heavily rely on AO2 objects in Asterisk 12, and the memset() in ao2_ref() actually became noticeable on the profile. This was #ifdef'ed to only run when AO2_DEBUG was enabled. After being misled by an erroneous comment in taskprocessor.c during profiling, the wrong comment was removed. Review: https://reviewboard.asterisk.org/r/2873/ ........ r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines Taskprocessor optimization; switch Stasis to use taskprocessors This patch optimizes taskprocessor to use a semaphore for signaling, which the OS can do a better job at managing contention and waiting that we can with a mutex and condition. The taskprocessor execution was also slightly optimized to reduce the number of locks taken. The only observable difference in the taskprocessor implementation is that when the final reference to the taskprocessor goes away, it will execute all tasks to completion instead of discarding the unexecuted tasks. For systems where unnamed semaphores are not supported, a really simple semaphore implementation is provided. (Which gives identical performance as the original taskprocessor implementation). The way we ended up implementing Stasis caused the threadpool to be a burden instead of a boost to performance. This was switched to just use taskprocessors directly for subscriptions. Review: https://reviewboard.asterisk.org/r/2881/ ........ r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines 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/ ........ r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines 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/ ........ Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	ccab0f27bc	app_queue: Make manager events tolerant of Local channel shenanigans ... app_queue currently attempts to handle Local channel optimizations in an effort to provide accurate information in Stasis messages (and their corresponding AMI events) as well as the Queue log. Sometimes, however, things don't go as planned. Consider the following scenario: SIP/foo <-> L;1 <-> L;2 <-> SIP/agent SIP/agent answers, triggering a Local channel optimization. app_queue will normally do the following: * Listen for the Local optimization events and update our agent accordingly to SIP/agent in the queue log and messages * When we get a hangup, publish the AgentComplete event based on our information (SIP/foo and SIP/agent) However, as with all things that depend on sanity from something as capricious as Local channels, things can go wrong: (1) SIP/agent immediately hangs up upon answering. This triggers a race condition between termination messages coming from SIP/agent and the ongoing Local channel optimization messages. (Note that this can also occur with SIP/foo) (2) In a race condition, Asterisk can (rarely) deliver the hangup messages prior to the Local channel optimization. In that case, the messages *may* arrive to app_queue in the following order: * Hangup SIP/Agent * Hangup SIP/foo * Optimize L;1/L;2 * Hangup L;2 * Hangup L;1 When app_queue receives the hangup of the agent or the caller, it will attempt to publish the AgentComplete event. However, it now has a problem - it thinks its agent is the ;1 side of the Local channel, as it never received the optimization event. At the same time, that channel is already gone. This results in getting NULL from the Stasis cache. What's more, we can't really wait for the optimization message, as we are currently handling the hangup of the channel that the optimization event would tell us to use. This patch modifies the behavior in app_queue such that, since we still have a lot of pertinent queue information (interface, queue name, etc.), we now raise the event with what information we know. The channels involved now may or may not be present. Users will still at least get the "AgentComplete" event, which "completes" the known Agent information. Review: https://reviewboard.asterisk.org/r/2878/ (closes issue ASTERISK-22507) Reported by: Richard Mudgett ........ Merged revisions 400060 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400061 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	57e652f2ac	app_queue: Don't be quite so aggressive in initializing the array ... We only need the first character. ........ Merged revisions 399695 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399696 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	0618d89499	app_queue: Initialize array holding MixMonitor exec options ... If the channel variable MONITOR_EXEC is set, app_queue will pass the specified execution parameters to the MixMonitor application when a queue is recorded. If that channel variable is not set, the buffer that holds the escaped value was not being initialized to NULL, and so would be passed to the MixMonitor application with garbage. Hilarity ensued as app_mixmonitor attempted to execute gobeldy-gook. ........ Merged revisions 399681 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399682 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	5afbc01d5d	app_queue: Fix json blob ref leak. ... The json ref from queue_member_blob_create() was never released. ........ Merged revisions 399583 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399584 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Rusty Newton	4e3f78ad7b	'queue add member' help text correction ... You are adding dial strings to the queue, not channels. An aribitrary string could be used, but you are typically referencing a channel. Correcting the command help text. (issue ASTERISK-22263) (closes issue ASTERISK-22263) Reported By: Rusty Newton ........ Merged revisions 398884 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 398885 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 398886 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398887 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
Mark Michelson	8300c9aaaf	Remove set but unused variable 'meid'. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397466 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	00baddb906	Massively clean up app_queue. ... This essentially makes app_queue usable again. From reviewboard: * Reporting of transfers and call completion is done by creating stasis subscriptions and listening for specific events in order to determine when the call is finished (either via a transfer or hangup). * Dial end messages have been added where they were previously missing. * Queue stats are properly being updated again once calls have finished. * AgentComplete stasis messages and AMI events are now occurring again. * Mixmonitor starting has been factored into its own function and uses the Mixmonitor API now instead of using ast_pbx_run() In addition to the changes in app_queue, there are several supplementary changes as well: * Queue logging now differentiates between attended and blind transfers. A note about this is in the CHANGES file. * Local channel optimization events now report more information. This includes which of the two local channels involved is the destination of the optimization, the channel that is replacing the destination local channel, and an identifier so that begin and end events can be matched to each other. The end events are now sent whether the optimization was successful or not and includes an indicator of whether the optimization was successful. * Changes were made to features and bridging_basic so that additional flags may be set on a bridge. This is necessary because the queue requires that its bridge only allows move-swap local channel optimizations into the bridge. (closes issue ASTERISK-21517) Reported by Matt Jordan (closes issue ASTERISK-21943) Reported by Matt Jordan Review: https://reviewboard.asterisk.org/r/2694 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397451 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	430bb3bfb3	Let Queue wrap up time influence member availability ... Queue members who happen to be in multiple queues at the same time may not have any wrap up time. This problem occurred due to a code change in Asterisk 11.3.0 that unified device state tracking of Queue members in multiple Queues (which fixed some other problems, but unfortunately caused this one). This patch fixes the behavior by having the is_member_available function check the queue's wrap up time and the time of the member's last call, such that for a particular queue, the member won't be considered available if their last call is within the wrap up time. (closes issue ASTERISK-22189) Reported by: Tony Lewis Tested by: Tony Lewis ........ Merged revisions 396948 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396949 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago