|Summary:||ASTERISK-15593: [regression] Realtime agents Device state always Not in use|
|Reporter:||Sebastian Gutierrez (sum)||Labels:|
|Date Opened:||2010-02-08 19:16:40.000-0600||Date Closed:||2011-06-07 14:00:41|
|Description:||I have SIP realtime agents that are always in use, this dind't happend on previous SVN and RC versions|
|Comments:||By: Sebastian Gutierrez (sum) 2010-02-08 19:24:47.000-0600|
1 SIP member of a realtime queue
for example was working on Asterisk SVN-branch-1.6.2-r212631M
queue show, shows always not in use, when should be in use
any other info needed?
By: Leif Madsen (lmadsen) 2010-02-09 08:49:20.000-0600
Please provide the information required to reproduce this issue, including the queues.conf, sip.conf, and extensions.conf files (relevant parts).
It may also be useful to see the console output with debugging enabled; please provide the output for a working version (and specify which version worked, and which one doesn't) and a non-working version.
You may be able to look at the SVN log to determine where this may have gotten broken as well. Take the last working version, then you can look through the logs and step forward in revisions from subversion to test specific revisions.
If you can track down the exact commit that causes this issue, then it is likely to get fixed a lot faster.
By: Sebastian Gutierrez (sum) 2010-02-09 15:08:47.000-0600
queues, sip are realtime (sip with rtcache), extensions is just entering a queue.
184.108.40.206 seems to work
I'll try to get more detailed info as soon as I can
By: Sebastian Gutierrez (sum) 2010-02-09 17:08:55.000-0600
Here are my findings struggling with versions...
220.127.116.11 is the one that is not working the sip device state on queue show
18.104.22.168 is working fine
22.214.171.124 seems to work the device state with iax channel
the difference I found between the sip channel versions was a fix for T38, do you think this could be the cause that fix this? do you recomend to rebuild with chan_sip.c from 126.96.36.199 on the 188.8.131.52 (is in production 24x7) for a possible fix?
By: Sebastian Gutierrez (sum) 2010-02-09 21:42:19.000-0600
I think I got the reason, but I want to confirm.
call-limit null on the sip table and the device state is not updated, I change it to 1 and I have working the device states again, any comment?
By: Leif Madsen (lmadsen) 2010-02-22 15:37:25.000-0600
Hmmm, that seems strange. I'd think that shouldn't really be the case, so I'm setting this to Acknowledged.
By: Mark Michelson (mmichelson) 2010-02-26 11:18:33.000-0600
sum: Let me see if I understand this correctly. Are you saying that your table was configured incorrectly and so the value of call-limit was null? Or did Asterisk cause the call-limit value to be null in the table?
By: Sebastian Gutierrez (sum) 2010-02-26 12:28:01.000-0600
my table had the null value, when I change the value to other than null everything works ok, but if the value is null the device state is unchanged.
By: Mark Michelson (mmichelson) 2010-03-01 09:51:41.000-0600
sum: Sorry, I phrased my question badly. What I want to know is where the null value came from. I'm trying to figure out if the null value was due to a misconfiguration on your part or if Asterisk was responsible for placing the null value in the table when you upgraded. Your comments so far have been unclear as to the source of the null value.
By: Sebastian Gutierrez (sum) 2010-03-01 09:58:35.000-0600
I misconfigured the table, I forgot to put a value for call-limit. anyway I think this shouldnt be the asterisk default beheavior if this field is null.
By: Mark Michelson (mmichelson) 2010-03-03 11:21:20.000-0600
This is not a bug in Asterisk. SIP bases its device state on the call-limit (or countcalls) setting in sip.conf or in realtime. A misconfigured table will result in the behavior you saw.