Ticket #2127 (closed Bugs: fixed)

Opened 1 year ago

Last modified 6 months ago

call-limit parameter needed for Asterisk 1.4 compatibility

Reported by: rjenkinsgb Assigned to: p_lindheimer
Priority: major Milestone: 2.3
Component: Core Version: 2.3-branch
Keywords: call-limit sip busy hold Cc:
Confirmation: Need testing SVN Revision (if applicable): (2.3.0 beta 1)
Backend Engine: Asterisk 1.4.x Backend Engine Version: 1.2.x / 1.4.x

Description

Asterisk 1.4.x requires a call-limit value in each SIP extension definition for it to properly track the status of extensions.

Without this, after the extension has been used & done transfers etc., asterisk eventually shows the extension status as 'hold' when it is not in use and the extension can no longer receive calls. This is visible from the CLI with 'core show hints' and SIP phones with line status indicators show the extension(s) affected as busy. The first to fail are of course the operators/receptionists, then the site can no longer handle incoming calls..

The call-limit value appears to be the number of calls that can be simultaneously associated with an extension; I've seen a note that setting it down to 1 blocks attended transfers. Advised values I've seen are 4 or 10. Asterisk 1.4 appears to default to zero (= unlimited) which is when the problems start.

There is already a patch to add the call-limit parameter to the SIP extensions page here: http://www.freepbx.org/trac/ticket/1964

This seems to work fine with the present 2.3.0Beta1 release, and the patch notes say it was written for use with asterisk 1.2.x so there should hopefully not be any back-compatibility issues.

Note: While searching for the cause of this I saw mention of modifying freepbx's dialplan.agi to allow an extension status of 16. This is not required & does not change the fact that asterisk shows the extension state as 'hold' rather than 'idle'. With call-limit = 4 the status 16 never seems to occur.

Change History

07/26/07 08:27:51 changed by p_lindheimer

  • priority changed from blocker to major.
  • version changed from SVN-HEAD to 2.3-branch.

07/26/07 09:38:25 changed by p_lindheimer

  • component changed from Core - Users/Devices to Core.

07/26/07 09:42:52 changed by p_lindheimer

#1884 for additional history

07/27/07 00:55:04 changed by julianjm

These are unrelated problems.

1) Having call-limit=0 will cause asterisk to not show InUse? states for that peer. But the Hold state will be set in any case... I think this is a bad feature (bug), because it forces you to set a high call-limit to have those states set.

2) On the other hand, the status=16 issue (Hold) is an asterisk bug. After doing a native SIP transfer, the internal variable that stores the Hold state for a peer is decremented twice (-1), thus always returning _true_. I've submited a fix: http://bugs.digium.com/view.php?id=10323 . It works for me, but it will require more testing...

Julian J. M.

07/30/07 16:20:04 changed by robert

The second part (the Asterisk bug) is now fixed in the Asterisk 1.4 branch and should be in the next release 1.4.10.

08/01/07 00:03:38 changed by kenn10

If the "busy-limit" parameter per station being addressed as well? I don't see this mentioned. I've had to add this in sip_additional.conf for each SIP station to make the BLF work correctly. The busy-limit seems to be necessary for the light to come on with just one call.

call-limit=2 busy-limit=1

08/01/07 02:32:59 changed by p_lindheimer

would some of you other guys confirm what is needed on the busy-limit as well. If what kenn10 is saying is true, we will want this set to busy-limit=1 because we want a status of busy to be returned for any phone that has 1 or more active call as there is other functionality that depends on this condition.

We also need to know how both of these parameters effect Asterisk 1.2. At this point, this lack of anyone doing such testing on 1.2 is what is keeping us from adding this into the code.

08/01/07 19:00:53 changed by robert

I researched this issue in the asterisk source code for 1.2, 1.4 and the trunk.

First, call-limit is implemented in 1.2 and 1.4. There shouldn't be any issues with it in 1.2. The issue in 1.4 should be resolved in 1.4.10.

There is no busy-limit, it is actually busy-level. (The initial code called it busy-limit but never actually read the value from sip.conf).

Busy-level is only supported on the trunk not in the 1.2 or 1.4 branches.

So I think it is safe to add call-limit to the SIP Device Options.

The busy-level functionality is going to have to wait until 1.6 or until it is backported to a future 1.4 release.

08/02/07 09:05:43 changed by p_lindheimer

robert: thanks. What is the implication of no busy-limit? Will the hints show busy on 1.4 when a call is active once you've set call-limit to something like 10? Or does call-limit end up changing the hint to not indicate busy (which would be a real problem)?

08/02/07 09:39:37 changed by p_lindheimer

I did some very quick testing on 1.2 (in this case 1.2.10) here is what I found:

  • call-limit once set does not change after a reload, it requires asterisk to be restarted
  • as indicated there is no busy-level or busy-limit
  • when call-limit is set, it breaks the hints by returning an Idle state for the extension. There is no apparent way to stop this
    • Call Waiting will be broken by this
    • All the prim mode ring strategies will be broken by this
    • CFB will be broken by this (I think)
    • Intercom(once fixed) and Paging will be broken by this (unable to detect if we should not page an extension that is in use)
    • probably other stuff I am not thinking of

This is all on 1.2 testing. We can have FreePBX NOT set call-limit on 1.2. However, I suspect that all of the above is the same on 1.4. I NEED someone to test this for us and confirm or deny the observed behavior that I described for 1.2.

Testing is easy:

  • Go into sip_additional.conf and add call-limit = 10 to an extension
  • do a sip reload at the CLI
  • confirm it is set by doing a sip show peers and sip show users and check that the call-limit is set to 10
  • now make a call to another phone, or echo test (*43) and while on the call do a show hints and check the status of the extension being tested. It should show:
    • State:Idle when it is free,
    • State:InUse when it is busy,

If the same issue happens on 1.4, then it is a serious design/change flaw in Asterisk not only for FreePBX but anyone who depends on being able to check the status of hints for intelligent dialplan applications while still depending on the hints for BLF functionality. So it's going to take some discussions with the Asterisk development community to fix this. (It sounds like busy-limit would fix it - and would be a perfectly acceptable solution but from what is being said, it is not necessarily planned for a 1.4 release).

08/02/07 10:07:11 changed by robert

In 1.4:

no call-state
device state remains idle
call-state = n
device state changes to InUse? when on a call and becomes Busy when on "n" calls.

08/02/07 10:12:18 changed by robert

Doh,

call-state should be call-limit in my previous post.

(follow-up: ↓ 21 ) 08/02/07 11:06:39 changed by robert

I took a look at the current code for 1.2 (1.2.23) and as far as I can tell from looking at it, the behaviour should be the same on current versions of both 1.2 and 1.4.

InUse? and Busy are only reported when call-limit is not equal to 0.

In going over the change logs, this was changed in revision 6722. This was to fix issue #5103. Here is a comment from the routine that reports the device state.

If we have qualify on and the device is not reachable, regardless of registration state we return AST_DEVICE_UNAVAILABLE

For peers with call limit:

not registered
AST_DEVICE_UNAVAILABLE
registered, no call
AST_DEVICE_NOT_INUSE
registered, calls possible
AST_DEVICE_INUSE
registered, call limit reached
AST_DEVICE_BUSY

For peers without call limit:

not registered
AST_DEVICE_UNAVAILABLE
registered
AST_DEVICE_UNKNOWN

However, that revision was long before version 1.2.10. So I can't explain what you saw during your tests.

Perhaps some "sip debug" output would help explain things?

08/02/07 12:58:46 changed by p_lindheimer

So if I understand your description, when you run the same test that I did above you get the opposite results. Without call-limit set on 1.4, it is effectively always idle. When you set call-limit to something high (that you would never reach) then it is inUse as soon as there is one or more calls (and I guess busy if you ever get to the full limit)? Is that the case?

And - if that is the case, then we need to not set call-limit on 1.2 and set it on 1.4...

08/02/07 13:31:31 changed by p_lindheimer

  • owner set to p_lindheimer.

08/02/07 13:32:09 changed by p_lindheimer

  • status changed from new to assigned.

