Summary:ASTERISK-13967: limitonpeers=yes vs call-limit=1 didn't work on asterisk 1.4.24
Reporter:sybasesql (sybasesql)Labels:
Date Opened:2009-04-16 12:57:30Date Closed:2011-06-07 14:03:20
Versions:Frequency of

In asterisk 1.4.24 limitonpeers=yes vs call-limit=1 didn't work.

My setup:
callerid="xxxxxxxxxxx" <xxxxxxxxxxx>

[Apr 16 21:33:21] ERROR[23739] chan_sip.c: Call from peer 'xxxxxxxxxxx' rejected due to usage limit of 1
[Apr 16 21:33:21] NOTICE[23739] chan_sip.c: Failed to place call for user xxxxxxxxxxx, too many calls

User xxxxxxxxxxx accept inbound call and immediate make outbound call (redirect inbound) through his peer xxxxxxxxxxx, but got error "rejected due to usage limit of 1".
Comments:By: Leif Madsen (lmadsen) 2009-04-16 16:37:27

Can you show the SIP debug along with this error, plus the whole console output as well? Please attach as separate files to this issue. Thanks

By: Leif Madsen (lmadsen) 2009-04-16 16:43:49

Based on a conversation I had with file on IRC, this appears to be working exactly as it should per your configuration. The incoming call is most likely matching on the IP address ('peer' structure), and not the 'user' structure (which would be user based matching), and thus when you try to dial out, it already has a channel usage of '1'.

By: sybasesql (sybasesql) 2009-04-16 17:13:08

Limitonpeers changes the way we handle incoming calls for type=friend objects.
For type=friend, we do have two different call limits, one for incoming calls (on user) and one for outbound calls (on peer). SIP subscriptions and device states only check peers.
So if you have type=friend and set call-limit to 1, the SIP device is allowed 2 calls - one inbound and one outbound.

With limitonpeers, all call counters only use the peer side and ignore the user. This means that SIP subscriptions will notify that the CALLING device is busy or inuse, instead of only the CALLED device.

By: Joshua C. Colp (jcolp) 2009-04-27 09:24:27

I've confirmed exactly what you say here, but I don't know if there is a solution we can come to for this besides not using call-limit like this. You want individual limits on both the incoming and outgoing sides, not using limitonpeers has the side effect of splitting them apart but provides poor device state. The only suggestion I have right now is to use group counting to limit things.

By: sybasesql (sybasesql) 2009-04-29 19:52:49

But it works perfect on asterisk <= 1.4.22.
Using GROUP_COUNT in my configuration (10000+ DIDs) very expensive for memory and cpu use unlike call-limit + limitonpeers.

By: Joshua C. Colp (jcolp) 2009-05-12 10:55:53

I've gone back to 1.4.22, 1.4.20, and 1.4.18. They all behave as the current version does - they all reject the call as expected. Like I said, I don't think we are going to be able to come to a solution for 1.4. You can't have it be combined and separated...

By: Joshua C. Colp (jcolp) 2009-05-12 11:02:43

It would be useful to actually go back to an earlier version and get the console output, sip traces, everything. That way we can actually determine if there is a regression.

By: Joshua C. Colp (jcolp) 2009-06-01 08:40:58

I'm suspending this issue due to lack of feedback. Based on my testing I've found no regression here. If it is then please feel free to reopen.