Lack of call-limit for extensions causes hint problems

After mucking around with this for ages … I have found that without manually editing the sip_additional file and adding a call-limit to each extension, extensions involved in transfers etc will eventually have their hint stay on hold forever.

An Asterisk restart fixes it for a while, but it comes back.

Can someone please include the call-limit feature in the device/user area ?
anyone have any ideas here, or has this been thought of already ?

I thin k there is a bug open on this but it included several other things as well. Why don’t you open a bug explicitly for this issue - and explain in detail what the problem is and why this is needed. Also - you mention it works for a while after a restart and then eventually always looks like on hold. Can you elaborate on that - in the bug report if appropriate. What you describe sounds like an Asterisk bug that call-limits would only temporarily keep back until enough calls happen - but I"m probably mis-understanding what you are saying.

Hi,
I can confirm this problem, I’ve just spent two days trying to get a customers setup working correctly again after upgrading from asterisk 1.2.x to 1.4.7.1

The problem appeared there as phones appearing busy after calls had been answered and transferred on - they would then not accept further calls until asterisk had been restarted.
(The phones are Polycom 501s & 601s).

Setting call-limit in each extension appears to fix the problem.

As far as I can understand from other comments I found online, asterisk 1.2 had a default finite limit, where 1.4 defaults to zero, with zero being unlimited… I think this ‘no limit’ situation prevents asterisk tracking the number of available calls/lines whatever and it gets screwed up.

Any sensible limit value (I’ve been using 4) allows it to stay in sync.

Even if ‘call-limit’ was added to the SIP extensions configuration in FreePBX with a default of zero, it would at least allow a figure to be set if needed in a particular installation.

A related problem is that sip_additional.conf does not allow for including custom lines or sections in the extension configs - this again would allow ‘fixes’ like this to done manually, pending a final solution.

