I would like to dynamically read an asterisk dialplan command from a (dynamically generated) file. Note: Within this file there can be a Dial() or a Playback() command, maybe later more than these two.
Is there any asterisk command or command combination that allows this? Something like
exten => 1234,1,ReadAndExecuteCommandFromFile("/foo/bar")
whereas "/foo/bar" contains one (1) line like
Dial(SIP/123456#provider)
or
Playback(something)
?
The functionality you are looking for is called AGI - Asterisk Gateway Interface. It will allow you to interact with the channel, in a synchronous manner. However, the "Commands" will be slightly different.
There are multiple scripting tool kits for AGI. If you are familiar with PHP, I suggest you have a look at PHPAGI, as it will give you the most bang for your buck in this case.
Simplest way use AGI is do like this:
exten => 1234,1,AGI(/bin/cat /foo/bar)
in /foo/bar file you need place AGI command
EXEC Dial SIP/123456#provider
or
EXEC Playback somefile
However more effective way use func_odbc function+dialplan or full AGI stack(better fast-AGI)
Related
I usually think of UNIX pipes as a quick and dirty way to interact with the console, doing things such as:
ls | grep '\.pdf$' #list all pdfs
I understand that it's possible to use create named pipes using mkfifo and mknod.
Are named pipes still used significantly today, or are they a relic of the past?
They are still used, although you might not notice. As a first-class file-system object provided by the operating system, a named pipe can be used by any program, regardless of what language it is written in, that can read and write to the file system for interprocess communication.
Specific to bash (and other shells), process substitution can be implemented using named pipes, and on some platforms that may be how it actually is implemented. The following
command < <( some_other_command )
is roughly identical to
mkfifo named_pipe
some_other_command > named_pipe &
command < named_pipe
and so is useful for things like POSIX-compliant shell code, which does not recognize process substitution.
And it works in the other direction: command > >( some_other_command ) is
mkfifo named_pipe
some_other_command < named_pipe &
command > named_pipe
pianobar, the command line Pandora Radio player, uses a named pipe to provide a mechanism for arbitrary control input. If you want to control Pianobar with another app, such as PianoKeys, you set it up to write command strings to the FIFO file, which piano bar watches for incoming commands.
I wrote a MAMP stack app in college that we used to manage users in an LDAP database on a file server. The PHP scripts would write commands to a FIFO that a shell script running in launchd would read from and interact with the LDAP database. I had no idea what I was doing, so I don’t know if there was a better or more correct way to do it, but it worked great at the time.
Named pipes are useful where a program would expect a path to a file as an argument as opposed to being willing to read/write with stdin and stdout, though very modern versions of bash can get around this with < ( foo ) it is still sometimes useful to have a file like object which is usable as a pipe.
I am using Asterisk Realtime Dialplan and a FuncODBC call within an Exec() to return a Dial() command.
I want to try and stick a command Set() before the Dial() conditionally depending on if I need to change the CALLERID(num). Is it possible to have multiple commands in a single Dialplan Exec() ?
If so then how can I piece them all together - seperating each function with a comma seems to fail in Asterisk 1.8
Some dialplan would help clarify what your trying to do, but from what I understood your looking for Execif() (use asterisk command core show application ExecIf to learn more)
I have a perl script which calls another perl script using backticks. I want to instead call this script and have it daemonize. How do I go about doing this?
edit:
I dont care to communicate back with the process/daemon. I'll most likely just stick it in an sqlite3 table or something.
You refer to backticks, thus I suppose that you want to communicate with the daemon after it's started? Since daemons does not use STDOUT, you will have to think of some other way of passing information to and from it.
The Perl interprocess communication man page (perlipc) has several good examples of this, especially the section "Complete dissociation of child from parent".
The Proc::Daemon contains convenient functions for daemonizing a process.
I have an asterisk-based PBX, and I have been able to successfully run an AGI script from the web control panel of the PBX.
Because I am calling AGI from Perl (neither of which I know, yet)...
asterisk commands look like this:
print "SET CALLERID $newcid \"\"\n";
So far, I don't expect to need to do any database lookups, etc. I simply want to set the caller ID (which I can do already) - then forward the call to a particular number.
Can anyone show me how to forward the current call using the AGI/perl style of executing asterisk commands shown above?
FYI: I've seen some examples using a format like:
Exten => blah blah....
But, I am not sure how to convert that to the AGI/perl format.
print "EXEC DIAL \"Zap/1/5551234567\"\n";
or, if you are using Asterisk::AGI,
$AGI->exec("DIAL", "Zap/1/5551234567");
Take an undocumented executable of unknown origin. Trying /?, -h, --help from the command line yields nothing. Is it possible to discover if the executable supports any command line options by looking inside the executable? Possibly reverse engineering? What would be the best way of doing this?
I'm talking about a Windows executable, but would be interested to hear what different approaches would be needed with another OS.
In linux, step one would be run strings your_file which dumps all the strings of printable characters in the file. Any constants chars will thus be shown, including any "usage" instructions.
Next step could be to run ltrace on the file. This shows all function calls the program does. If it includes getopt (or familiar), then it is a sure sign that it is processing input parameters. In fact, you should be able to see exactly what argument the program is expecting since that is the third parameter to the getopt function.
For Windows, you can see this question about decompiling Windows executables. It should be relatively easy to at least discover the options (what they actually do is a different story).
If it's a .NET executable try using Reflector. This will convert the MSIL code into the equivalent C# code which may make it easier to understand. Unfortunately private and local variable names will be lost, as these are not stored in the MSIL but it should still be possible to follow what's going on.