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.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(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 >>> > 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 >>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >>> http://www.freeswitch.org >>> >> >> >> >> -- >> Anthony Minessale II >> >> FreeSWITCH http://www.freeswitch.org/ >> ClueCon http://www.cluecon.com/ >> Twitter: http://twitter.com/FreeSWITCH_wire >> >> AIM: anthm >> MSN:anthony_miness...@hotmail.com <msn%3aanthony_miness...@hotmail.com> >> GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<paypal%3aanthony.miness...@gmail.com> >> IRC: irc.freenode.net #freeswitch >> >> FreeSWITCH Developer Conference >> sip:8...@conference.freeswitch.org <sip%3a...@conference.freeswitch.org> >> iax:gu...@conference.freeswitch.org/888 >> googletalk:conf+...@conference.freeswitch.org<googletalk%3aconf%2b...@conference.freeswitch.org> >> pstn:213-799-1400 >> >> _______________________________________________ >> 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 UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org