[Home]

Summary:ASTERISK-09416: zero billsec in mysql db
Reporter:Reynan (villkram)Labels:
Date Opened:2007-05-09 23:20:25Date Closed:2007-06-22 15:21:03
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Astersisk log zero billing seconds in the cdr database using manager cli action, Originate. In /etc/asterisk dir, cdr.conf was configured to not to stop at extension "h". cdr modules: cdr_addon_mysql.so, dr_custom.so, cdr_manager.so,     cdr.


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

Originate function was done in php having this portion:
fputs($socket, "Action: originate\r\n");
fputs($socket, "Exten: $prefix_num$target\r\n");
fputs($socket, "Context: outgoing\r\n");
fputs($socket, "Channel: SIP/$tm_extension\r\n");
fputs($socket, "Account: $unique_id\r\n");
fputs($socket, "Variable: mydialid=$dialid\r\n");
fputs($socket, "Priority: 1\r\n\r\n");
fputs($socket, "Action: Logoff\r\n\r\n");

Comments:By: Reynan (villkram) 2007-05-09 23:46:43

manually dialing the number on the phone gives the correct billsec result in the cdr databse.
By: Tilghman Lesher (tilghman) 2007-05-10 02:50:12

Please upload the contents of your extensions.conf.  I suspect you're not calling Answer(), which is what starts the timer for billsec.
By: Reynan (villkram) 2007-05-10 18:42:55

I do call 'Answer' in one of the context in my dialplan. This problems arise when i upgrade my asterisk server to 1.4.2, copied my previous configurations to /etc/asterisk/ . I have enocuntered no problem when i was using verion 1.2.14, cdr variables, especially the 'billsec' is being log correctly, if i am to manually dial a number in a phone, or if i am to use the Originate action.
By: Joshua C. Colp (jcolp) 2007-05-14 11:46:04

Please also upload the console output.
By: Reynan (villkram) 2007-05-15 16:56:00

ORIGINATE A CALL USING SIP/201
using cli command: show channels
===================================================

Asterisk Call Manager/1.0
Response: Success
Message: Authentication accepted

Response: Follows
Privilege: Command
Channel              Location             State   Application(Data)            
SIP/201-0a11b8d8     (None)               Up      Bridged Call(SIP/201-0a118488)
SIP/201-0a118488     201@outgoing:1       Up      Dial(SIP/201|60|tr)          
2 active channels
1 active call
--END COMMAND--

Response: Goodbye
Message: Thanks for all the fis


SRC CHANNEL DETAILS
suing cli command: show channel SIP/201-0a11b8d8
==================================================


Asterisk Call Manager/1.0
Response: Success
Message: Authentication accepted

Response: Follows
Privilege: Command
-- General --
          Name: SIP/201-0a11b8d8
          Type: SIP
      UniqueID: 1179264768.40
     Caller ID: 201
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: 26
     Frames in: 5305
    Frames out: 0
Time to Hangup: 0
  Elapsed Time: N/A
 Direct Bridge: SIP/201-0a118488
Indirect Bridge: SIP/201-0a118488
--   PBX   --
       Context: outgoing
     Extension:
      Priority: 1
    Call Group: 0
  Pickup Group: 0
   Application: Bridged Call
          Data: SIP/201-0a118488
   Blocking in: ast_waitfor_nandfds
     Variables:
BRIDGEPEER=SIP/201-0a118488
DIALEDPEERNUMBER=201
SIPCALLID=07feb5ff404b3af65f79f93d7dc75acf@192.168.50.53

--END COMMAND--

Response: Goodbye
Message: Thanks for all the fish.


DST CHANNEL DETAILS
suing cli command: show channel SIP/201-0a118488
==================================================


Asterisk Call Manager/1.0
Response: Success
Message: Authentication accepted

Response: Follows
Privilege: Command
-- General --
          Name: SIP/201-0a118488
          Type: SIP
      UniqueID: 1179264764.39
     Caller ID: (N/A)
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: 27
     Frames in: 323
    Frames out: 7199
Time to Hangup: 0
  Elapsed Time: 0h2m24s
 Direct Bridge: SIP/201-0a11b8d8
Indirect Bridge: SIP/201-0a11b8d8
--   PBX   --
       Context: outgoing
     Extension: 201
      Priority: 1
    Call Group: 0
  Pickup Group: 0
   Application: Dial
          Data: SIP/201|60|tr
   Blocking in: ast_waitfor_nandfds
     Variables:
BRIDGEPEER=SIP/201-0a11b8d8
DIALEDPEERNUMBER=201
DIALEDPEERNAME=SIP/201-0a11b8d8
mydialid=reynan
SIPCALLID=385d0dc94060a79a1c4a4059350c85d7@192.168.50.53

 CDR Variables:
level 1: dst=201
level 1: dcontext=outgoing
level 1: channel=SIP/201-0a118488
level 1: dstchannel=SIP/201-0a11b8d8
level 1: lastapp=Dial
level 1: lastdata=SIP/201|60|tr
level 1: start=2007-05-16 05:32:48
level 1: answer=2007-05-16 05:32:48
level 1: end=2007-05-16 05:32:48
level 1: duration=0
level 1: billsec=0
level 1: disposition=ANSWERED
level 1: amaflags=DOCUMENTATION
level 1: accountcode=117926476442148200
level 1: uniqueid=1179264764.39

--END COMMAND--

Response: Goodbye
Message: Thanks for all the fish.



CDR entries on database
after i hangup the phone
===============================================

cdrid = 17470656
uniqueid = 1179264764.39
userfield =
accountcode = 117926476442148200
src =
dst = 201
dcontext = outgoing
clid =
channel = SIP/201-0a118488
dstchannel = SIP/201-0a11b8d8
lastapp = Hangup
lastdata =
calldate = 2007-05-16 05:32:48
duaration = 270
billsec = 0
disposition = ANSWERED
amaflags = 3


By: Steve Murphy (murf) 2007-05-17 11:20:09

OK, I'm going to investigate this today. I hope to lab it up and see what's happening. My initial suspicion is that the ast_cdr_end() routine isn't being called, because, if memory serves me correctly, that is where the billsec and duration are calculated. We shall see.
By: Steve Murphy (murf) 2007-05-17 13:45:41

I just labbed this up on the svn 1.4 version, and the billsec looks OK. There has been considerable updates and improvements to CDR code since 1.4.2; can you update to something a little more "modern" ?


By: Arnd Schmitter (arnd) 2007-05-21 06:34:33

Hello

I've encountered the same Problem with Version 1.4.2, but with some additional Problems:

the fields "clid" and "src" are filled with data from a previous call.

I 've now updated to 1.4.4 and the Problem with the empty answeretime has gone, but the Problem with the clid and src Fields continue to exists.
By: Steve Murphy (murf) 2007-06-22 15:21:01

OK, I've spent a few hours reproducing this both on 1.4 and in my team/murf/CDRfix5 branch; As far as the clid is concerned, it appears you can set the clid that appears in the CDR via a CallerID: line in your callfile/originate. I would assume that
As to the Source, in both cases, it is empty for me.

Please check this out once again with the latest 1.4 svn. If you still see src and clid fields being random stuff, or stuff from previous commands, re-open and I'll dig deeper. I may need some help reproducing this. Please supply examples that involve call files, as this is easier to reproduce at my end.