• Asterisk Call Manager

We want to build an application whereas we call an external number and play a file, similar to the command: originate SIP/TrunkName/ application playback hello-world whereas TrunkName is the name of the external (& outgoing) SIP trunk, the external number to get dialed and hello-world the name of the audio file to be played when the call recipient lifts the handset. It works fine, however there is no way to add the originator CallerID, e.g. 9999, to record within the CDR as well that the outgoing call was placed by the extention 9999 (belonging to a specific client, for billing/tracking purposes). I have been searching several fora and Google articles, to no effect. How can we include the originator’s CalledID within the above command and/or perform the same action operationally (dial out and playback a file)?

After it works using CLI, we plan to integrate this as an AMI call. Any help would be greatly appreciated! We tried that, as follows: action: originate channel: SIP/MyTrunk/7890 application: playback data: hello-world MaxRetries: 2 RetryTime: 30 WaitTime: 20 SetCDRUserField: 45642132 Asterisk does dial outbound, however within CDR we want to include a custom value (e.g. An ID of the type 45642132) in order to be able to get return codes and cross-match CDR with application data. We haven’t managed to record such a variable to CDR using for example the SetCDRUserField command (which must be depreciated as well). Hence, (a) Is there a way to record within CDR a custom (random) ID string?

(b) Can we add ActionID: (or a similar) parameter to the callfile in order to be able to disseminate call execution responses from our application as they are received from Asterisk? © Unless the reveiver of the call answers the call, the script will continue redial indefinitely to the outbound number. Moreover, the status recorded in the CDR is not “NOT ANSWERED” if he receiver handset is not lifted, but “BUSY” always.

Hence, the values: MaxRetries: 2 RetryTime: 30 WaitTime: 20 are never respected/recognized by the script. Our alternative implementation using AMI: action: originate channel: SIP/MyTrunk/7890 application: playback data: hello-world MaxRetries: 2 RetryTime: 30 WaitTime: 20 actionid: 1234567 exten: 1234 is not operational, as it reports that this extension number is not available/present (although it is present!) Call files is a very rough alternative to the AMI way. However, if AMI does not support the dial-and-playback-file operation we require, we’ll try the call file way. Update: We also tried: Channel: SIP/9999 MaxRetries: 2 RetryTime: 60 WaitTime: 30 Context: call-file-test Extension: 9998 Account: 123456789 CallerID: “Test Call Originator” where call-file-test exten = 10,1,Answer exten = 10,n,Wait(1) exten = 10,n,Playback(hello-world) exten = 10,n,Wait(1) exten = 10,n,Hangup When invoked, we get from asterisk: pbx.c:6510 astpbxrun: Channel ‘SIP/992’ sent to invalid extension but no invalid handler: context,exten,priority=call-file-test,9998,1 Extensions 9999/9998 do exist. Within the CDR, albeit the file did not playback when receiver answered and line was immediately hang up, within the CDR the call is recorded as “ANSWERED”!

Asterisk Call Manager

It is based on a bash script which creates a call file and an extension in the dialplan. Basically when the system is started the script selects all users, starts calling (via call files) them one after another. This is very basic example of the 'reverse application manipulation'. Pre-setup: Before running through the core of this.