Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel!
Hi Michael, I will like to get a few RINGS back to the user and sleep a bit before the call back. The second i can do using the app sleep. What about the first thing? http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_ring_ready Will test i let you know... Crazy Callbacker aka aep -- Stopping junk mailers is good for the environment FYI, I did a POC on this: extension name=crazy_callback condition field=destination_number expression=^(\d{10})$ action application=set data=luarun dump_arg.lua ${caller_id_number} ${caller_id_name}/ /condition /extension dump_arg.lua: -- dump_args.lua -- print out the args freeswitch.consoleLog(info, Arg1: .. argv[1] .. \n) freeswitch.consoleLog(info, Arg2: .. argv[2] .. \n) From there you can do whatever you want in the target script. I'm sure perlrun, pyrun, and jsrun are all the same in terms of accepting args and running whatever you want, like generating an originate API, etc. Just remember that the caller needs to hangup before you can call him back. :) -MC On Fri, Sep 18, 2009 at 7:53 AM, Anthony Minessale anthony.miness...@gmail.com wrote: You could put an api_hangup_hook on the channel to jsrun your script. What you want with javascript is not going to happen as long as you execute the script *WITH* the channel. it's not a problem it's just misuse/misunderstanding on your part. On Fri, Sep 18, 2009 at 5:03 AM, Alberto Escudero aep.li...@it46.sewrote: Thanks for all the tips. I tried to run apiExecute(bgapi, jsrun originate) and still Javascript?? does not let the thread go. No matter the combination of session.hangup(), exit, apiExecute with or without bgapi, the state remains in CS_EXECUTE. So at the end i am triggering an event that i can later use to execute a originate callback. It is nicer with ESL but i still think that will be nice to have a real way to expunge a second Javascript and let the first one die. The GSM channel/modem needs to be free-free (as I am a serial port-free) to handle the outgoing call. The callback script worked perfect with SIP because it does not care how many sessions are running in parallel. It can always place a call back event the channel is not properly close. /aep -- Stopping junk mailers is good for the environment 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: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Alberto Escudero Sent: Thursday, September 17, 2009 3:20 PM To: freeswitch-users@lists.freeswitch.org 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
Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel!
On Thu, Sep 17, 2009 at 5:53 PM, Michael Giagnocavo m...@giagnocavo.netwrote: Oh, weird. Seems to work in other languages. Yet another reason to use Lua instead of JS. :) -MC ___ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel!
Thanks for all the tips. I tried to run apiExecute(bgapi, jsrun originate) and still Javascript?? does not let the thread go. No matter the combination of session.hangup(), exit, apiExecute with or without bgapi, the state remains in CS_EXECUTE. So at the end i am triggering an event that i can later use to execute a originate callback. It is nicer with ESL but i still think that will be nice to have a real way to expunge a second Javascript and let the first one die. The GSM channel/modem needs to be free-free (as I am a serial port-free) to handle the outgoing call. The callback script worked perfect with SIP because it does not care how many sessions are running in parallel. It can always place a call back event the channel is not properly close. /aep -- Stopping junk mailers is good for the environment 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: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Alberto Escudero Sent: Thursday, September 17, 2009 3:20 PM To: freeswitch-users@lists.freeswitch.org 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(1); //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 FreeSWITCH-users@lists.freeswitch.org 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 FreeSWITCH-users@lists.freeswitch.org 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 FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel!
You could put an api_hangup_hook on the channel to jsrun your script. What you want with javascript is not going to happen as long as you execute the script *WITH* the channel. it's not a problem it's just misuse/misunderstanding on your part. On Fri, Sep 18, 2009 at 5:03 AM, Alberto Escudero aep.li...@it46.se wrote: Thanks for all the tips. I tried to run apiExecute(bgapi, jsrun originate) and still Javascript?? does not let the thread go. No matter the combination of session.hangup(), exit, apiExecute with or without bgapi, the state remains in CS_EXECUTE. So at the end i am triggering an event that i can later use to execute a originate callback. It is nicer with ESL but i still think that will be nice to have a real way to expunge a second Javascript and let the first one die. The GSM channel/modem needs to be free-free (as I am a serial port-free) to handle the outgoing call. The callback script worked perfect with SIP because it does not care how many sessions are running in parallel. It can always place a call back event the channel is not properly close. /aep -- Stopping junk mailers is good for the environment 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: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Alberto Escudero Sent: Thursday, September 17, 2009 3:20 PM To: freeswitch-users@lists.freeswitch.org 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(1); //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 FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org ___
Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel!
FYI, I did a POC on this: extension name=crazy_callback condition field=destination_number expression=^(\d{10})$ action application=set data=luarun dump_arg.lua ${caller_id_number} ${caller_id_name}/ /condition /extension dump_arg.lua: -- dump_args.lua -- print out the args freeswitch.consoleLog(info, Arg1: .. argv[1] .. \n) freeswitch.consoleLog(info, Arg2: .. argv[2] .. \n) From there you can do whatever you want in the target script. I'm sure perlrun, pyrun, and jsrun are all the same in terms of accepting args and running whatever you want, like generating an originate API, etc. Just remember that the caller needs to hangup before you can call him back. :) -MC On Fri, Sep 18, 2009 at 7:53 AM, Anthony Minessale anthony.miness...@gmail.com wrote: You could put an api_hangup_hook on the channel to jsrun your script. What you want with javascript is not going to happen as long as you execute the script *WITH* the channel. it's not a problem it's just misuse/misunderstanding on your part. On Fri, Sep 18, 2009 at 5:03 AM, Alberto Escudero aep.li...@it46.sewrote: Thanks for all the tips. I tried to run apiExecute(bgapi, jsrun originate) and still Javascript?? does not let the thread go. No matter the combination of session.hangup(), exit, apiExecute with or without bgapi, the state remains in CS_EXECUTE. So at the end i am triggering an event that i can later use to execute a originate callback. It is nicer with ESL but i still think that will be nice to have a real way to expunge a second Javascript and let the first one die. The GSM channel/modem needs to be free-free (as I am a serial port-free) to handle the outgoing call. The callback script worked perfect with SIP because it does not care how many sessions are running in parallel. It can always place a call back event the channel is not properly close. /aep -- Stopping junk mailers is good for the environment 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: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Alberto Escudero Sent: Thursday, September 17, 2009 3:20 PM To: freeswitch-users@lists.freeswitch.org 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...
[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(1); //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 FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel!
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: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Alberto Escudero Sent: Thursday, September 17, 2009 3:20 PM To: freeswitch-users@lists.freeswitch.org 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(1); //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 FreeSWITCH-users@lists.freeswitch.org 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 FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel!
session.dispose(); ??? On Thu, Sep 17, 2009 at 5:20 PM, Alberto Escudero aep.li...@it46.se wrote: 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(1); //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 FreeSWITCH-users@lists.freeswitch.org 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 FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel!
Dispose is a .NET only thing. But I think you are right - with anthm's changes, any way you kill your session, if you're on the right thread, it should really hangup. -Michael From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Phillip Jones Sent: Thursday, September 17, 2009 3:38 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel! session.dispose(); ??? On Thu, Sep 17, 2009 at 5:20 PM, Alberto Escudero aep.li...@it46.semailto:aep.li...@it46.se wrote: 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(1); //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 FreeSWITCH-users@lists.freeswitch.orgmailto:FreeSWITCH-users@lists.freeswitch.org 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 FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel!
On Fri, Sep 18, 2009 at 12:08 AM, Michael Giagnocavo m...@giagnocavo.net wrote: Dispose is a .NET only thing. But I think you are right – with anthm’s changes, any way you kill your session, if you’re on the right thread, it should really hangup. Problem is, we are trying to *not answer* the incoming call, get the callid from the ring, destroy the session, create another session (on the same, monoline interface), and make an outbound call. Javascript (last svn) give us a 2009-09-18 01:18:49.291721 [ERR] inline:1 Session is not answered! if we try to session.hangup() a session that was not answered (by the way, it makes sense). -giovanni -- Sincerely, Giovanni Maruzzelli Cell : +39-347-2665618 ___ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel!
Oh, weird. Seems to work in other languages. -Original Message- From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Giovanni Maruzzelli Sent: Thursday, September 17, 2009 5:27 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Callback in Javascript, session.destroy() does not free the channel! On Fri, Sep 18, 2009 at 12:08 AM, Michael Giagnocavo m...@giagnocavo.net wrote: Dispose is a .NET only thing. But I think you are right - with anthm's changes, any way you kill your session, if you're on the right thread, it should really hangup. Problem is, we are trying to *not answer* the incoming call, get the callid from the ring, destroy the session, create another session (on the same, monoline interface), and make an outbound call. Javascript (last svn) give us a 2009-09-18 01:18:49.291721 [ERR] inline:1 Session is not answered! if we try to session.hangup() a session that was not answered (by the way, it makes sense). -giovanni -- Sincerely, Giovanni Maruzzelli Cell : +39-347-2665618 ___ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org 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 FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org