[Asterisk-Users] (no subject)

[support at sjobeck.com]

Rich,
 
What about a combination of your excellent/intelligent suggestion &
something like this:
 
exten => 911,1,Dial(Zap/g17/${EXTEN})
exten => 911,2,SoftHangup(Zap/1-1)
exten => 911,3,Wait(1)
exten => 911,4,Goto(1)

... with the idea that if a line is not free, we forcible seize one.
 
Probably not correctly written, but, do you "get" where I am going? 
 
How would I write this so it "forcibly seized" a line out of that group?
 
Thanks so much (I see a lot of your posts, and you are a steely eyed
muscle man ... keep up the great work)
 
Peace. Love. Linux.
 
Jason
 
 
 
<snip>

> [e911]
> exten => 911,1,ChanIsAvail(Zap/1)
> exten => 911,2,Dial(Zap/1/911)
> exten => 911,3,Hangup()
> exten => 911,102,ChanIsAvail(Zap/4)   
> exten => 911,103,Dial(Zap/4/911)
> exten => 911,104,Hangup()
> exten => 911,203,ChanIsAvail(Zap/5)
> exten => 911,204,Dial(Zap/5/911)
> exten => 911,205,Hangup()
> exten => 911,304,SoftHangup(Zap/5-1)
> exten => 911,305,Wait(2)
> exten => 911,306,Goto(204)
> 
> Did I get the Priority + 101 idea right here?
 
Probably a better way to do that is to use "group=17" within the
zapata.conf definitions for zap/1, zap/4, and zap/5. Then use 
something like 
 exten => 911,1,Dial(Zap/g17/${EXTEN})
 
In your example above, if ChanIsAvail(Zap/1) finds that Zap/1 is
unavailable, then priority 102 will be executed. However, what do
you want to happen if Zap/1 is available (at least from asterisk's
perspective), but the pstn line on Zap/1 doesn't process the call
for whatever reason?
 
If you're doing the above for a home system, you can probably handle
failures in lots of different ways. But, if you're doing this for
a business client, the above approach will leave you open for a
fair number of legal liability issues when it doesn't work as 
expected.
 
Just as a simple test, disconnect the pstn line from Zap/1 and
see what happens when a call is placed.

</snip>