[Freeswitch-users] auto dialing question ...

Shelby Ramsey sicfslist at gmail.com
Mon Jan 26 00:45:10 PST 2009 

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 <
anthony.minessale at gmail.com> 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 <sicfslist at gmail.com>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/$ANI@$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 <msc at freeswitch.org>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 <sicfslist at gmail.com>
>>> 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/$ANI@$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/$ANI@$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
>>> > <anthony.minessale at gmail.com> 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 <msc at freeswitch.org>
>>> >> wrote:
>>> >>>
>>> >>> On Fri, Jan 23, 2009 at 2:15 PM, Shelby Ramsey <sicfslist at gmail.com>
>>> >>> 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
>>> >>> > Freeswitch-users at 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 at 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/
>>> >>
>>> >> AIM: anthm
>>> >> MSN:anthony_minessale at hotmail.com<MSN%3Aanthony_minessale at hotmail.com>
>>> >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
>>> >> IRC: irc.freenode.net #freeswitch
>>> >>
>>> >> FreeSWITCH Developer Conference
>>> >> sip:888 at conference.freeswitch.org<sip%3A888 at conference.freeswitch.org>
>>> >> iax:guest at conference.freeswitch.org/888
>>> >> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
>>> >> pstn:213-799-1400
>>> >>
>>> >> _______________________________________________
>>> >> Freeswitch-users mailing list
>>> >> Freeswitch-users at 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 at 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 at 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 at 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/
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090126/aedcafb2/attachment-0002.html

More information about the FreeSWITCH-users mailing list