Here is some detail on how the ‘g’ option breaks custom CDR variables. Currently the LD part of the dialplan looks like this (before I add the ‘g’), without adding any code to determine release direction:
[long_distance]
; LD
exten => _91XXXXXXXXXX!,1,Dial(${PRI}/${EXTEN:1})
exten => _91XXXXXXXXXX!,n,Hangup()
; on hangup, record the cause code
exten => h,1,Set(CDR(causecode)=${HANGUPCAUSE})
exten => h,n,Set(CDR(dialstatus)=${DIALSTATUS})
Our CDR’s then store the HANGUPCAUSE and DIALSTATUS variables in addition to the rest of the CDR data that is always saved.
Asterisk output on call hangup before adding ‘g’
-- Executing [h@supervisor:1] Set("SIP/RCA1091-0000000f", "CDR(causecode)=16") in new stack
-- Executing [h@supervisor:2] Set("SIP/RCA1091-0000000f", "CDR(dialstatus)=ANSWER") in new stack
CDR output before adding 'g’
End = 2012-08-30 06:21:41
Result = ANSWER
Cause Code = 16
Duration = 12
Billable = 9
If I add the ‘g’ option so that I can determine the release direction, then the CDR’s no longer record the values I set in the ‘h’ extension. I show them being set in the console output, but they are not added to the CDR.
Asterisk console output after adding ‘g’:
-- Executing [h@supervisor:1] Set("SIP/RCA1091-0000000d", "CDR(causecode)=16") in new stack
-- Executing [h@supervisor:2] Set("SIP/RCA1091-0000000d", "CDR(dialstatus)=ANSWER") in new stack
CDR result after adding 'g’
End = 2012-08-30 06:33:27
Result =
Cause Code = 0
Duration = 6
Billable = 2