Summary:ASTERISK-19165: Empty CDR userfield and wrong UniqueID values stored in Master.csv when using Originate from AMI
Reporter:Alex (alexrixhardson)Labels:
Date Opened:2012-01-04 07:10:20.000-0600Date Closed:2018-01-02 08:44:20.000-0600
Versions: Frequency of
Description:When originating calls using AMI, CDR userfield isn't set for the second leg. Also invalid call UniqueId is stored in the CDR.

The problem can be reproduced in the following way:

1. connect two SIP softphones to Asterisk (let's say phone1 and phone2),

2. add this dialplan:

exten => _X.,1,Set(CDR(userfield)=test)
exten => _X.,n,Dial(SIP/phone1)

exten => _X.,1,Verbose(My uniqueid is ${UNIQUEID})
exten => _X.,n,Set(CDR(userfield)=test)
exten => _X.,n,Dial(SIP/phone2)

3. execute this action via AMI:
action: originate
channel: Local/123@test-firstleg
context: test-secondleg
exten: 123
priority: 1

The CDR record in Master.csv for the second leg will not contain userfield value "test" (userfield will be empty). UniqueId value stored in CDR record will be different than the one printed out by "Verbose(My uniqueid is ${UNIQUEID})" in dialplan.

Could you please advice how to avoid these two issues?
Comments:By: Alex (alexrixhardson) 2012-01-23 14:48:59.000-0600

Anything new on this issue?

By: Joshua C. Colp (jcolp) 2017-12-19 06:21:38.312-0600

CDR support has been completely rewritten in Asterisk 13. Do you still experience this problem there?

By: Asterisk Team (asteriskteam) 2018-01-02 08:44:21.003-0600

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines