[Home]

Summary:ASTERISK-13225: Userfield not updating when the call is answered, if not answered it updates properly
Reporter:unservices (unservices)Labels:
Date Opened:2008-12-15 19:58:33.000-0600Date Closed:2009-04-29 08:37:20
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_cdr
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Have a call coming through a SIP trunk. Extensions.conf is on realtime mode, which goes to mysql extensions table and rings the SIP extension. At the same context of extensions.conf I also have the 'h' extension, so that a small script could run at the end to calculate the call cost after it's completed, storing in the userfield. The script is running on the 'h' extension with deadagi, so that it would allow to run after the call is hangup.

Since it was not working, I made it quite simple just storing the numbers 1234 in the userfield once the script runs, nothing else. If the call comes and the extension does not answer (no answer cdr result), the userfield gets updated. But if the extension answers the call, upon hangup the userfield simply does not get updated. Interesting to see is that with debug in the console I see the agi script setting up the userfield for 1234 as expected, but it never gets saved into the database. It seems that the script runs, but it's loosing the reference on where to update.

More interesting is that the same script / config runs with no problems with the asterisk version 1.2 - which I'm trying to update to 1.4.22 so that would have patches, better call quality, etc.

Obviously I have clonned the hard disk and am testing on a side server, so that the main one is not affected... But really want to solve this asap because the old box is giving me problems.

****** ADDITIONAL INFORMATION ******

Had initially a hard time because of the missing userfield=1 in the cdr_mysql.conf which was optional on the 1.2 version but now is mandatory. So now I have that in place (since it saves when no answer). Also eliminated an error on the log regarding the dbsocks by removing the comment from dbsock in the res_mysql.conf (again it seems that this was optional in the previous version).

Also I honestly didn't found a way to view/debug the SQL commands sent to update the cdr records. I've turned on the debug, and was able to see in the log the sql command for the sip peers, authenticating, updating the realtime info, etc but not for the cdr. Would really appreciate if something can be assisted also on this, so that future similar debugging could be easier.

Just as a side note, maybe nothing related to, the AGI scripts in the version 1.2 was connecting with the mysql (different machine) using a local dns name. On this version though I had to replace from the dns name with the direct IP address. Had also some problems with the cid record on the database, as that from the version 1.2 I get just the regular 10 digit cid saved, and with the version 1.4.22 I have been getting +1NPANXX format.
Comments:By: unservices (unservices) 2008-12-24 11:58:28.000-0600

Didn't heard anything back yet, just see that it's assigned to murf but don't see a way to contact him/her. Does anyone have any sugestions? Issue still continues, waiting to solve that so I can migrate a system from v1.2 into the new v1.4.
By: Steve Murphy (murf) 2009-01-07 16:05:04.000-0600

Sorry for the delay; Please attach the 'h' exten from your dialplan, minus, of course, any proprietary material it might contain... I want to see exactly how you are setting the userfield. I'll reproduce it on my machine and fix it.
I just don't want to waste time trying to reproduce it if you and I aren't on the same wavelength.



By: andrebarbosa (andrebarbosa) 2009-01-19 10:06:40.000-0600

I think I'm having the same problem:

I have a simple scenario: SIP phone A calls to SIP phone B

After the phone B answers, it presses a dtmf combination that will fire a dynamic feature that sets the accountcode and userfield

http://pastebin.com/m623123bf

[macro-projectcodes]
exten = s,1,Set(CDR(accountcode)="345")
exten = s,n,Set(CDR(userfield)="345")
exten = s,n,Verbose(${CDR(accountcode)})

After the application ran, I got this output:

ebox*CLI> show channel SIP/barbosa-0827d8f8
-- General --
          Name: SIP/barbosa-0827d8f8
          Type: SIP
      UniqueID: 1232380100.13
     Caller ID: 500
Caller ID Name: (N/A)
   DNID Digits: (N/A)
         State: Up (6)
         Rings: 0
 NativeFormats: 0x4 (ulaw)
   WriteFormat: 0x4 (ulaw)
    ReadFormat: 0x4 (ulaw)
WriteTranscode: No
 ReadTranscode: No
1st File Descriptor: 158
     Frames in: 7708
    Frames out: 7679
Time to Hangup: 0
  Elapsed Time: 0h2m35s
 Direct Bridge: SIP/504-b6b00c18
