[Home]

Summary:ASTERISK-12046: Queue timeout not overided by the timeout parameter on the Queue command
Reporter:daren ferreira (daren)Labels:
Date Opened:2008-05-19 07:33:10Date Closed:2008-05-27 14:23:37
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Hello,

I didn't find such issue, neither in mantis, neither in changelog, so i hope i don't create a duplicate request.

I'm actually using an asterisk 1.4.19.1 on the one i found a very little bug. In fact the timeout option of the "Queue" command doesn't override the value set in the config file...

Example:

In one of my scenari, the timeout parameter in
"exten => s,5,Queue(service-clients|n||sc/sc-scstellatelecom|180)" is ignored, the timeout value used is the one found in the queues.conf

Here are the extract of the config files.

; queues.conf extract
[service-clients]

musiconhold = default
strategy = ringall

member => SIP/mt1
member => SIP/mt4
member => SIP/mt5

timeout = 180
retry = 5

;extensions.conf extract

[sc_menu_principal]
exten => s,1,GotoIfTime(20:01-7:59|mon-sat|*?sc_ferme_rappel,s,1)
exten => s,2,NoOp()
exten => s,3,GotoIfTime(*|sun|*?sc_ferme_rappel,s,1)
exten => s,4,PlayBack(sc/veuillezpatienter)
exten => s,5,Queue(service-clients|n||sc/sc-scstellatelecom|180)
exten => s,6,Queue(bureau|n||sc/sc-scstellatelecom|90)
exten => s,7,PlayBack(sc/aucundispo)
exten => s,8,BackGround(sc/rappel)
exten => s,9,WaitExten()
exten => 1,1,Macro(id-mail,Service commercial particuliers)
exten => 2,1,PlayBack(sc/aurevoir)
exten => 2,2,Hangup()


Thanks a lot!

Daren
Comments:By: David Woolley (davidw) 2008-05-19 08:18:02

These two timeouts are different.  The queues.conf one is how long to ring queue members' phones.  The app_queue one is how long before the user is dropped from the queue.  I suspect the app_queue one is suspended when the phones are actively being called.

By: Joshua C. Colp (jcolp) 2008-05-19 09:45:07

davidw is indeed correct, these timeouts serve two different purposes. It is doing the correct thing and not overriding the configuration file one.

By: daren ferreira (daren) 2008-05-20 02:45:09

Oups, it's true, i knew the difference, i made a mistake in the understanding of my problem.

If, now, i'm right, the normal "global" timeout is queues.conf timeout by the retry ( global_timeout = conf_timeout*conf_retry if cmd_timeout>=global_timeout else global_timeout=cmd_timeout ).

But davidw seems to be right, the first queue was heavily used when it was leaved. So it might be related to that, but are you ok to tell that it's not normal; that the queue shouldn't be left before its end?

Do you have an idea on how to force asterisk to use the queue until the cmd_timeout or until the end of the conf_timeout*conf_retry ?

What do you think of adding a special queue member with a infinite wait/ring through a LOCAL extension?

I'll try, who knows...

By: Mark Michelson (mmichelson) 2008-05-21 14:16:10

I'm sorry but I cannot tell what the problem you are having is. Your last note is not making a lot of sense to me. Part of it is because you are using terms like "global_timeout," "conf_timeout," "conf_retry," and "cmd_timeout." I don't know what you mean by these terms.

Also in your initial post, you mentioned that the timeout specified in queues.conf was used instead of the one in the dialplan. Both are set to the same value, though, so I don't know how you could tell a difference.

By: daren ferreira (daren) 2008-05-21 16:24:35

In fact i made a mistake when copying queues.conf. The original settings causing problem were :

; queues.conf extract
[service-clients]

musiconhold = default
strategy = ringall

member => SIP/mt1
member => SIP/mt4
member => SIP/mt5

timeout = 15
retry = 5

So, normally, queue must not be left before 15*5 seconds = 75 seconds or before the time specified in the Queue command, must it?

My problem is most of time the queue is left after less than 30 seconds... no matter the timeouts are set.

I didn't got that problem on previous versions.

"conf_timeout" was a mean to tell "timeout set in queues.conf config file"
"conf_retry" was a mean to tell "reply set in queues.conf config file"
"cmd_timeout" was a mean to tell "timeout set in the queue command"

"global_timeout" was a mean to tell "time the queue is executed before beeing left for fallthrough"

By: David Woolley (davidw) 2008-05-22 07:52:21

retry is a time, not a pure number.

With the parameters you have, the phones are rung for 15 seconds, then there is a pause for 5 seconds before they are rung again for 15 seconds.  This is done indefinitely, unless you limit the time in the queue in the Queue application parameters.

By: daren ferreira (daren) 2008-05-22 10:42:01

Oh, really !

So why do my queue is left for fallthrough after less than 20 seconds; even if i didn't specify any timeout or if i specify a long timeout (as in the example) on the Queue command... You're pointing my problem...

By: David Woolley (davidw) 2008-05-22 12:32:08

That's because the n option is set.  n will stop it after ringing after a limited number of tries.  If I read it correctly, that is after each member has been tried once.

By: daren ferreira (daren) 2008-05-22 14:51:13

Until now i thought that the n option was related to the Queue command timeout not the config file option... because until my last update it seemed to do so...

Anyway i'll remove this option and will keep you inform.

By: daren ferreira (daren) 2008-05-27 03:57:30

I've made the changes (removed the n option) and my problem has gone.
So that was not a bug but a misunderstandment of the n option.

Thanks a lot for your help!

By: Mark Michelson (mmichelson) 2008-05-27 14:23:36

Thanks, davidw, for your help on this. I'm going to close this now since the confusion seems to have been cleared up now.