So, what happens is that when you are executing an app, the state is 
CS_EXECUTE. Even if the session is hungup, the state machine doesn't go through 
all the hangup code until your app executes. 

The easiest workaround is probably to start a background api (bgapi?) call to a 
script. This will happen on another thread, then allow your current thread to 
execute and the hangup code will execute. This should work just fine, I think. 
(You can stop reading here.)

But wait, there's even more fun! anthm recently checked in a change a couple 
days that lets you work around this. Don't call destroy, call hangup on the 
session, on that session's thread. This will perform a hangup, then progress 
the state machine. Then the session will truly be hungup. Maybe you need update 
your freeswitch code, if this is not happening for you.

If you updated and hangup still isn't hanging up, you might want to ask 
specifically about that. Or, you may need to call 
switch_core_session_hangup_state directly -- just hangup alone might not do the 
trick. This is a C function, and not exposed to languages by default - you can 
either patch javascript plugin to expose this safely (and I have no idea what 
this means for the javascript runtime), or use a more capable plugin like 
mod_managed which _does_ expose all the C functions, and lets you call in and 
out of them as you please.

And now, someone who knows what they're talking about will chime in and point 
out what I got wrong.

Thanks,
-Michael

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Alberto 
Escudero
Sent: Thursday, September 17, 2009 3:20 PM
To: [email protected]
Subject: [Freeswitch-users] Callback in Javascript, session.destroy() does not 
free the channel!

We are trying to create a callback application in Javascript. We get the
callerid from the unanswered call and after destroying the session, we
initiate a callback to the user to conenct it to a local extension in the
dialplan.

Although we have tried to destroy the first session, or even invoke a
second script using apiExecute("jsrun",dialer.js"), tried session.hangup()
or exit()... the first session does not seem to close properly until the
whole chain of scripts are completed.

Here is a piece of code that shows the concept (yes!, the sleep function
is far from ideal. CPU loves it! )

function sleep(milliseconds) {
  var start = new Date().getTime();
  for (var i = 0; i < 1e7; i++) {
    if ((new Date().getTime() - start) > milliseconds){
      break;
    }
  }
}

if (session.ready()) {
        //We catch the caller_id
        caller_id_num = session.caller_id_num;

        console_log("Now we got your Caller ID\n");

        //How long we want to wait to trigger a call back
        session.execute("sleep",5000);

        console_log("We have waited a while... time to create the
callback\n");

        //apiExecute("jsrun", "callback.js");
        }

//Destroy the session...
session.destroy();
session=undefined;

sleep(10000);

//Preparing callback
session2 = new
Session('{ignore_early_media=true}celliax/interface1/600464646');
session2.setAutoHangup(false);
session2.answer();
exit();

++
Wisdom thoughts?

-- 
Stopping junk mailers is good for the environment




_______________________________________________
FreeSWITCH-users mailing list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

_______________________________________________
FreeSWITCH-users mailing list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Reply via email to