Indirect Bridge: SIP/504-b6b00c18
--   PBX   --
       Context: internal
     Extension:
      Priority: 1
    Call Group: 6
  Pickup Group: 14
   Application: AppDial
          Data: (Outgoing Line)
   Blocking in: ast_waitfor_nandfds
     Variables:
BRIDGEPEER=SIP/504-b6b00c18
MACRO_DEPTH=0
DIALEDPEERNUMBER=barbosa
SIPCALLID=3958626d050a6047383fa1a507195e7b@192.168.90.63

 CDR Variables:
level 1: dst=s
level 1: dcontext=internal
level 1: channel=SIP/barbosa-0827d8f8
level 1: lastapp=Verbose
level 1: lastdata=345
level 1: start=2009-01-19 15:48:20
level 1: answer=2009-01-19 15:48:21
level 1: duration=0
level 1: billsec=0
level 1: disposition=ANSWERED
level 1: amaflags=DOCUMENTATION
level 1: accountcode=345
level 1: uniqueid=1232380100.13
level 1: userfield=345

So, I think that the userfield and accountcode are correctly SET.

But, after I hangup the call, I got this cdr record:

"","504","500","internal","""504"" <504>","SIP/504-b6b00c18","SIP/barbosa-0827d8f8","Dial","SIP/barbosa|30|tThH","2009-01-19 15:48:19","2009-01-19 15:48:21","2009-01-19 15:51:00",161,159,"ANSWERED","DOCUMENTATION",""

Neither the accountcode or userfield are updated.

Also notice at the lastapp and lastappdata fields that are not updated.
By: andrebarbosa (andrebarbosa) 2009-01-23 10:07:41.000-0600

Any comments on this?

I can look at the code if you give me some pointers where to look :)
By: unservices (unservices) 2009-01-23 10:28:34.000-0600

Murf, sorry for the delay on my end also (was traveling)...

Anyhow, I have a very simple php script that runs after the call is completed to calculate the call cost and set into the userfield.

On the extensions.conf therefore is quite simple:

exten => h,1,DeadAGI(myscript.php)

On there I read the call values with phpagi (I've checked the values and they are all present) and then at the end I have something like:

 $agi->exec("Set CDR(userfield)=1234")

Which in turn does not set the value at all. I've tried exactly as described above adding a fake value 1234 and it does not get set at all.

It makes me wonder what's the difference from the script running between answering and not answering the call. If the call is answered then it does not update. If not answered, it updates.
By: saghul (saghul) 2009-01-27 06:22:20.000-0600

I can confirm it: if I set the userfield in the h extension it only gets updated when the call is not answered.


PS: Asterisk version: 1.4.21.1
By: Steve Murphy (murf) 2009-01-27 13:50:17.000-0600

OK, I'm using the latest 1.4 svn checkout. I'm a little more familiar with perl
agi, and have some example scripts (you didn't supply me with more than one line of your php agi script!). I got the perl environment together on my test machine, and ran the script in my hangup exten... and see the userfield in both answered and unanswered conditions. So, folks, please retest with the LATEST svn, because that's where a fix will be introduced.
By: Steve Murphy (murf) 2009-01-27 13:52:45.000-0600

I'm going to tentatively close this bug, as already fixed/unable to repro. If you can prove otherwise, then I need the AGI script in whatever language it's in, and how it's called from the h extensions.
By: unservices (unservices) 2009-01-30 07:56:22.000-0600

Murf, you can reproduce the issue by just having one line on the h extension like:

exten = h,1,Set(CDR(userfield)="1234")

The field would not be updated if the call is answered. If it's not answered, it would update as expected.

I will test the new svn this weekend as suggested, but in the meantime wanted to post here the note so that you can think about. Another two users (andrebarbosa & saghul) reported finding the same issue, so it's most likely not a local error but something in the code.
By: Steve Murphy (murf) 2009-02-06 17:45:33.000-0600

1. checkout the latest version of 1.4 from svn.
2. Test to see if this bug is still a problem.
3. If it is still not fixed, then get the latest patch from 13892 and apply it (patch -p0 < patch) and compile and test if it is fixed now.
4. report back soon. I'm anxious to commit this. My personal testing with this patch in place does not have this bug.
By: Antonio Gallo (agx) 2009-02-25 09:48:48.000-0600

I know you already told to test latest SVN; i just want to confirm you that with latest 1.4.23.1 the problem can be seen too: when the call is Answered the USERFIELD is empty; and only if its empty.

I don't have "h" extension i just:
1. dial outgoing calls
2. AGI: "SET VARIABLE "cdr(userfield)" "1234"
3. AGI: "SET VARIABLE "cdr(accountcode)" "1234"

accountcode is set to 1234 while userfield no;
By: Antonio Gallo (agx) 2009-02-25 11:04:18.000-0600

temporary dialplan workaround:

if DIALSTATUS is ANSWERED:

exten=>s,n,Set(CDR(mystuff)="1234")
exten=>s,n,ResetCDR(w)
exten=>s,n,NoCDR
exten=>s,n,Hangup
By: unservices (unservices) 2009-02-25 11:09:57.000-0600

Murf, problem persists after using latest version from svn. If it helps, I'm using the mysql cdr...It might be something wrong in the sql side...
By: Sverre G (sverre) 2009-02-25 17:54:23.000-0600

Sorry agx, but this results in 2 CDR records, the first one with all of the correct timing information, the second one with the userfield set but 0's for duration and billsec.

As much as I'm not testing on svn, i'm using 1.4.22, the problem exists in both CSV and MySQL. Doing a exten => s,1,Set(CDR(userfield)=1234) immediately before the dial command works fine, meanwhile a exten => h,1,Set(CDR(userfield)=1234) does not work. The CLI correctly reports the setting of the field, it just never makes it into the actual CDR.

I also tried endbeforehexten=yes and endbeforehexten=no in cdr.conf but it didn't help.
By: Denis Galvao (denisgalvao) 2009-03-03 09:22:17.000-0600

This bug is related to this one?
http://bugs.digium.com/view.php?id=14590
By: andrebarbosa (andrebarbosa) 2009-03-18 10:02:37

I did the test with last SVN (2009-03-19) with and without the ASTERISK-13064 patch, and the bug still happens on both setups.
By: Sverre G (sverre) 2009-03-18 20:02:19

It probably goes without saying that the workaround for now, if you're using a database driven CDR solution - is to use a DeadAGI script to update the database directly based on the uniqueid, channel, dstchannel or some combination thereof.
By: andrebarbosa (andrebarbosa) 2009-03-19 07:07:21

I'm using the workaround that agx suggested (thanks man!).

I've an [hangupedcalls] context,

exten = h,1,SET(TMPACCOUNTCODE=${SHARED(ACCOUNTCODE)})
exten = h,n,GotoIf($["${TMPACCOUNTCODE}" != ""]?accountcode)
exten = h,n,SET(TMPACCOUNTCODE=${SHARED(ACCOUNTCODE,${BRIDGEPEER})})
exten = h,n,GotoIf($["${TMPACCOUNTCODE}" != ""]?accountcode:exit)
exten = h,n(accountcode),Set(CDR(accountcode)=${TMPACCOUNTCODE})
exten = h,n(exit),Verbose(${CDR(accountcode)})
exten = h,n,ResetCDR(w)
exten = h,n,NoCDR
exten = h,n,Hangup

I also have to use SHARED variables, because in my scenario, AccountCode can be written either by the caller or callee.

Using asterisk 1.23.1 with func shared ported by Tilghman
By: Sverre G (sverre) 2009-03-19 07:37:27

If it works for you and agx great, but I found that using ResetCDR(w) followed by NoCDR didn't allow me to set the USERFIELD. You seem to be setting the accountcode - maybe that's the difference. Either way, this bug is about the userfield, so try giving it a shot with USERFIELD and see how you go.
By: Matt Riddell (zx81) 2009-03-19 17:54:47

How is this ready for testing when it has no patch?
By: Sverre G (sverre) 2009-03-19 19:00:50

Back on Feb 6, murf said:

3. If it is still not fixed, then get the latest patch from 13892 and apply it (patch -p0 < patch) and compile and test if it is fixed now.
4. report back soon. I'm anxious to commit this. My personal testing with this patch in place does not have this bug.

So far as I can tell, noone has tested this problem with this patch yet - other than murf. Hence ready for testing.
By: andrebarbosa (andrebarbosa) 2009-03-20 05:53:12

sverre, I tested the same work-around for userfield and it also worked :)

exten = h,1,SET(TMPACCOUNTCODE=${SHARED(ACCOUNTCODE)})
exten = h,n,GotoIf($["${TMPACCOUNTCODE}" != ""]?accountcode)
exten = h,n,SET(TMPACCOUNTCODE=${SHARED(ACCOUNTCODE,${BRIDGEPEER})})
exten = h,n,GotoIf($["${TMPACCOUNTCODE}" != ""]?accountcode:exit)
exten = h,n(accountcode),Set(CDR(userfield)=${TMPACCOUNTCODE})
exten = h,n(exit),Verbose(${CDR(userfield)})
exten = h,n,ResetCDR(w)
exten = h,n,NoCDR
exten = h,n,Hangup

Here is the cdr record on Master.csv

"","500","555","internal","""barbosa"" <500>","SIP/barbosa-b756ed30","SIP/marco2-0824f2d0","Dial","SIP/marco2|30|tThH","2009-03-20 11:01:57","2009-03-20 11:02:02","2009-03-20 11:02:14",17,12,"ANSWERED","DOCUMENTATION","1237546917.10","456"

