[Asterisk-Users] How to make groups of extensions ???
C F
shmaltz at gmail.com
Wed Mar 22 09:16:11 MST 2006
On 3/22/06, Andrew Kohlsmith <akohlsmith-asterisk at benshaw.com> wrote:
> 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. :-)
Can't agree more with you.
>
> -A.
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> Asterisk-Users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
More information about the asterisk-users
mailing list