Asterisk Call File Example

Posted on |



Asterisk Call Files. Asterisk Call Files are structured files that, when moved to the appropriate directory, are able to automatically place calls using Asterisk. Call files are a great way to place calls automatically without using more complex Asterisk features like the AGI, AMI, and dialplan, and require very little technical knowledge to use. There are a couple of things that you will have to think about to determine the best approach for your situation, here is what I can tell you though - If you do.not. need to listen for DTMF input (keypresses) while playing the audio file then you can play an audio file on an AgiChannel in Java by using something like `agiChannel.exec('playback.

Skip to end of metadataGo to start of metadata

Asterisk has the ability to initiate a call from outside of the normal methods such as the dialplan, manager interface, or spooling interface.

Using the call file method, you must give Asterisk the following information:

  • How to perform the call, similar to the Dial() application
  • What to do when the call is answered

With call files you submit this information simply by creating a file with the required syntax and placing it in the outgoing spooling directory, located by default in /var/spool/asterisk/outgoing/ (this is configurable in asterisk.conf).

The pbx_spool.so module watches the spooling directly, either using an event notification system supplied by the operating system such as inotify or kqueue, or by polling the directory each second when one of those notification systems is unavailable. When a new file appears, Asterisk initiates a new call based on the file's contents.

Creating Files in the Spool Directory

Icon

Do not write or create the call file directly in the outgoing directory, but always create the file in another directory of the same filesystem and then move the file to the outgoing directory, or Asterisk may read a partial file.

NFS Considerations

Icon

By default, Asterisk will prefer to use inotify or kqueue where available. When the spooling directory is on a remote server and is mounted via NFS, the inotify method will fail to work. You can force Asterisk to use the older polling method by passing the --without-inotify flag to configure during compilation (e.g. ./configure --without-inotify).

The call file consists of <Key>: <value> pairs; one per line.

Comments are indicated by a '#' character that begins a line, or follows a space or tab character. To be consistent with the configuration files in Asterisk, comments can also be indicated by a semicolon. However, the multiline comments (;----;) used in Asterisk configuration files are not supported. Semicolons can be escaped by a backslash.

The following keys-value pairs are used to specify how setup a call:

  • Channel: <channel> - The channel to use for the new call, in the form technology/resource as in the Dial application. This value is required.
  • Callerid: <callerid> - The caller id to use.
  • WaitTime: <number> - How many seconds to wait for an answer before the call fails (ring cycle). Defaults to 45 seconds.
  • MaxRetries: <number> - Number of retries before failing, not including the initial attempt. Default = 0 e.g. don't retry if fails.
  • RetryTime: <number> - How many seconds to wait before retry. The default is 300 (5 minutes).
  • Account: <account> - The account code for the call. This value will be assigned to CDR(accountcode)

When the call answers there are two choices:

  1. Execute a single application, or
  2. Execute the dialplan at the specified context/extension/priority.

To execute an application:

  • Application: <appname> - The application to execute
  • Data: <args> - The application arguments

To start executing applications in the dialplan:

  • Context: <context> - The context in the dialplan
  • Extension: <exten> - The extension in the specified context
  • Priority: <priority> - The priority of the specified extension; (numeric or label)
  • Setvar: <var=value> - You may also assign values to variables that will be available to the channel, as if you had performed a Set(var=value) in the dialplan. More than one Setvar: may be specified.

The processing of the call file ends when the call is answered and terminated; when the call was not answered in the initial attempt and subsequent retries; or if the call file can't be successfully read and parsed.

To specify what to do with the call file at the end of processing:

  • Archive: <yes|no> - If 'no' the call file is deleted. If set to 'yes' the call file is moved to the 'outgoing_done' subdirectory of the Asterisk spool directory. The default is to delete the call file.

If the call file is archived, Asterisk will append to the call file:

  • Status: <exitstatus> - Can be 'Expired', 'Completed' or 'Failed'
Asterisk Call File Example

Other lines generated by Asterisk:

Asterisk keep track of how many retries the call has already attempted, appending to the call file the following key-pairs in the form:

With the main process ID (pid) of the Asterisk process, the retry number, and the attempts start and end times in time_t format.

  • <astspooldir>/outgoing - The outgoing dir, where call files are put for processing
  • <astspooldir>/outgoing_done - The archive dir
  • <astspooldir> - Is specified in asterisk.conf, usually /var/spool/asterisk

Call files that have the time of the last modification in the future are ignored by Asterisk. This makes it possible to modify the time of a call file to the wanted time, move to the outgoing directory, and Asterisk will attempt to create the call at that time.

Skip to end of metadataGo to start of metadata

Another example is to use callfiles and Local channels so that you can execute some dialplan prior to performing a Dial(). We'll construct a callfile which will then utilize a Local channel to lookup a bit of information in the AstDB and then place a call via the channel configured in the AstDB.

Asterisk Call File Example Excel

First, lets construct our callfile that will use the Local channel to do some lookups prior to placing our call. More information on constructing callfiles is located in the doc/callfiles.txt file of your Asterisk source.

Our callfile will simply look like the following:

Add the callfile information to a file such as 'callfile.new' or some other appropriately named file.

Our dialplan will perform a lookup in the AstDB to determine which device to call, and will then call the device, and upon answer, Playback() the silence/1 (1 second of silence) and the tt-weasels sound files.

Before looking at our dialplan, lets put some data into AstDB that we can then lookup from the dialplan. From the Asterisk CLI, run the following command:

We've now put the device destination (SIP/0004f2040001) into the 201/device key within the phones family. This will allow us to lookup the device location for extension 201 from the database.

We can then verify our entry in the database using the 'database show' CLI command:

Now lets create the dialplan that will allow us to call SIP/0004f2040001 when we request extension 201 from the extensions context via our Local channel.

Then, we can perform a call to our device using the callfile by moving it into the /var/spool/asterisk/outgoing/ directory.

Then after a moment, you should see output on your console similar to the following, and your device ringing. Information about what is going on during the output has also been added throughout.

Asterisk Call File Example Pdf

You'll see the line above as soon as Asterisk gets the request from the callfile.

This is where we performed our lookup in the AstDB. The value of SIP/0004f2040001 was then returned and saved to the DEVICE channel variable.

We perform a check to make sure ${DEVICE} isn't NULL. If it is, we'll just hangup here.

Now we call our device SIP/0004f2040001 from the Local channel.

We answer the call.

We then start playing back the files.

Example

At this point we now see the Local channel has been optimized out of the call path. This is important as we'll see in examples later. By default, the Local channel will try to optimize itself out of the call path as soon as it can. Now that the call has been established and audio is flowing, it gets out of the way.

We can now see the tt-weasels file is played directly to the destination (instead of through the Local channel which was optimized out of the call path) and then a NOTICE stating the call was completed.