The tests I did with SVN with\without murf patch, I did for both accountcode and userfield, and both of them failed.
By: Sverre G (sverre) 2009-03-20 08:27:37

OK, so we have a successful workaround, but this bug should be changed from ready for testing, because the murf patch on the latest SVN doesn't work.

Is this something that should be addressed when CDR's are reworked in bug http://bugs.digium.com/view.php?id=11849 - where lmadson said "I'm updating this by marking this issue as targeted for 1.4.25 just so we have an end goal for what 1.4.25 might contain, but this may change as we move forward."?
By: unservices (unservices) 2009-03-20 11:34:52

I've tested again with the patch and continues to fail.

Sounds that workaround is not a good solution because it is implemented through extensions.conf whereas in our case we would use the values from an agi/php script.

As stated on the beginning, in our case the php script calculates and puts a cost in the call record after the call is completed. Really hard to do with static coding on extensions.conf (query db, etc).

In fact, I believe the userfield is used by everyone to store dynamic information that result from calculations.

IMO, the issue should remain open pending solution. If there is a rework of the CDR, it might be linked to it. There are details on this issue along with attempts made that could be helpful in the rework.


By: Matthew Nicholson (mnicholson) 2009-04-20 17:15:09

I cannot reproduce this on the latest asterisk 1.4 svn (r189465).  This is how I tested.

