I spent several months trying to figure out something similar to this
myself a while back. The solution I came up with finally really works
great, and I think it should work for you too.
Once the incoming caller is in the dialplan, issue a Dial() command using
both the "m" option and the "M()" option, in addition to any
other options
you would normally be using for Dial(). The "m" option will play
music on
hold while the Dial() command "does it's thing". The M() option
will take
an argument in between the ()'s, and that argument should be a Macro that
you define in extensions.conf. When the call connects to the on-call
operator via Dial(), execution will pass to that Macro, yet the original
caller is still on hold listening to music the whole time, unaware of what
is happening with your operator. The Macro can basically ask whether the
operator is able to take the call or not, and you can even do really
advanced stuff like announce the caller ID to the operator, or other
call-identifying information, so they can decide if they need to take the
call or not. When the Macro exits, have it set the variable MACRO_RESULT
depending on whether the operator is going to take the call or not. If
you don't set MACRO_RESULT, or set it to "", then the call will be
bridged
and the 2 parties will be talking to eachother. If the operator rejects
the call, then you can set MACRO_RESULT to
GOTO:<context>^<exten>^<priority> and it will transfer the
original
incoming caller to that context/exten/priority after the Macro is done
executing. There, you can either play a message to the original caller
and hang up, send them to voicemail, or try another operator - anything
you want really.
I also found you can run an AGI script inside the Macro and it still
works, so that makes it possible to do some really advanced call menu
structures with database lookups, etc.
The original incoming caller will hear nothing but music on hold the
entire time from when you first call Dial() until the Macro is finished
executing, which then means either the call is bridged, or the caller is
sent to yet another context due to rejection.
This type of routine typically is used for a "call announce" menu in a
find me/follow me scenario, and is very useful considering you don't know
if the recipient is going to answer, or their cell phon voicemail picks
up, or their 3 year old picks up the phone, etc. You could even set it up
to require the operator to enter a PIN code before they can bridge the
call, so that the operator's 8 year old can't answer the call and
confuse
the customer, etc. Very very flexible stuff.
I think this will work for what you want to do. Hope it helps...
-- Nick
On Fri, 23 Nov 2007, Alberto Pastore wrote:
> Hi everybody.
>
> I am in the following scenario:
>
> 1 Customer "A" calls an asterisk box over a Zap channel on
> a toll free number during night time
>
> 2 The incoming call enters an AGI script on the dialplan
>
> 3 The AGI script plays back a welcome message, then
> starts the music-on-hold stream
>
> 4 The AGI script originates a calls to a
> stand-by operator's cell phone (operator "B")
>
> 5 When the operator "B" answers the call, he is prompted
> (via another AGI script in the dialplan)
> to dial "1" to be recognized as "human" (the AMD()
> function is too random to be useful)
>
> 6 After being recognized as human, Customer "A" must
> be bridged to Operator "B"
>
> Everything is ok from 1 to 5, but I cannot really figure out
> how to accomplish task #6....
> I've tried with MeetMe or call parking but with no success.
>
> Can anyone point me in the right direction?
> Thanks
>
>
> --
> Alberto Pastore
> B-Press Srl - Gruppo MSoft
> P.IVA 01697420030
> P.le Lombardia, 4 - 28100 Novara - Italy
> Tel. 0321-499508
> Fax 0321-492974
> http://www.msoft.it
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>