<br><br><div class="gmail_quote">On Thu, Mar 4, 2010 at 2:35 PM, Mark Sobkow <span dir="ltr">&lt;<a href="mailto:m.sobkow@marketelsystems.com">m.sobkow@marketelsystems.com</a>&gt;</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;">



  

<div bgcolor="#ffffff" text="#000000">
Andrew Thompson wrote:
<blockquote type="cite">
  <pre>On Thu, Mar 04, 2010 at 12:36:23PM -0600, Mark Sobkow wrote:
  </pre>
  <blockquote type="cite">
    <pre>I&#39;m having some difficulty with Freeswitch/Erlang processing.  An 
operator dials in and registers by entering a PIN code, which triggers 
an Erlang event handler callback and puts the call into park.  This works.

A customer calls in, which triggers another Erlang event handler 
callback and puts the call into park.  That works, too.

Another thread of Erlang checks the operator and customer queues, and 
uses uuid_bridge to join the two calls together.  That also works.

What _doesn&#39;t_ work is that when the customer hangs up, I want the 
operator A leg to go back into a park state, and it&#39;s hanging up 
instead.  One suspicion I have is that because there is no dialplan 
associated with the call (it&#39;s controlled by Erlang), there is no 
dialplan to &quot;continue&quot; by setting hangup_after_bridge=false.  Either 
that or maybe I need to set the variables on the new UUID returned by 
the uuid_bridge command (though I thought that UUID was just the UUID 
assigned to the command, not a new call identifier.)

BTW, &quot;pbx&quot; is just an OTP rewrite of pieces of the standard 
&quot;freeswitch.erl&quot; code.


    pbx:api( uuid_setvar, Operator#pbx_operator_registry.operator_uuid 
++ &quot; hangup_after_bridge false&quot; ),
    pbx:api( uuid_setvar, Operator#pbx_operator_registry.operator_uuid 
++ &quot; park_after_bridge true&quot; ),

    </pre>
  </blockquote>
  <pre>Try using park_after_bridge and catch the park event or
transfer_after_bridge and set the dialplan location to transfer the call
to.

Andrew

  </pre>
</blockquote>
What a relief.  &quot;transfer_after_bridge&quot; worked!  Plus it provided an
obvious way for me to collect the call result code, fire it back to
Erlang, and leave the operator waiting for the next incoming call. :)<br>
<br></div></blockquote><div>&quot;Another satisfied customer!&quot; :D Now it&#39;s time to throw some of that Canadian colored money at Tony&#39;s paypal account. ;)<br>BTW, what kind of solution are you developing? <br>
-MC<br></div></div>