Summary:	ASTERISK-09715: Asterisk resets AMAflag if call being answered
Reporter:	Anders Kjærgaard Jørgensen (anjo03)	Labels:
Date Opened:	2007-06-20 08:45:18	Date Closed:	2007-06-22 10:22:47
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	We recently detected, that it seems like Asterisk is resetting the AMAflag to "default" when a call is being answered. If the caller or the called person hangs up before the call is being answered, Asterisk obey the "SetAMAFlag"-command and correct sets the AMAflag in the CDR. If the called persons picks up the phone, "default" (AMAflag 3) is always written to the CDR-record.
Comments:	By: Steve Murphy (murf) 2007-06-21 16:38:17 What kind of device is being answered? Sip? Zap? Skinny? let me know. I'll look thru all the channel drivers, but it's a bit of a chore. There's other places amaflags are set, and the mystery hopefully can solved quickly by starting with your channel driver... By: Steve Murphy (murf) 2007-06-21 17:19:28 Another question: are you using ForkCDR at all? the builtin app setAMAFlags()? Let me know. By: Steve Murphy (murf) 2007-06-21 17:22:59 Or, are you using Set(CDR(amaflags)=DOCUMENTATION) anywhere? Where? By: Steve Murphy (murf) 2007-06-21 17:52:28 A code review of the cdr_setamaflags() routine revealed a flaw; which I've fixed in 1.2 via svn v. 70948 in 1.4 via svn v. 70949 and in trunk   v. 70951 Basically, in a chained CDR set, all cdr's amaflags fields are set, irregardless of the fact that they may be LOCKED. So, if you do a ForkCDR(), and then set the amaflags, both the original and the new CDRs will get the amaflags set to the new value. This is not right, so I changed it. It may or may not solve your problem, we shall see I hope. By: Anders Kjærgaard Jørgensen (anjo03) 2007-06-22 02:48:23 The scenario is a SIP-device calling out on a Zap-channel. We are using "ResetCDR" instead of "ForkCDR", and using the SetAMAFlags-application. Here is a sample code, that shows the problem: exten => s,1,Noop exten => s,n,SetAMAFlags(billing) exten => s,n,Dial(Zap/g1/28111111) exten => s,n,SetAMAFlags(omit) exten => s,n,ResetCDR(w) exten => s,n,Hangup As you can see, the AMAFlag-field in the CDR should end up as either "1" (omit) or "2" (billing). And it does, if the Zap-channel does not answer. If he answers, that CDR shows 3 as AMAflag. This samplecode shows, that if you dont dial a channel, AMAflags are being written correctly: exten => s,1,Noop exten => s,n,SetAMAFlags(billing) exten => s,n,ResetCDR(w) exten => s,n,SetAMAFlags(documentation) exten => s,n,ResetCDR(w) exten => s,n,SetAMAFlags(default) exten => s,n,ResetCDR(w) exten => s,n,SetAMAFlags(omit) exten => s,n,ResetCDR(w) exten => s,n,Hangup Furthermore, I cant see the difference of the AMAflag, if you use "documentation" instead of "default"? How is "documentation" displayed in the CDR? By: Steve Murphy (murf) 2007-06-22 10:22:46 Excellent. That was just the info I needed. The problem was in the CDR merge code I added (of course!), which I should have suspected immediately. I've been able to reproduce the problem in my env, and made mods to the merge routine via 1.4 v. 71063, and trunk v. 71093. Reviewed the code to see if other fields were in a like situation, but did not think any others were. I'm closing this bug; if problems continue, re-open this bug, and we'll dig deeper. I tested it out here, and it looks to me like this is solved.