08/02/07 17:14:58 changed by p_lindheimer

  • confirmation set to Need Feedback.

r4661

PLEASE TEST

If this is important to you, please pull retrieve_conf and libfreepbx.confgen.php from svn (~amp_conf/bin) and put them in you AMPBIN directory, /var/lib/asterisk/bin, (after backing up the old retrieve_conf) and then test for us please.

Because of the differing requirement between Asterisk 1.2 (call-limit breaks FreePBX) and Asterisk 1.4 (call-limit is required) we have put a fix in that will automatically insert call-limit=50 in all extensions if you are running Asterisk 1.4. In the process we have gotten rid of all the legacy retrieve_zap/sip/iax/queues_from_mysql.pl scripts so we can really use some testing with people with all of these various setups (1.2 and 1.4). There is no big risk - you can swap back the old retrieve_conf script and regenerate the conf files properly if there are any bugs. Further - if you have some good setups with a lot of these files, save the old sip_additional.conf, zapata_additional.conf, iax_additional.conf and queues_addtional.conf files off, run it and then diff the files and if there are issues (other than spaces or the header - let us know.

thanks!

08/02/07 19:24:32 changed by vgster

call-limit=50 is generated after following the above procedure and the _additional.conf files appear to be generating properly. I will do more testing.

08/04/07 05:22:06 changed by p_lindheimer

  • confirmation changed from Need Feedback to Need testing.

08/04/07 06:25:22 changed by p_lindheimer

  • status changed from assigned to closed.
  • resolution set to fixed.

fixed in Framework: 2.3.0beta2.9

(in reply to: ↑ 13 ; follow-up: ↓ 22 ) 05/25/08 06:52:37 changed by dereckrahhal

well thanks to this post i was able to handle the queue and agents issues.. i was about to lose my job because of it.. anyway i followed everything in your posts and the only thing that worked with me was setting the call-limit=1 and adding the busy-limit=1 and it worked !!! the queue skipped the busy users .. i don't know other problems that may arrise from doing that though.. i tried putting call-limit=10 or even leave it to 50 but the queue didn't skip the busy agents.. now it does.. hope you test it and let me know if anyone have faced any problems

(in reply to: ↑ 21 ) 05/25/08 08:11:13 changed by p_lindheimer

Replying to dereckrahhal:

well thanks to this post i was able to handle the queue and agents issues.. i was about to lose my job because of it.. anyway i followed everything in your posts and the only thing that worked with me was setting the call-limit=1 and adding the busy-limit=1 and it worked !!! the queue skipped the busy users .. i don't know other problems that may arrise from doing that though.. i tried putting call-limit=10 or even leave it to 50 but the queue didn't skip the busy agents.. now it does.. hope you test it and let me know if anyone have faced any problems

Dereck, if using 2.3, you can simply disable CW on those agents which will have the same effect. A better solution is to move to 2.4 and then choose "Skip Busy Agent" for the specific queue, you will have the same effect but still keep the ability to have CW/multiple line appearances on your agent's phones.

06/09/08 16:38:52 changed by kim@flintriver.com

I am using FreePBX 2.4 and have CW disabled and Skip Busy Agent = YES, but the busy agent's phone will ring even though they are on the phone. (I'm using X-Lite softphone.) The only way to prevent the agent's phone from ringing while they are on the phone that I've found so far is to set call-limit=1 and do a "sip reload." However, this is not a good solution since "Apply Configuration Changes" in FreePBX will set call-limit back to 50. I can't tell that "Skip Busy Agent = YES" has any affect and does not appear in any conf file that I can find. I'm a newbie to */FreePBX, but it seems like it should be a simple thing not to ring a busy agent. Any suggestions? Thanks.

06/10/08 05:32:58 changed by p_lindheimer

if you have CW disabled (in FreePBX) and you are getting multiple call attempts to your phone then you have other configuration issues or you are using something like agent.conf type agents. FreePBX will not attempt to make a call to a device that is busy with another call based on the state of the asterisk 'hints.'

Donate



Support
Download
Develop
Forums
News
Documentation
Paid Support
About

Paid Ads