MC / Anthony, Muchas gracias ... looks like I'm going to be on my way to being * free :) Ran a small production test today (about 20,000 dials) and going to get after it tomorrow with a real campaign.
You guys kick ass. Thanks again for the assistance fine sirs. Shelby On Fri, Jan 23, 2009 at 6:54 PM, Anthony Minessale < [email protected]> wrote: > its the same idea where i gave you that example to call 9998 call 1234 > where your extension is delivered via curl when 1234 is requested > use the "read" and "transfer" apps in the xml you return, you can get it > working statically first in your regular dialplan. > > > > On Fri, Jan 23, 2009 at 6:20 PM, Shelby Ramsey <[email protected]>wrote: > >> Thanks Michael. >> Here are some really simple examples (we limit what people do through the >> web ... nothing really fancy ... just some good old fashion robo calls). >> ultimately today it looks like this extensions_table (context, exten, >> priority, app, appdata): >> >> campaign,100,1,ANSWER() --> answers call >> campaign,100,2,WAIT(1) --> this is a pause >> campaign,100,3,PLAYBACK($INTROFILE) --> plays intro file >> campaign,100,4,BACKGROUND($MESSAGE) --> plays message >> campaign,100,5,WAITEXTEN(5) --> WAIT for DTMF >> campaign,100,6,HANGUP() >> Here are DTMF options >> campaign,1,SYSTEM($SCRIPT campaign $EXTEN) >> campaign,2,SYSTEM($SCRIPT campaign $EXTEN) >> campaign,3,DIAL,zap/g1/$ANI >> >> anothercampaign,112,1,ANSWER() >> anothercampaign,112,2,BACKGROUND($SOMEFILE) >> anothercampaign,112,3,WAITEXTEN(5) >> anothercampaign,112,4,HANGUP() >> Options: >> anothercampaign,1,DIAL(sip/$...@$ip) >> anothercampaign,2,PLAYBACK($GOODBYE) >> >> And they pretty much all look like that ... it's easy to return the stuff >> for extension 100 via XML ... but the challenge is the DTMF options >> (relating to the same context) ... or maybe I'm just missing something >> (which is a definite possibility). We don't ever do anything complicated in >> the IVRs (TTS or ASR) but there is just a lot of them that all get >> controlled, manipulated via a web interface. >> >> I can originate a call ... do all of that ... just trying to figure out a >> "simple" way to return the above via xml. >> >> Thanks for your help Anthony and Michael as always! >> >> Shelby >> >> >> >> >> >> On Fri, Jan 23, 2009 at 5:55 PM, Michael Collins <[email protected]>wrote: >> >>> I see your dilemma. To keep things dynamic you definitely want to use >>> your XML_CURL stuff. Like you said, nothing static. >>> >>> Can you post a sample call-flow in plain English? I'm curious about >>> something. I don't want to say anything else. Just post a simple call >>> flow: >>> Initiate call >>> Wait for answer/busy/timeout/invalid >>> On busy/timeout/invalid: update db and move on >>> On answer play greeting, accept digit, route based on digit >>> >>> Something like that would help me conceptualize what you are trying to >>> do. >>> >>> Thanks >>> MC >>> >>> P.S. - I've done a little bit of outbound IVR calling so hopefully I >>> can assist you. >>> >>> On Fri, Jan 23, 2009 at 3:39 PM, Shelby Ramsey <[email protected]> >>> wrote: >>> > Anthony / Michael, >>> > Thanks for the quick responses. What I don't want to do is "drive the >>> call" >>> > (by that listen on a socket ... do this on this event ... or anything >>> else >>> > that my very limited FS foo would break) ... Just want to start it and >>> then >>> > give it instructions on where to go. >>> > So I guess a better question would be ... how do I give directions to >>> FS for >>> > this (and I get the 1st part ... that's obvious ... really lost on the >>> DTMF >>> > digit part) ... and please keep in mind we're talking hundreds of >>> extensions >>> > / IVR's and distributed machines so I can't have any dependancy on >>> static >>> > conf files other than maybe something like what Michael mentioned where >>> I >>> > point every call to something: >>> > [campaign] >>> > exten => 100,1,ANSWER() >>> > exten => 100,n,PLAYBACK(somefile) >>> > exten => 100,n,BACKGROUND(somefile) >>> > exten => 100,n,WAITEXTEN(4) >>> > exten => 100,n,HANGUP() >>> > but in that same context is someone triggers DTMF: >>> > exten => 1,1,DOSOMETHING >>> > exten => 2,1,DOSOMETHING >>> > I was imaging issuing originate via XML_RPC ... something like >>> originate >>> > sofia/$...@$ip $SOMEEXTEN then on answer when FS tries to connect to >>> > $SOMEEXTEN it will ask me what to do via xml_curl ... where I would >>> normally >>> > respond with something like this: >>> > <?xml version="1.0" encoding="UTF-8" standalone="no"?> <document >>> > type="freeswitch/xml"> <section name="dialplan" description="FS >>> RESPONSE"> >>> > <context name="public"> <extension name="$EXTEN"> <condition >>> > field="destination_number" expression=""> <action application="set" >>> > data="hangup_after_bridge=true"/> <action application="set" >>> > data="continue_on_fail=true"/> <action application="set" >>> > data="call_timeout=180"/> <action application="set" >>> > data="proxy_media=true"/> <action application="set" >>> > data="pass_rfc2833=true"/> <action application="set" >>> > data="accountcode=$CUSTOMER" /> <action application="set" >>> > data="origination_caller_id_name=NULL" /> <action application="set" >>> > data="origination_caller_id_number=$CIDNUM" /> <action >>> application="set" >>> > data="effective_caller_id_name=NULL" /> <action application="set" >>> > data="effective_caller_id_number=$CIDNUM" /> <action application="set" >>> > data="userfield=$BUNCHOFCRAPFORMYCDR" /> <action application="bridge" >>> > data="sofia/external/$...@$providerip" /> </condition> </extension> >>> > </context> >>> > </section> </document> >>> > The challenge I've got is I have no idea how to do stuff like the IVR >>> > mentioned above (the playback part is easy) ... but I can't grasp >>> > conceptually how to get the "context" with "multiple extensions" part >>> back >>> > to FS via this method (is it possible?)... >>> > Sorry for what is probably a very simple answer and any AST references >>> (but >>> > I've been using it in heavy production environments for about 5 years). >>> Just >>> > trying to "port" what I do today without making my brain melt out of my >>> ears >>> > (and it doesn't take much for that to happen). >>> > Shelby >>> > PS ... Really enjoy the list. I usually fall out of my chair laughing >>> once a >>> > day from your remarks Anthony. Keep it coming! >>> > >>> > On Fri, Jan 23, 2009 at 4:55 PM, Anthony Minessale >>> > <[email protected]> wrote: >>> >> >>> >> Does AST mean Asterisk Open Source PBX ? >>> >> >>> >> If so, then yes I am familiar with it's archetechure as I am a former >>> >> developer from that project. >>> >> >>> >> You have 3 choices with FreeSWITCH >>> >> >>> >> 1) You can open a dedicated connection to mod_event_socket or XMLRPC >>> per >>> >> call and issue the originate command from there: >>> >> This will block until you know for sure the outcome of the >>> attempt. >>> >> If it's success it will give you the uuid if not it gives you the >>> cause >>> >> code. >>> >> >>> >> 2) You can use a single mod_event_socket or XMLRPC connection to send >>> all >>> >> calls but use the bgapi mechanism which will do the same as above >>> >> only asynchronously, The command will return immediately and the >>> >> result will be fired as an event that you can pick up on the same or >>> >> different event_socket connection or >>> >> other event consumer such as a custom C,perl,lua etc module. >>> >> >>> >> 3) You can use mod_xml_cdr to generate detailed 1-file-per-leg call >>> files >>> >> that will tell you when where and why the calls failed or did not >>> fail. >>> >> >>> >> >>> >> On Fri, Jan 23, 2009 at 4:39 PM, Michael Collins <[email protected]> >>> >> wrote: >>> >>> >>> >>> On Fri, Jan 23, 2009 at 2:15 PM, Shelby Ramsey <[email protected]> >>> >>> wrote: >>> >>> > Sorry for the double post ... actually hit send too early ... >>> >>> > OK ... Here goes another I'm doing this with AST ... but I want to >>> >>> > move it >>> >>> > to FS. Searched via google site:lists.freeswitch.org auto dialer >>> and >>> >>> > others >>> >>> > ... nothing useful. >>> >>> > Today I have a platform for auto dialing with AST (centrally >>> managed >>> >>> > ... >>> >>> > about 10 machines) and we do this: >>> >>> > -- Remote machines query central DB for numbers to call based on >>> >>> > certain >>> >>> > configs >>> >>> > -- Use AMI to generate the call >>> >>> > -- If call gets answered, extension info queried via rta (central >>> db >>> >>> > again) >>> >>> > The nice thing about all of this is it's relatively easy to manage >>> >>> > (through >>> >>> > one central web interface we built) and it works ... the bad part >>> is >>> >>> > reporting ... >>> >>> > So ... conceptually I'm trying to accomplish the same thing ... >>> >>> > Today we use FS a lot for termination of VoIP traffic ... all done >>> via >>> >>> > XML_CURL ... which is awesome (not to xml cdr ... and the >>> "proxying" >>> >>> > of >>> >>> > media) ... >>> >>> > Would like to do something like: >>> >>> > -- originate request (looks simple enough) >>> >>> > -- on answer XML_CURL posts info >>> >>> >>> >>> Several choices, depending upon how much you want it handled inside >>> >>> the dialplan vs. handled in the scripting language. For the sake of >>> >>> testing you could do something like this: >>> >>> <extension name="ivr-start"> >>> >>> <condition field="destination_number" expression="ivr_whatever"> >>> >>> <action application="set" data="execute_on_answer=transfer >>> >>> IVR_ANSWER XML default"/> >>> >>> <!-- rest of dialplan --> >>> >>> </condition> >>> >>> </extension> >>> >>> >>> >>> Then have: >>> >>> <extension name="ivr-answer"> >>> >>> <condition field="destination_number" expression="IVR_ANSWER"> >>> >>> <action application="lua" data="post-info.lua >>> >>> ${some_important_value}"/> >>> >>> </condition> >>> >>> </extension> >>> >>> >>> >>> This would have any answered call go to the "ivr-answer" extension >>> >>> while unanswered calls could stay in the ivr-start extension to get >>> >>> properly handled. (Busy, no answer, invalid/SIT, etc.) >>> >>> >>> >>> You could then have the "ivr-answer" extension do whatever is >>> >>> appropriate, like listen for digits, play announcement, beg for >>> money, >>> >>> etc. :) >>> >>> >>> >>> -MC >>> >>> >>> >>> > But for the life of me I can't figure out how to translate this >>> into >>> >>> > the xml >>> >>> > response ... >>> >>> > [campaign] >>> >>> > exten => 100,1,ANSWER() >>> >>> > exten => 100,n,WAIT(2) >>> >>> > exten => 100,n,BACKGROUND(${SOUND_DIR}/somefile) >>> >>> > exten => 100,n,WAITEXTEN(10) >>> >>> > exten => 100,n,HANGUP() >>> >>> > exten => 1,1,PLAYBACK(goodbye) >>> >>> > .... and so on ... >>> >>> > I've looked at the ivr.conf stuff but it's all static and all of >>> this >>> >>> > has to >>> >>> > be manageable via a web interface .... meaning dumping into a DB >>> and >>> >>> > returning an XML response seems reasonable ... but trying to stick >>> or >>> >>> > modify >>> >>> > static text files from the web interface is too much text parsing >>> and >>> >>> > bad >>> >>> > things will happen ... >>> >>> > Any thoughts or pointing me in the right direction would be >>> >>> > appreciated. >>> >>> > Shelby >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > 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 >>> >> >>> >> >>> >> >>> >> -- >>> >> Anthony Minessale II >>> >> >>> >> FreeSWITCH http://www.freeswitch.org/ >>> >> ClueCon http://www.cluecon.com/ >>> >> >>> >> AIM: anthm >>> >> MSN:[email protected]<msn%[email protected]> >>> >> GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> >>> >> IRC: irc.freenode.net #freeswitch >>> >> >>> >> FreeSWITCH Developer Conference >>> >> sip:[email protected]<sip%[email protected]> >>> >> iax:[email protected]/888 >>> >> googletalk:[email protected]<googletalk%3aconf%[email protected]> >>> >> pstn:213-799-1400 >>> >> >>> >> _______________________________________________ >>> >> 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 >>> > >>> > >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > Anthony Minessale II > > FreeSWITCH http://www.freeswitch.org/ > ClueCon http://www.cluecon.com/ > > AIM: anthm > MSN:[email protected] <msn%[email protected]> > GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:[email protected] <sip%[email protected]> > iax:[email protected]/888 > googletalk:[email protected]<googletalk%3aconf%[email protected]> > pstn:213-799-1400 > > _______________________________________________ > 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