so if you set the call-limit to 4, can you then receive call after call on an extension, and each time transfer that call somewhere else, and it continues to be ok? From what was previously described, it sounded like a potential ‘stop gap’ that would eventually have the same ‘failure mode’ behavior after enough calls. Thanks for the info - I have yet to really look closely at these differences and new requirements of 1.4 and am counting on the beta testers like you to help iron out the wrinkles like this one. (And please add relevant data to the bug - because that is what we’ll revisit to figure out how to best set this up for Asterisk 1.4.

Hi,
I’ve not found a formal bug report for this, I don’t know if one exists?

I did find a patch which adds call-limit in the extension setup:
http://www.freepbx.org/trac/ticket/1964

By following the link in this to the .diff and getting the raw file I’ve patched my test system and now have the call-limit parameter available.

there’s a somewhat ‘generic’ bug against 1.4 that includes this. If you want, just open a new bug just against this issue, and reference the patch below. Then what we really need to know is how such a setting effect Asterisk 1.2 - since for FreePBX 2.3 we are trying to keep a single consistent dialplan across 1.2 and 1.4 if possible.

OK, bug posted:
http://www.freepbx.org/trac/ticket/2127

The patch was for use with Asterisk 1.2 anyway, so I can’t see any problem in that respect.

As far as I’ve been able to figure out, call-limit is the maximum number of calls that can be associated with an extension in real time. I saw a message that setting it down to 1 prevents attended transfers, as that requires two simultaneous calls, even though one is on hold.

The advised values seem to be 4 or 10.

thanks for the reply. For all who are following - I’d still very muck like to see it tested on 1.2. The fact that someone put a patch up that was aimed at 1.2 doesn’t mean anything. People put up patches often for their own very specific needs not realizing the implications such patches may have to a more general public.

Changelog in 1.4.9 shows this issue as being addressed. So hopefully this will mean that we don’t necessarily have to worry about it.

Will test and let everyone know.

brettm,
please do report back and let us know if you do not require the call-limit to get hints working, or if there is a more general sip.conf setting. I would like to avoid putting the call-limits in if possible and I still haven’t seen anyone report back if there are issues if we do put it in with 1.2.

I have just noticed the same problem and upgraded to asterisk 1.4.9 with no change.

The phones still report status 16 and wont take a call after a transfer. These phones are Aastra 57i.

I manually added a call limit of 4 to a phone, restarted * and checked it had applied it and then tested again. The problem still exists but only when performing a blind transfer. I’m thinking this is more an asterisk issue than freepbx, and as bugs go, it’s a big one!

dirk - take a look at the full asterisk requirements I think there were some other settings in the sip general context that were required to make it work. It is a show stopper bug that needs to be addressed, I’m still waiting to hear back from some people who would be willing to test it on 1.2 (haven’t seen anyone step up yet) so we know if it causes 1.2 issues.

Then of course we need to get the full set of settings correct to have it done properly.

I’m sure I have a few VM’s that have 1.2 on them, from previous testing. If I find settings that make it work in 1.4 I’ll try them in 1.2 and see if anything breaks, but there’s no sense in trying them in 1.2 until I make it work in 1.4

Hi Dirk,

my present sip.conf has this section in it:

[code:1];Reported as required for Asterisk 1.4
notifyringing=yes
notifyhold=yes
limitonpeers=yes
jbenable = yes
jbforce=yes
[/code:1]

I think it’s the ‘notify’ flags that affect the phone status issue.
I have seen a comment that the jb (jitterbuffer) flags are not a good idea in all systems, but they don’t seem to have any adverse affect on the two machines that have these settings.

Well I reloaded etc etc after upgrade to 1.4.9 and it’s still busted.

The other thing that I forgot about which I discovered a while ago was the fact that not only do the hints stay on hold without the individual peer call-limit but the CLI show no updating of hint subcriptions on other extensions when calls are made also.

Put them back in and I’m back to the old copying a sip_additional file with the peer call-limit entries in it over the one that FreePBX creates.

The sip.conf entries above work fine. I’ve been live in an office running * 1.4.6 through to 1.4.9 now over thw last couple of weeks and it’s all good. Misdn on Centos 5 with Snom 320’s. Haven’t had a hiccup yet and have had good feedback from users who are still getting used to the idea about a free call to another office.

I’ll reopen the bug with Digium I think.

Well I reloaded etc etc after upgrade to 1.4.9 and it’s still busted.

The other thing that I forgot about which I discovered a while ago was the fact that not only do the hints stay on hold without the individual peer call-limit but the CLI show no updating of hint subcriptions on other extensions when calls are made also.

Put them back in and I’m back to the old copying a sip_additional file with the peer call-limit entries in it over the one that FreePBX creates.

The sip.conf entries above work fine. I’ve been live in an office running * 1.4.6 through to 1.4.9 now over thw last couple of weeks and it’s all good. Misdn on Centos 5 with Snom 320’s. Haven’t had a hiccup yet and have had good feedback from users who are still getting used to the idea about a free call to another office.

I’ll reopen the bug with Digium I think.

My sip.conf shows the same fields as rjenkinsgb.
I was hoping to see something different that may help. I’m starting to get a little stressed over this now.

Right, I’ve attacked it again and added the ‘call-limit=4’ line to the first three xtn’s on the system and tested and tested.

This is with asterisk 1.4.9 installed and the call-limit added and asterisk restarted.

I found that I can transfer calls with *2 and ## without problems locking the phones in busy.

Extensionstate 16 still happens with I use the transfer button on the phone itself though. The advantage of this is that it will perform both a blind and unattended transfer rather than deciding which one you want before pressing the button.

The even sequence is:
[list]101 phones 102
102 answers and transfers to 103.
103 answers
all phones hang up
any phone calls 102 and it shows as busy[/list:u]

Looks like it may be an Aastra thing?

I’ve just updated to the latest FreePBX modules, 2.3.0 RC1 and asterisk 1.4.10

I had a look at sip_additional.conf to see how call-limit had been implemented and found that some extensions had two call-limit lines, the first either having no value or 4, the second having value 50.

I had previously used the patch file from http://www.freepbx.org/trac/ticket/1964
as mentioned earlier in this thread.

It seems the patch added entries in the sip database table which are still being processed during a configuration update, though the new call-limit=50 does not appear to use the database.

I searched the database using phpmyadmin and found a few stray entries for call-limit (in the keyword column of the sip table) and removed these records. The sip_additional.conf file now looks OK, with only one instance of call-limit per extension or trunk.

call-limits are auto inserted at ‘reload time’ (when you press the reload bar) when it detects you are running 1.4, it does not use the database for this. This allows for painless transition back and forth between 1.2 and 1.4. So as you observed, if you have used some patch or other means previously you will need to remove them all. The following SQL statement would do the trick:

[code:1]DELETE FROM sip WHERE keyword = ‘call-limit’[/code:1]