asterisk

Commit Graph

Author	SHA1	Message	Date
Richard Mudgett	4e750a26fd	Added ConfBridge AMI event note to UPGRADE.txt. ........ Merged revisions 422255 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 422256 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422257 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	f3a525e9a6	ARI: Fix implicit answer when playback is initiated on unanswered channel When issuing a POST /channels/{channel_id}/play on a channel that is not yet answered, ARI is supposed to: * Queue up an AST_CONTROL_PROGRESS on the channel * Start up the playback of the media Instead, we sneak an answer on the channel right before starting playing media. This is due to ARI's usage of control_streamfile. This function implicitly answers the channel (and doesn't give ARI the option to stop it). The answering of the channel here is probably unnecessary: * app_voicemail, by far the biggest consumer of this function, always answers the channels anyway * control stream file (in res_agi) and ControlPlayback probably shouldn't be implicitly answering the channel. Answering should not be tied directly to playing back media. As it turns out, the answering of the channel here is pretty old: 356042 twilson if (ast_channel_state(chan) != AST_STATE_UP) { 3087 anthm res = ast_answer(chan); 180259 tilghman } (As in, ancient?) Note that others ran into this problem and commented about it on various mailing lists. Review: https://reviewboard.asterisk.org/r/3907/ ASTERISK-24229 #close Reported by: Matt Jordan ........ Merged revisions 421695 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 421696 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421699 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	add46fd27c	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) ........ Merged revisions 420624 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420625 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	455243cdd4	Update UPGRADE-13.txt file git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420608 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	5760526f69	Update UPGRADE.txt for 13 branch git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420497 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago

5 Commits (d013ecf7486ad4a04d8ccb52340c5e62bb44b6f6)