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
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
Richard Mudgett
Matthew Jordan