I worked with a very bright asterisk person. all the config files were setup. the call file module is installed and running. created the call file in the /var/spool/asterisk/tmp file then cp the file into the outgoing? That is the correct path in manager.conf
Extension is 200 the context directory is default. I used the data as tt-monkeys …which I think is the build in audio file. will not execute the script when moving file into outgoing directory? I did create a python script that does most of the work …but it needs to be finalized.
On Sunday 09 February 2025 at 12:06:28, autodidact via Asterisk Community
wrote:
I worked with a very bright asterisk person. all the config files were
setup. the call file module is installed and running. created the call
file in the /var/spool/asterisk/tmp file then cp the file into the
outgoing? That is the correct path in manager.conf
I would recommend the use of “mv” instead of “cp”.
The difference is that “mv” will take the entire file and make it appear at
once in the outgoing directory, whereas “cp” will copy the file byte by byte or
block by block, and there’s a (very small, but non-zero) possibility that
either a partial or zero-length file might be the first thing that Asterisk finds
in the outgoing directory, and that will cause it not to do what you want /
expect.
Extension is 200 the context directory is default. I used the data as
tt-monkeys …which I think is the build in audio file. will not execute
the script when moving file into outgoing directory? I did create a python
script that does most of the work …but it needs to be finalized.
Show us the callfile you are trying to use, and show us what, if anything,
appears in the Asterisk verbose log when you put the file in place.
Also tell us which version of Asterisk you are using, and how you installed
it. Is this a pure Asterisk installation, or in combination with a GUI
manager such as FreePBX or Issabel?
Antony.
–
A few words to be cautious of between American and English:
There is a caveat to this; both source and destination directories must be on the same file system. If you need atomicity, and that is not the case, you need to do a cp onto the target system, followed by a mv, to the final directory.
Just for clarity (and to confirm my ‘IIRC’), mv just updates the directory entry. Thus, the file that was in source/ is now in destination/ – note that the inode number is not changed and no file blocks were copied.
If mv cannot update the directory entry because the source and destination are on different filesystems, it silently ‘degrades’ to cp (copying blocks) followed by rm.