We tried that, as follows:
action: originate
channel: SIP/MyTrunk/00441234567890
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/00441234567890
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” <9998>
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 __ast_pbx_run: Channel ‘SIP/9999-00000002’ 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”!