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 <francisco@deezcurra.com.ar> 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 <

 francisco@deezcurra.com.ar> 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




--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org
pstn:213-799-1400