On 4/24/11 1:21 PM, Bruce Ferrell wrote:> In the following example
>
> exten => _1NXXNXXXXXX,1,Set(GROUP(outbound)=myprovider)
> exten => _1NXXNXXXXXX,n,Set(COUNT=${GROUP_COUNT(myprovider at
outbound)})
> exten => _1NXXNXXXXXX,n,NoOp(There are ${COUNT} calls for myprovider)
> exten => _1NXXNXXXXXX,n,GotoIf($[ ${COUNT} > 2 ]?denied : continue)
> exten => _1NXXNXXXXXX,n(denied),NoOp(There are too many calls up)
> exten => _1NXXNXXXXXX,n,Hangup()
> exten => _1NXXNXXXXXX,n(continue),GoSub(callmyprovider,${EXTEN},1)
>
> instead of sequentially numbering the priorities, the "n"
construct is used. I
> find that when I attempt this in the realtime extensions table only, the
first
> priority step is recognized. If I sequentially number the priorities and
add a
> label, the step is no longer recognized.
>
> Is this behavior by design or an error?
i think it's probably by design. unlike reading from a
text file, database rely on column values for sorting.
i don't think having 'n' as the priority will sort the way
you want.
--
Edwin Lam <edwin.lam at officegeneral.com>
Systems Engineer, OfficeWyze, Inc.
Ph: +1 415 439 4988 Fax: +1 415 283 3370
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xD6506D20