Is anybody knows , how we can Originate an external number call using PHP AGI script ?
You have got two possible options. One is use the "Originate" command. See http://www.voip-info.org/wiki/view/Asterisk+manager+Example:+Originate for an example.
The other one, which is what I favor in my solutions, since it does not require AMI, is using spooled call files. See https://wiki.asterisk.org/wiki/display/AST/Asterisk+Call+Files for how to do them. The trick, and I cannot stress it enough, is to create the spool file in /tmp and then "move" the file into the ../spool/asterisk/outgoing directory.
If you assign a unique channel variable key/value to the spooled call, you can then pick it up with your dial plan and route the call appropriately.
Related
I am using Asterisk 13.17.0 on a FreePBX 14.0.1.1 distro. I would like to execute a python script whenever a call gets picked up, regardless of whether it is an internal or external one, passing to it as command line parameters the number who's calling and the user who's picking it up. How could I modify my dialplan in order for this to be done? I've tried modifying the [app-pickup] extension in /etc/asterisk/extensions_additional.conf, but picking up an internal call with this modification was to no avail
You should check diall command params, especial G param
https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+Application_Dial
G( context^exten^priority ) - If the call is answered, transfer the calling party to the specified priority and the called party to the specified priority plus one.
context
exten
priority
In freepbx you can change dial params in settings tab.
You also SHOULD NOT ever touch extensions_additional.conf, it even have warning on top of file. File will be rewrited every time you change config. You have do changes in extensions_custom.conf
I want to execute an AGI script for calling party after called party hangs up. For example, for doing a survey for customers I am going to run an AGI script after agent hangs up.
Unfortunately, when AGI scripts runs the agi debug output says:
"511: The command cannot be executed on a dead channel"
I use commands like "ANSWER" or "STREAM FILE" in my agi script which need a channel to run on.
I know that calling channel hangs up as soon as called party hangs up.
I tried DeadAGI instead of AGI and also "g" option in dial command but none of them works.
So, I think I have to search for a solution that keep the calling channel up so that I can run my script on that.
Any suggestion please?
You should not use "g" param for this case, because it is CALLER hangup. You should use "F"
F([[context^]exten^]priority): When the caller hangs up, transfer
the *called* party to the specified destination and *start* execution
at that location.
NOTE: Any channel variables you want the called channel to inherit
from the caller channel must be prefixed with one or two underbars ('_').
F: When the caller hangs up, transfer the *called* party to the next
priority of the current extension and *start* execution at that location.
NOTE: Any channel variables you want the called channel to inherit
from the caller channel must be prefixed with one or two underbars ('_').
NOTE: Using this option from a Macro() or GoSub() might not make
sense as there would be no return points.
g: Proceed with dialplan execution at the next priority in the current
extension if the destination channel hangs up.
Finally I found the answer. The problem is that we don't have to execute agi script in h extension otherwise we get an error for some functions like answer or streamfile in agi. we have to redirect the call to some extension before h extension and for that in elastix I had to change extensions.conf.
When running gnu-make rules with -jN make creates a jobserver for managing job-count across submakes. Additionally you can "pass the jobserver environment" to a make recipe by prefixing it with + - eg:
target :
+./some/complex/call/to/another/make target
Now I instead of a sub-make I have a (python) script which runs some complex packaging actions (too complex for make). One of the actions that it can run into can actually spawn off a make command.
package.stamp : $(DEPS)
+./packaging.py $(ARGS)
touch $#
Now when that make command is invoked inside packaging.py
make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
This makes some sense because whatever environment is setup by make, may not be being honoured or passed through by python.
Is it possible to pass through the jobserver references through the python program to the sub-make - if so, how?
There are two aspects to the jobserver that must be preserved: the first is an actual environment variable, which make uses to send options to sub-makes. That value is being preserved properly, or else make would not know that it should even look for the jobserver and you would not see that warning message.
The second aspect are two open file descriptors which are passed to the children of make. Your script MUST preserve these two descriptors and leave them open when it invokes the sub-make.
You don't show us what Python code is being used to invoke the sub-make. By default, the subprocess module will not close file descriptors, but you can provide the close_fds=True option to have it do so... you should not use this option if you want parallel make invocations to work properly with the jobserver.
If you're not using subprocess, then you'll have to show us what you are doing.
You should probably mark this with a python tag as it's mainly a Python question.
To summarise and clarify the answer - for the jobserver to work in your sub-processes you need to preserve:
Environment variables
The jobserver fds
One of the environment variables passed looks (for me) as follows:
MAKEFLAGS= --jobserver-fds=3,4 -j -- NAME=VALUE
jobserver-fds communicates which fds make has opened to communicate with the jobserver. For the the submake to be able to use the jobserver you should thus preserve, or arrange to be available, those specific fds (or else re-write the environment variable appropriately to point them to whichever fd they end up on).
NAME=VALUE is arguments passed by me to the original make.
I created a client-server application and now I would like to deploy it.
While development process I started the server on a terminal and when I wanted to stop it I just had to type "Ctrl-C".
Now want to be able to start it in background and stop it when I want by just typing:
/etc/init.d/my_service {stop|stop}
I know how to do an initscript, but the problem is how to actually stop the process ?
I first thought to retrieve the PID with something like:
ps aux | grep "my_service"
Then I found a better idea, still with the PID: Storing it on a file in order to retrieve it when trying to stop the service.
Definitely too dirty and unsafe, I eventually thought about using sockets to enable the "stop" process to tell the actual process to shut down.
I would like to know how this is usually done ? Or rather what is the best way to do it ?
I checked some of the files in the init.d and some of them use PID files but with a particular command "start-stop-daemon". I am a bit suspicious about this method which seems unsafe to me.
If you have a utility like start-stop-daemon available, use it.
start-stop-daemon is flexible and can use 4 different methods to find the process ID of the running service. It uses this information (1) to avoid starting a second copy of the same service when starting, and (2) to determine which process ID to kill when stopping the service.
--pidfile: Check whether a process has created the file pid-file.
--exec: Check for processes that are instances of this executable
--name: Check for processes with the name process-name
--user: Check for processes owned by the user specified by username or uid.
The best one to use in general is probably --pidfile. The others are mainly intended to be used in case the service does not create a PID file. --exec has the disadvantage that you cannot distinguish between two different services implemented by the same program (i.e. two copies of the same service). This disadvantage would typically apply to --name also, and, additionally, --name has a chance of matching an unrelated process that happens to share the same name. --user might be useful if your service runs under a dedicated user ID which is used by nothing else. So use --pidfile if you can.
For extra safety, the options can be combined. For example, you can use --pidfile and --exec together. This way, you can identify the process using the PID file, but don't trust it if the PID found in the PID file belongs to a process that is using the wrong executable (it's a stale/invalid PID file).
I have used the option names provided by start-stop-daemon to discuss the different possibilities, but you need not use start-stop-daemon: the discussion applies just as well if you use another utility or do the matching manually.
I have a database where one entry is structured like so:
number_to_call date file_to_play
Using asterisk, I need to do the following:
1. Check the database daily.
2. If date matches that of today's, then initiate call on number.
3. Once phone has been picked up, play file_to_play.
Some general pointers on how I even begin to do this would be great.
Most of the applications that I have written so far have worked on incoming calls. I have the following questions:
1. How do I write a "daemon" that will check the database? Asterisk should have both user and group privileges for it to execute properly. How do I do this?
2. Can I initiate an outgoing call from outside of the asterisk dialplan?
The calls are being made to a PSTN/mobile number.
You can Write any script Which can check DB on daily basis and once it maches the date range you can initiate a call using .call files.
Please study asterisk auto-dial out from voip-info.org - I think you can understand better then.
You can run your script for same user as asterisk runs there is also one more method to initiate call from linux which we can call Originate CLI command which can also refer to http://voip-info.org/.
In general it is not a great idea to write your own dialer, unless your volume is very very low. Where I work, we started rolling our own but at the end went with a commercial solution that handled most of the logic. There are a number of commercial and free solutions out there, so don't reinvent the wheel.
See my answer to https://stackoverflow.com/questions/11666755/outbound-dialer-using-asterisk/14589901#14589901 for why it is not a good idea to roll your own.