[Freeswitch-dev] hangup_after_bridge and intercept application

Francisco de Ezcurra francisco at deezcurra.com.ar
Tue Aug 26 20:50:20 EDT 2008

More information:

I was using the intercept application and after switching to uuid_bridge  
(called from javascript) the api_hangup_hook and hangup_after_bridge are 
working well now. When one leg hangs up, the other leg goes to the correct 
	<action application="set" data="api_hangup_hook=uuid_transfer ${pbx_bleg} 
2102" />
           <action application="javascrip" data="api_execute.js uuid_bridge 
${uuid} ${pbx_bleg}"/>
           <action application="transfer" data="2103" />

Is there any difference between how both applications make the bridge ? 


On Friday 22 August 2008, Francisco de Ezcurra wrote:
 I don't understand how/when this line <action application="transfer"
 data="-both 2103" />  is executed if the channel is in a bridge.

 For example, in this case:
  <action application="export" data="hangup_after_bridge=false"/>
  <action application="intercept" data="XXXX" />
  <action application="transfer" data="2103" />

 As I understood, the transfer is executed when the bleg hangs up. But if I
 need to transfer the bleg when the aleg hangs up, the only way i found is by
 using the api_hangup_hook variable. Like this:

 	<action application="set" data="api_hangup_hook=uuid_transfer <BLEG_UUID>
 2102" />

 So, if what I'm saying is correct, how is possible for the leg A to execute
 the transfer with -bleg like below when it hangs up ?

 	<action application="intercept" data="XXXX" />
 	<action application="transfer" data="-bleg 2102" />

 BTW,  the api_hangup_hook works sometimes and sometimes not. I could not
 determine exactly when it works and when it doesn't. I'm attaching two logs
 where I did exactly the same things and in one case it worked and in the
 other case not.

 Here are the dialplan extensions I used to test:

      <extension name="waiting">
         <condition field="destination_number" expression="2100">
           <action application="answer" />
           <action application="fifo" data="myqueue in undef

       <extension name="intercept">
         <condition field="destination_number" expression="2101">
           <action application="set"
           <action application="answer" />
           <action application="export" data="hangup_after_bridge=false"/>
           <action application="set" data="api_hangup_hook=uuid_transfer
 ${pbx_bleg} 2102" />
           <action application="intercept" data="${pbx_bleg}"/>
           <action application="transfer" data="2103" />

       <extension name="goodbye">
         <condition field="destination_number" expression="2102">
           <action application="fifo" data="myqueue in undef

       <extension name="welcome">
         <condition field="destination_number" expression="2103">
           <action application="fifo" data="myqueue in undef

 And here are the steps I followed in both cases:

 1) With the phone registered as user1.fezcurra dial 2100 (the fifo).
 2) Get the channel UUID and set it into the dialplan.
 3) With the phone resgistered as user3.fezcurra dial 2101. (This will bridge
 both channels).
 4)  Hangup the phone registered as user3.fezcurra.

 	In some cases the phone registered as user1.fezcurra goes to the extension
 2102 and in some cases it doesn't and it is hung up by FS.

 Is correct how I am using the api_hangup_hook variable? If not, how can I do
 what I need: "Transfer the leg that did not hangup to another extension" ?


 On Friday 15 August 2008, Anthony Minessale wrote:
  <action application="transfer" data="-bleg 2103" />

  if the call is currently in a bridge it will transfer the other side of the
  call instead of itself.

  <action application="transfer" data="-both 2103" />

  would transfer both legs of the call to the same ext. i.e a conference
  extension etc.

  On Fri, Aug 15, 2008 at 10:28 AM, Francisco de Ezcurra <

  francisco at deezcurra.com.ar> wrote:
  > Anthony
  > I was not answering the call originated via mod_event_socket so that was
  > why
  > it didn't work as I expected. My fault. :(
  > I tried to use the -bleg with transfer but i could not figure out how to
  > use
  > it so used uuid_transfer like this and it is working as I need.
  >     <extension name="intercept">
  >        <condition field="destination_number" expression="2101">
  >           <action application="set"
  > data="bleg=c0153280-6ad8-11dd-85e3-9108b1fae78b"/>
  >          <action application="answer" />
  >          <action application="export" data="hangup_after_bridge=false"/>
  >          <action application="set" data="api_hangup_hook=uuid_transfer
  > ${bleg} 2102" />
  >          <action application="intercept" data="${bleg}"/>
  >          <action application="transfer" data="2103" />
  >        </condition>
  >      </extension>
  > Is there any way to use the transfer application with -bleg in the
  > dialplan ?
  > If yes, how is the syntax ?
  > Thanks in advance
  > 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 at 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
  > _______________________________________________
  > Freeswitch-dev mailing list
  > Freeswitch-dev at lists.freeswitch.org
  > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
  > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
  > http://www.freeswitch.org

More information about the Freeswitch-dev mailing list