extensions.conf:
[default]
exten => 200,1,Noop
exten => 200,n,Busy

exten => 300,1,Noop
exten => 300,n,Answer
exten => 300,n,Wait(2)
exten => 300,n,Hangup

exten => 400,1,Noop
exten => 400,n,Dial(sip/test2)
exten => 400,n,Hangup

exten => h,1,Set(CDR(userfield)=userfield)


I tested by dialing 200, 300, and 400 from test1.  When dialing 400, I answered test2.  In all cases userfield was properly written to Master.csv.

How do you reproduce this bug and are you able to reproduce it with the cdr_csv.so backend?
By: Matt Riddell (zx81) 2009-04-22 16:06:42

You could possibly try using call files or manager originate - I know some people were having problems in that area
By: Matthew Nicholson (mnicholson) 2009-04-27 14:56:32

Testing with originate worked fine as well.  I still cannot reproduce this bug.  If no objects, I will be closing this soon.
By: Matt Riddell (zx81) 2009-04-27 16:25:20

Can you hold it open for another day - I'll get someone in the office to confirm that an upgrade to latest 1.4 resolves the issue.  Thanks
By: Sverre G (sverre) 2009-04-27 17:58:02

I'll test this afternoon (in 7-8 hours) and let you know also.
By: Sverre G (sverre) 2009-04-28 20:34:17

I can confirm that the problem is fixed in SVN-branch-1.4-r190721.

Do we know what the difference is between 1.4.22 (or maybe later versions but I didn't test) and SVN that might have fixed it? What major release would we expect to see the fix?
By: Matthew Nicholson (mnicholson) 2009-04-29 08:35:57

This will be fixed in the next major release (1.4.25).