it's only possible for the extension who is calling intercept to have
hangup_after_bridge=false set when the bridge terminates and if he's not
already hungup and if the other side ended the call.
Make sure you have latest trunk, this is a new patch.
On Thu, Aug 14, 2008 at 4:00 PM, Francisco de Ezcurra <
[EMAIL PROTECTED]> wrote:
> Yes, that is what i expected. But in my tests, when I hangup the A leg the
> B
> leg goes back to the FIFO it was on before the intercept. And when I hangup
> the B leg the A leg
>
>
> These are the step I followed.
>
> 1) Originate a call via MES and transfer it to the extension 2100
>
> api originate
> {hangup_after_bridge=false}sofia/default/user3.fezcurra
> 2100
>
> <extension name="waiting">
> <condition field="destination_number" expression="2100">
> <action application="fifo" data="myqueue in undef
>
> test/clientdata/system/audios/male/en_US/misc/HoldMusic.wav"/>
> </condition>
> </extension>
>
> 2) Make a call to the extension 2101
>
> <extension name="intercept">
> <condition field="destination_number" expression="2101">
> <action application="answer" />
> <action application="set" data="hangup_after_bridge=false"/>
> <!-- This is the UUID returned in the originate (step 1) -->
> <action application="intercept"
> data="72a3cb6a-6943-11dd-b3aa-65ce53a0ab35"/>
> <action application="transfer" data="2102"/>
> </condition>
> </extension>
>
> <extension name="goodbye">
> <condition field="destination_number" expression="2102">
> <action application="playback"
> data="test/clientdata/system/audios/male/en_US/misc/Goodbye.wav"/>
> <action application="hangup" />
> </condition>
> </extension>
>
> 3)
> a) Hangup the call created in step 2).
> Result: the call originated in step 1 goes back to the FIFO of the
> extension 2100.
>
> b) Hangup the call originated in step 1)
> Result: the call created in step 2) in killed by FS.
>
>
> What I need is to send the leg that did not hang up to another extension.
> Is
> this possible with the dialplan i'm using or I should change it.
>
> Thanks
> Panchi
>
>
> On Thursday 14 August 2008, Anthony Minessale wrote:
> The extension that executed the intercept app is the one that will be able
> to move on in the dialplan after the call because it's the effective A leg
> and that is the extension that had a dialplan instruction set.
>
> BTW,
> you can execute transfer with the -bleg option to perform the transfer on
> the opposite leg of the call.
>
>
>
> On Thu, Aug 14, 2008 at 3:07 PM, Francisco de Ezcurra <
>
> [EMAIL PROTECTED]> wrote:
> > The fix works if i hangup the channel that makes the intercept. The
> other
> > leg
> > goes back to the fifo. But when i hangup the other leg the channel that
> > made
> > the intercept is hung up.
> >
> > What I expect with this (ext. 2101) dialplan is that the channel that
> > makes
> > the intercept executes the transfer to 2102 when the other leg hangs up.
> >
> > Is this possible? I can not use the variable api_hangup_hook on the
> > channel created in the originate via MES because I don't know at that
> > moment the other leg.
> >
> >
> > Thanks
> > Panchi
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
--
Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
AIM: anthm
MSN:[EMAIL PROTECTED] <[EMAIL PROTECTED]>
GTALK/JABBER/PAYPAL:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]>
iax:[EMAIL PROTECTED]/888
googletalk:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
pstn:213-799-1400
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
