[Asterisk-Dev] Forking the dialplan via Dial(LOCAL/...&LOCAL/...) (was Re: [Asterisk-Users] Dialplan question)

[steve at daviesfam.org]

On Fri, 6 Aug 2004 steve at daviesfam.org wrote:

> /me daydreams about being able to fork in the dialplan.
> 
> Actually you sort of can - wonder what something like: 
> 
>   Dial(Zap/1&LOCAL/s at AlsoDoThis&LOCAL/s at AndThisToo)
> 
> would do?

Well - I tried this:


=========================
exten => *22*,1,Answer
exten => *22*,2,Dial(SIP/6061&LOCAL/s at andthis)
exten => *22*,3,Busy

[andthis]
exten => s,1,Noop(in andthis)
exten => s,2,Wait(10)
exten => s,3,Answer
exten => s,4,Wait(1)
exten => s,5,Festival(Give up.  He's not going to answer)
exten => s,6,Wait(1)
exten => s,7,Busy
=========================


...which works perfectly.

But the current limitations are that once one leg answers, all the others 
are dropped.  And until you answer, the called legs aren't bridged to the 
caller and so the pbx started within the LOCAL channel can't "hear" digits 
etc.

I then tried this:

=========================
exten => *22*,1,Answer
exten => *22*,2,Dial(SIP/6061&LOCAL/s at andthis)
exten => *22*,3,Busy

[andthis]
exten => s,1,Noop(in andthis)
exten => s,2,ResponseTimeout(10)

exten => 1,1,Answer
exten => 1,2,Wait(1)
exten => 1,3,Festival(you pressed one)
exten => 1,4,Wait(1)
exten => 1,5,Busy

exten => t,1,Answer
exten => t,2,Wait(1)
exten => t,3,Festival(Give up.  He's not going to answer)
exten => t,4,Wait(1)
exten => t,5,Busy
=========================

The timeout and so on works fine here - but as I expected, the dialled 
digit (the "1") is not heard by the LOCAL channel.  So there is no way to 
trigger the "1" exten.

[I did notice that if I hit any DTMF key FTER the LOCAL channel Answers
in the "t" exten, then I get rewarded with an Asterisk seg fault.  So
there is something a bit messed up there.  The call was originated via 
CAPI.  You don't see this when the call comes in SIP or IAX2.]

But putting that aside, perhaps there is a way to propagate the digits
within Dial() so that the LOCAL channel sees them.

Actually, if we do that, we could then go further and allow for setting a
called channel to persist even after another Answers.

Now, as well as the ability to ring phones and do dialplan stuff in
parallel, per the original request, you can also keep the dialplan
listening on a connected call.

This would allow flexible implementation of things like transfer,
announcement of time remaining, etc etc (avoiding the endless
proliferation of special Dial() options).  We've talked about this before.

Steve