Summary:	ASTERISK-16923: CDR fields not written after call is bridged
Reporter:	pjois (pjois)	Labels:
Date Opened:	2010-11-05 16:09:53	Date Closed:	2012-02-07 16:25:43.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	CDR/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I'm finding that writing to CDR writeable fields (userfield, accountcode, amaflags, [custom field]) does not work after a call goes to DIAL.  This can be confirmed in two ways.  One is to execute the following: [extensions] exten => 1234,1,NOOP exten => 1234,n,DIAL(SIP/someguy,10,g) exten => 1234,n,SET(CDR(userfield)=test) This does not set the userfield to "test" as expected when SIP/someguy hangs up. The other method to verify this is to execute the following: [extensions] exten => 1234,1,NOOP exten => 1234,n,DIAL(SIP/someguy) SIP/someguy keeps the call alive, and from the manager interface, issue the following: Action: Setvar Channel: SIP/myphone-00000074 Variable: CDR(userfield) Value: test Again, the command returns success, but the userfield remains blank. However, if you issue the command before the call gets to DIAL, then the userfield is written as expected. For example, the following works perfectly: [extensions] exten => 1234,1,NOOP exten => 1234,n,SET(CDR(userfield)=test) exten => 1234,n,DIAL(SIP/someguy) This seems like an issue with DIAL specifically because using something like WAIT does not result in this problem: [extensions] exten => 1234,1,NOOP exten => 1234,n,WAIT(1) exten => 1234,n,SET(CDR(userfield)=test)
Comments:	By: Leif Madsen (lmadsen) 2010-11-30 08:05:21.000-0600 My gut instinct would be that I would not expect this to work. I can't really give a great reason why, but on the first example you're in the process of tearing down the call, so I'm not sure that modifying the CDRs are appropriate there. In the other example the call is in progress, so again, I'm not sure it makes sense to me that the CDR should be modified there. However, I'm going to mark this as acknowledged so that another developer can look at this to review and determine how we should deal with this scenario. By: David Woolley (davidw) 2010-12-08 06:23:16.000-0600 The application write to the channel CDR, but that has already been copied to the bridge CDR and it is the bridge CDR that will eventually be output. We did some trickery with h extensions to get userfields updated in this sort of situation. By: Terry Wilson (twilson) 2012-02-07 16:25:43.373-0600 CDRs are posted when the bridge between two channels is torn down. For Dial(), this will happen when one party hangs up. You cannot alter the CDRs after this point. This is something that will never change with CDRs. If different behavior is required, you will have to look into using CEL.