[Asterisk-Users] How to make groups of extensions ???

[Andrew Kohlsmith]

On Tuesday 21 March 2006 22:19, C F wrote:
> What you said before about everything being *incoming* from asterisks
> point of view is true, however that just shows that we were saying the
> same thing, since for the context (not asterisk DP context) of this
> post we are looking at the point of view of the user device and NOT
> asterisk.

True enough.

> Therefore, consider the follwoing setup: 
> PSTN/ZAP <> Asterisk <> User Deivce.
> When User Device has an incoming call from PSTN/ZAP becuase asterisk
> uses app_dial to ring User Device, we got an incoming call, which the
> context of PSTN/ZAP will make sure that according to the arguments to
> app_dial User Device rings.

Yes, the Zap channel's context= line determines where in the dialplan the call 
gets placed, since Asterisk sees an incoming call from a Zap channel.

> When User Device makes an outgoing call from User Device to PSTN/ZAP
> then the context of User Device will decide thru the arguments of
> app_dial what channel on PSTN/ZAP is used.

Entirely correct.  Asterisk sees an incoming call from the User Device, so the 
context= line from the whichever type=friend or type=user entry matches best 
(or is it first?) is used to determine which part of the dialplan the user's 
call accesses, and it's the dialplan which (in the original poster's 
question) determines which of the trunk lines the user can place calls 
through.

> Using group settings in 
> PSTN/ZAP it just makes it easier to specify more than one channel for
> that call if the one with the highest priority in the group is
> busy/congested. But is NOT the group that makes it possible, since
> using the status varialbes from app_dial we can do the next channel on
> our own, and we don't realy need groups to make it work.

Fair enough.  I see a bit of Perl's TMTOWTDI here, but the most sane method of 
doing what the original poster wanted would be to place the Zap channels into 
appropriate groups, and then simply use Dial(Zap/g#) to place the call.  If 
all the trunk lines in the group are in use, the Dial will fail and your 
dialplan will get them to a Busy priority.  The best/first (I forget which) 
matching type=friend or type=user entry for the User Device has a context= 
line which specifies where in the dialplan they start out, which gets them to 
the appropriate Dial() priority.

To play devil's advocate for a moment, I too can make it work without separate 
contexts for each User Device.  :-)

I suppose the most correct and easiest to implement answer would be
- create a unique context= for each User Device or User Device Group
- assign unique group numbers for the required Zap trunks
- in the dialplan, have each UD or UDG [context] Dial() the appropriate group

The dialplan "pseudocode" using Faisal's original post would look something 
like this:

[SpecialPerson]
exten => _X.,1,Dial(Zap/1/${EXTEN},,g) ; they only have access to line 1
exten => _X.,n,Macro(handle-hangup)

[groupA]
exten => _X.,1,Dial(Zap/g2/${EXTEN},,g)
exten => _X.,n,Macro(handle-hangup)

[groupB]
exten => _X.,1,Dial(Zap/g3/${EXTEN},,g)
exten => _X.,n,Macro(handle-hangup)

[groupC]
exten => _X.,1,Dial(Zap/4/${EXTEN},,g) ; not Zap/g4, just 4
exten => _X.,n,Macro(handle-hangup)

[macro-handle-hangup]
exten => s,1,GotoIf($[${DIALSTATUS} = BUSY]?busy,1)
exten => s,n,GotoIf($[${DIALSTATUS} = CONGESTION]?busy,1)
exten => s,n,GotoIf($[${DIALSTATUS} = CHANUNAVAIL]?busy,1)
exten => s,n,Wait(30)
exten => s,n,Congestion()

exten => busy,1,Busy()

And then in /etc/asterisk/zaptel.conf:

group=1 ; implicitly or explicitly, every channel's in a group
channel => 1

group=2
channel => 2

group=2,3
channel => 3

group=2,3
channel = 4

And finally, your sip.conf:

[11]
type = friend
context = SpecialPerson

[13]
type = friend
context = GroupA

[31]
type = friend
context = GroupA

[14]  (through [20])
type = friend
context = GroupB

[21] (through [30])
type = friend
context = GroupC

Obviously the excerpts from zaptel and sip.conf are only that, excerpts.  
He'll need to fill in the rest.  My handle-hangup macro above is functional, 
but very very sparse.  The real macro I use is quite large and handles all 
the PRI cause codes, ${DIALSTATUS} and ${HANGUPCAUSE} variables.

At any rate, this discussion sure beat the original "RTFM" reply.  :-)

-A.