I read some of the documents recently and I have general ideas on asterisk. however, I am not 100% confident in the implementation in following case:
1): originate call: dynamically by some parameters in database or some user actions through some client software to asterisk to ask asterisk to call some one;
2): after the call is answered, it will play a pre recorded messages – (there might be several messages, which message will be played will depends on the some parameters)
3): the result of the call will be inserted the database, like when, if answered or not, etc.
4): also, I am thinking business user can trigger the call or configure this in some GUI, like web, or window applications, applets, etc.
It seems to have several options, call file, manager command, AGI, etc. So which one is best for this job?
I did some thing like what you have above. I had a client that wanted to call customers and ask them to rate service as well as connect them to a provider. I would
Connect to an API via a php script that was ran via a cron job every minute and check for calls (you can do the same via looking in a db for calls that needed to go out).
Connect to the AMI and based on the parameters passed to me set which context the call should go to.
I used the dial plan for most things (e.g. play messages, connect the user with the call center) and used AGI’s to run logic, speak with my customers API, and log the calls (I use my own CDR’s so I can create it based on how the customer wants it).
I am in the process to integrate postgresql. After I set every thing - I think it is correct, but in the CLI> odbc show, it said: no such command. some place is wrong?
Thanks!
I think when you built Asterisk the development files for the unixODBC library or the unixODBC package wasn’t installed and so the Asterisk build process didn’t create the odbc module, so install the unixODBC and its development files, execute “./configure” again, run “make menuselect”, then select “func_odbc” in “dialplan functions” and “res_odbc” in “resource modules” (if you see “XXX” before “func_odbc” and “res_odbc” it means the unixODBC package and/or its development files isn’t/aren’t installed) and build again Asterisk, restart it and the odbc module should be present.
Thanks for explanation on this! But I could not enable the res_odbc because of:
ODBC Resource
Depends on: unixodbc(E), ltdl(E)
It seems to have two problems:
1): Asterisk could not find the odbc,
2): no ltdl.
However,
1):after configured the odbc.ini and odbcinst.init of the installed odbc, I tested the connection to postgresql (in the same box) by "echo "select 1 | isql -v asterisk-connector"
2): on the debian,run command: apt-get install libtool, it seems to install libtool AND development files.
It is due to unixODBC developem files not installed. the debian unixODBC-devel named as unixODBC-dev which is different from what in the most doucments.
After apt-get install unixODBC-dev in debian, follow in the steps by Marco. It works!
Also, I hate to do a self-plug, but you may want to check out my project pycall (pycall.org/). It’s a call file library for asterisk written in python (if you use python) that allows rapid development of the exact sort of stuff you are you trying to create. With a few modifications to the code I already have in the getting started tutorial you could get your software working in an hour or so.
Again, this is completely biased. But I don’t see why you should use the AMI for such a simple project.
Hello Randall,
Thanks for you suggestion! I will check it out.
quick question: if there is no exiting lib and starting from beginning. Which one is better choice and why, AMI or call file, or something else?
Thanks!
Call files are extremely simple to work with. The downside is that they run locally on your asterisk server (not across a network like AMI programs). The upside to using AMI is that it allows you to do more stuff (you can register to listen to events for certain extensions, etc.) but it is more complex.
With my library you can have it creating calls and delivering messages in 10 minutes or less. Just read the getting started tutorial, it is well documented: pycall.org/getting-started/
It walks you through building an application that creates multiple outbound calls that play a soundfile then hangup. It can easily hook in with dial plan to do whatever you need.
I’ve used it myself for a lot of projects similar to what you’ve described, and it has saved me a ton of development time. If you do end up using it, please let me know I’d be happy to hear some feedback.
Sorry just one more thing, here’s some example code which dials phone numbers specified on the command line, and plays the soundfile hello-world when they pick up, then hangs up. Very simple (example) of what you can do:
[code]#!/usr/bin/python
from sys import argv
from pycall.callfile import *
def main():
global USER, TRUNK_TYPE, TRUNK_NAME, SOUNDFILE, CALLERID_NUM
cf = CallFile(
callerid_num = CALLERID_NUM,
trunk_type = TRUNK_TYPE,
trunk_name = TRUNK_NAME,
application = 'Playback',
data = SOUNDFILE,
user = USER
)
for num in argv:
print 'Placing call to %s...' % num
cf.number = int(num)
cf.run()
if name == ‘main’:
main()[/code]
Obviously, this example is really basic, but it does what you want. It doesn’t do error checking or anything, and I threw it together in about 20 seconds.
So in terms of Scalability, AMI provides more than call files, since call files are in the local. If one server fails, you have to copy over to next server. Or …
Correct. You could always use pycall remotely and move the files over, but that would be an ugly solution. It is best to use AMI for large projects and things which need to be scalable.