Hmm, well, the Dial() command in 1.2 has the power to do call screening:

  http://www.voip-info.org/wiki/view/Asterisk+cmd+Dial#Dialmacros

And it looks like features.conf _might_ let you interrupt a call in
progress using the [applicationmap] section, though I haven't gotten
that to work yet:

  http://www.voip-info.org/wiki/view/Asterisk+config+features.conf

Don't ask me why there's only a ZapBarge, and no generic Barge... If you
go for the conferencing solution, I suggest you build cmd_conference, as
it's much lighter weight, and doesn't have all the timing issues meetme
does.

  http://www.voip-info.org/wiki/index.php?page=Asterisk+cmd+conference

There's an example there on how to send random announcements into the
conference using AMI on that page too.

re,
spd

On Wed, 5 Sep 2007, Mike C. Fletcher wrote:

> [EMAIL PROTECTED] wrote:
> > I think you can do something like that with chan_local
> >
> If I'm reading correctly, chan_local will immediately drop out when the
> SIP channel is connected to it.  That is, you have caller A "dial" the
> local context, it starts processing a dialplan, but the moment it
> completes a Dial() out to the user, the two calls are linked and cease
> processing in their dialplan (i.e. on success they cease dialplan
> processing, but if the dial fails they continue in the dialplan).  I'm
> trying to intercept the second call *after* the dial-out completes, that
> is, the callee would get connected to an IVR that would allow for opting
> out of all future calls, *then* the link would go through.
>
> For background, this is what I'm looking at:
>
>     * caller one gets his call, quick "hello" and record your name, then
> starts ringing caller 2 (continue ringing until bridge)
>     * caller two gets her call, IVR says "hi, you've got a call from"
> name, if you'd like to accept, press X, if you'd like to reject, press
> Y, if you'd like to ban this user from calling you again, press Z, if
> you'd like to prevent all future calls from all users, press A, if they
> choose X, they get linked with the caller (whose ringing ears now stop
> ringing).
>     * after a given period, the two callers hear a "sorry, your time is
> running out" and then a few seconds later a cheery "goodbye" to both
>     * preferably, at any point during the call, caller two (the callee)
> could invoke the options to bar/ban caller one
>
> At the moment I don't see how to do do that with chan_local... but then
> I've been dense before :) .  At the moment the only approach seems to be
> using MeetMe (or whatever) to bridge the two connections once they've
> gone through their respective IVRs to allow for the escapes to menus and
> playing the sounds (given the seemingly broken L option on my machine
> (still no luck there)).
>
> You would think this could be a matter of:
>     * dial each user into a context
>     * provide IVR introduction
>     * monitor the channels for IVRs, on IVR un-bridge the channels if
> bridged already and have each continue in their previous contexts with
> the IVR selection available
>     * bridge the channels
>     * play sound into channel at X time
>     * un-bridge after X period with '' as the IVR selection
>
> Oh well, that's life.
>
> Have fun,
> Mike
> > On Wed, 5 Sep 2007, Mike C. Fletcher wrote:
> ...
> >> In another "heh,
> >> wouldn't this be an obvious first thing to expose" moment, it looks like
> >> the ami command "Bridge" is only available in Asterisk 1.6+.
> >> Double-sigh.  I gather there must be a reasonable way to take two
> >> outgoing legs and join them with a short dialplan IVR interposed before
> >> you put either caller into the bridge... but I don't see it yet short of
> >> MeetMe or the like.
> >>
> ...
>
> --
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to