[asterisk-users] Fully utilise all PRIs in a DAHDI group

[Steve Totaro]

On Wed, Oct 17, 2012 at 8:43 AM, Raj Mathur (राज माथुर) <
raju at linux-delhi.org> wrote:

> Hi,
>
> Our client has DAHDI groups with 4 PRIs in each group (one 4-port
> interface per group), up to 6 groups per server.  When we dial, we can
> specify the group to be used for dialling, and our dial plan
> automatically distributes calls over multiple servers and multiple
> groups within a server.
>
> The way Asterisk dials by default is to use the lowest-numbered free
> line in a group to place a call.  This is technically fine.  However,
> what it means for our client is that the first couple of PRIs in a group
> tend to get the bulk of calls, the other two remain more-or-less
> unutilised.  This is a problem, since there are call commitments to the
> Telco for each PRI line.  The Telco tends to get all soggy and hard to
> light if some of the PRIs are used way below committed call levels.
>
> One solution is to group at the individual PRI level, so the load
> balancing automatically takes care of fair utilisation of each PRI.
> However, for various reasons we'd prefer not to do this.
>
> Another solution would be if Asterisk could choose a random (or LRU or
> LCU or round-robin or any other scheme) PRI within a group when
> dialling.  Any roughly fair way to distribute calls to PRIs within a
> DAHDI group would be fine.  Is there some way to achieve this?
>
> Asterisk 1.8.8 on Debian Squeeze.
>
> Regards,
>
> -- Raj
> --
> Raj Mathur                          || raju at kandalaya.org   || GPG:
> http://otheronepercent.blogspot.com || http://kandalaya.org || CC68
> It is the mind that moves           || http://schizoid.in   || D17F
>

Taken from the wiki searching with the exact terms you used.
http://www.voip-info.org/wiki/view/Asterisk+ZAP+channels

Thanks,
Steve Totaro
Dialing a GroupIn the Zap Channel Module's configuration file
(zapata.conf<http://www.voip-info.org/wiki/view/Asterisk+config+zapata.conf>),
you can define groups of Zap channels that get treated as a single channel
as far as the Dial
<http://www.voip-info.org/wiki/view/Asterisk+cmd+Dial>command
is concerned. You specify which of four methods the Zap channel module is
to use to select a non-busy channel from the channel group by prefixing the
group number with one of the letters *g*, *G*, *r*, or *R*:


   - *g*: select the lowest-numbered non-busy Zap channel (aka. ascending
   sequential hunt group).
   - *G*: select the highest-numbered non-busy Zap channel (aka. descending
   sequential hunt group).
   - *r*: use a round-robin search, starting at the next highest channel
   than last time (aka. ascending rotary hunt group).
   - *R*: use a round-robin search, starting at the next lowest channel
   than last time (aka. descending rotary hunt group).


The round-robin searches make the Zap channel module start looking for an
available channel from a different channel number each time. For each
channel group, the Zap channel module keeps track of the last round-robin
start point, and this time starts checking availability from either the
next (lowercase *r*)) or the previous uppercase *R* channel in the group.
Which channel it actually finds available (if any) does not affect the
starting point for the next round-robin search. Calls to the
Dial<http://www.voip-info.org/wiki/view/Asterisk+cmd+Dial> command
using ordinary (*g* or *G*) group selections do not affect future
round-robin starting points either.

For example, if you have defined channel group 2 as containing Zap channels
1, 2, 5 and 8, and the last round-robin search for this group (group 2)
began searching from channel 5, this is the order of searching that the Zap
channel module will use for the four possible selection methods:


   - Dial(Zap/g2...): Looks in order 1, 2, 5, 8
   - Dial(Zap/G2...): Looks in order 8, 5, 2, 1
   - Dial(Zap/r2...): Looks in order 8, 1, 2, 5
   - Dial(Zap/R2...): Looks in order 2, 1, 8, 5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20121017/0899f4f1/attachment.htm>