that is correct, it is set and then eventually tested:
exten => s,n,Set(GROUP()=OUT_${DIAL_TRUNK})
more stuff here
exten => s,n(checkmax),GotoIf($[ ${GROUP_COUNT()} > ${OUTMAXCHANS_${DIAL_TRUNK}} ]?chanfull)
the GROUP_COUNT() should default to the channels value that was set above if not explicitly specified (and how it has always been), unless something changed.
Philippe Lindheimer - FreePBX Project Lead
http//freepbx.org - IRC #freepbx
Asterisk has verified and provided a patch for their bug in 1.4
It is here: http://bugs.digium.com/view.php?id=11077
Philippe thank you for the help in identifying this is an Asterisk 1.4 bug.
I know it is a bit late but i can also confirm to this issue
in addition to this i can confirm that for IAX trunks max calls have never worked
i am testing out the patch, can you tell me if this patch is only for sip or also for iax?
I have pasted patch under the last entry in the extension.conf
is that the proper way?
[default]
include => ext-local
exten => s,1,Playback(vm-goodbye)
exten => s,2,Macro(hangupcall)
I am using asterisk 1.4.22 with Trixbox 2.6.2 and a Portech 372 dual sip to gsm gateway, each gsm channel is set up as a discrete SIP trunk which means only 1 call in or one call out can happen at any one time on each trunk.
On outbound calls max calls works fine when set to 1 which causes a second outbound call to use the second SIP trunk which has been denominated in Outbound Routes, however, although I have set the special context context=from-trunk-sip-trunkname, in the User Details of each trunk incoming calls do not appear to be counted.
When the first trunk is busy on an incoming call an attempt is still made to seize it (presumably because the max calls register has not been incremented) and the Portech Gateway correctly returns a 486 busy here message which results in a busy tone although the second trunk is available for outgoing calls.
I am wondering if I may have misunderstood the instructions in the max calls popup. Any guidance that can be given would be appreciated.
I have found a workaround, in the Portech it was possible to change the 486 Busy here message to 503 Service Unavailable which has cured the problem but if anyone has any ideas on the max call counting would like to hear them.
stonet,
making the change to 503 is the better solution. However, it would be interesting to understand what was not working with the contexts. My guess is that the configuration was such that the call was not hitting the proper context to count the inbound call. You can type:
group show channels
at the cli, and you should seel the group counts for each trunk. You can also see the calls coming in at the CLI to determine if they are flowing through that context.
asterisk 1.4.42
Used failover on BUSY instead of using maximum channels
create a new macro from [macro-dialout-trunk] and remove the below lines
exten => s-BUSY,1,Noop(Dial failed due to trunk reporting BUSY – giving up)
exten => s-BUSY,n,Playtones(busy)
exten => s-BUSY,n,Hangup(17)
as a result once you get a BUSY on the trunk it will be treated as CONGESTION and asterisk failover onto the next trunk.
This has to be used in the special scenario in which the trunk is dumb enough to send BUSY instead of CONGESTION otherwise the internal asterisk configuration will work out of the box.