<div dir="ltr">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.<br>
<br>Make sure you have latest trunk, this is a new patch.<br><br><br><div class="gmail_quote">On Thu, Aug 14, 2008 at 4:00 PM, Francisco de Ezcurra <span dir="ltr"><<a href="mailto:francisco@deezcurra.com.ar">francisco@deezcurra.com.ar</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yes, that is what i expected. But in my tests, when I hangup the A leg the B<br>
leg goes back to the FIFO it was on before the intercept. And when I hangup<br>
the B leg the A leg<br>
<br>
<br>
These are the step I followed.<br>
<br>
1) Originate a call via MES and transfer it to the extension 2100<br>
<div class="Ih2E3d"><br>
api originate {hangup_after_bridge=false}sofia/default/user3.fezcurra<br>
2100<br>
<br>
</div><div class="Ih2E3d"> <extension name="waiting"><br>
<condition field="destination_number" expression="2100"><br>
<action application="fifo" data="myqueue in undef<br>
test/clientdata/system/audios/male/en_US/misc/HoldMusic.wav"/><br>
</condition><br>
</extension><br>
<br>
</div>2) Make a call to the extension 2101<br>
<div class="Ih2E3d"><br>
<extension name="intercept"><br>
<condition field="destination_number" expression="2101"><br>
<action application="answer" /><br>
<action application="set" data="hangup_after_bridge=false"/><br>
<!-- This is the UUID returned in the originate (step 1) --><br>
<action application="intercept"<br>
data="72a3cb6a-6943-11dd-b3aa-65ce53a0ab35"/><br>
<action application="transfer" data="2102"/><br>
</condition><br>
</extension><br>
<br>
</div> <extension name="goodbye"><br>
<div class="Ih2E3d"> <condition field="destination_number" expression="2102"><br>
<action application="playback"<br>
</div> data="test/clientdata/system/audios/male/en_US/misc/Goodbye.wav"/><br>
<div class="Ih2E3d"> <action application="hangup" /><br>
</condition><br>
</extension><br>
<br>
</div>3)<br>
a) Hangup the call created in step 2).<br>
Result: the call originated in step 1 goes back to the FIFO of the<br>
extension 2100.<br>
<br>
b) Hangup the call originated in step 1)<br>
Result: the call created in step 2) in killed by FS.<br>
<br>
<br>
What I need is to send the leg that did not hang up to another extension. Is<br>
this possible with the dialplan i'm using or I should change it.<br>
<br>
Thanks<br>
Panchi<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
On Thursday 14 August 2008, Anthony Minessale wrote:<br>
The extension that executed the intercept app is the one that will be able<br>
to move on in the dialplan after the call because it's the effective A leg<br>
and that is the extension that had a dialplan instruction set.<br>
<br>
BTW,<br>
you can execute transfer with the -bleg option to perform the transfer on<br>
the opposite leg of the call.<br>
<br>
<br>
<br>
On Thu, Aug 14, 2008 at 3:07 PM, Francisco de Ezcurra <<br>
<br>
<a href="mailto:francisco@deezcurra.com.ar">francisco@deezcurra.com.ar</a>> wrote:<br>
> The fix works if i hangup the channel that makes the intercept. The other<br>
> leg<br>
> goes back to the fifo. But when i hangup the other leg the channel that<br>
> made<br>
> the intercept is hung up.<br>
><br>
> What I expect with this (ext. 2101) dialplan is that the channel that<br>
> makes<br>
> the intercept executes the transfer to 2102 when the other leg hangs up.<br>
><br>
> Is this possible? I can not use the variable api_hangup_hook on the<br>
> channel created in the originate via MES because I don't know at that<br>
> moment the other leg.<br>
><br>
><br>
> Thanks<br>
> Panchi<br>
<br>
</div></div><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Freeswitch-dev mailing list<br>
<a href="mailto:Freeswitch-dev@lists.freeswitch.org">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>
</div>