Try it from the FS CLI first to see how to do it. originate <dial string> <extension> <dialplan> <context>
so type this in the console replacing the sofia url with one of your choice: originate sofia/default/[email protected] 9998 XML default when you answer the call you should hear the tetris song. so you can use any e...@context+dialplan combo with those args. You can do the same over xmlrpc or mod_event_socket On Fri, Jan 23, 2009 at 5: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 > > -- 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
