[Home]

Summary:ASTERISK-17095: [patch] CDR(billsec) is not inserted properly for unanswered calls
Reporter:Josep Casals C (joscas)Labels:
Date Opened:2010-12-11 13:44:16.000-0600Date Closed:2011-05-06 12:50:17
Priority:MinorRegression?No
Status:Closed/CompleteComponents:CDR/cdr_pgsql
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20101215__issue18460.diff.txt
Description:CDR(billsec) is not inserted properly for high resolution CDRs. When CDR(billsec)=0 it attempts to insert a huge value instead of 0.

From postgresql-8.3-main.log (obfuscated a bit to hide personal data) I can see that it attempts to insert '1292094492.137196' instead of '0'. More strangely, the billsec number that it attempts to insert looks very similar to the UNIQUEID
___________
2010-12-11 19:08:12 UTC ERROR:  numeric field overflow
2010-12-11 19:08:12 UTC DETAIL:  A field with precision 14, scale 6 must round to an absolute value less than 10^8.
2010-12-11 19:08:12 UTC STATEMENT:  INSERT INTO cdr ("clidnum","clidname","dialednum","calldate","answer","callend","duration","billsec","disposition","uniqueid","sequence") VALUES (,,,,'2010-12-11 20:08:12','2010-12-11 20:08:12','2010-12-11 20:08:12','0.029349','1292094492.137196','NO ANSWER','arcas-1292094492.13',0)

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

--
-- PostgreSQL database dump
--

-- Dumped from database version 8.3.12
-- Dumped by pg_dump version 9.0.1
-- Started on 2010-11-26 14:21:47 CET

SET statement_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET check_function_bodies = false;
SET client_min_messages = warning;
SET escape_string_warning = off;

SET search_path = public, pg_catalog;

SET default_tablespace = '';

SET default_with_oids = false;

--
-- TOC entry 1462 (class 1259 OID 16387)
-- Dependencies: 3
-- Name: cdr; Type: TABLE; Schema: public; Owner: asterisk; Tablespace:
--

CREATE TABLE cdr (
   id bigserial PRIMARY KEY,
   clidnum character varying(80),
   clidname character varying(80),
   dialednum character varying(80),
   calldate timestamp with time zone,
   answer timestamp with time zone,
   callend timestamp with time zone,
   duration numeric(14,6),
   billsec numeric(14,6),
   disposition character varying(45),
   uniqueid character varying(32),
   sequence integer
);


ALTER TABLE public.cdr OWNER TO asterisk;

--
-- TOC entry 1733 (class 0 OID 0)
-- Dependencies: 3
-- Name: public; Type: ACL; Schema: -; Owner: postgres
--

REVOKE ALL ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM postgres;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO PUBLIC;


-- Completed on 2010-11-26 14:21:49 CET

--
-- PostgreSQL database dump complete
--
Comments:By: Josep Casals C (joscas) 2010-12-11 13:48:35.000-0600

This issue could be related to issue 18407 where CDR(end) is not inserted.

By: snuffy (snuffy) 2010-12-13 05:02:22.000-0600

Is there such a problem for 'non-hires' cdr's?
Also could you check against a different backend.. say 'cdr_custom'



By: Josep Casals C (joscas) 2010-12-13 06:02:33.000-0600

I've checked with non-hires CDRs and I've found that there is exactly the same problem. It appears that the problem is not linked to high-res CDRs.

I've also checked that CDRs are written correctly for cdr_custom.

By: Tilghman Lesher (tilghman) 2010-12-15 14:14:11.000-0600

Patch uploaded.  Please patch and verify that it works for you.

By: Josep Casals C (joscas) 2010-12-20 04:36:39.000-0600

The patch has solved the problem in my test environment. Thanks.

By: Digium Subversion (svnbot) 2010-12-20 11:41:25.000-0600

Repository: asterisk
Revision: 299130

U   branches/1.6.2/cdr/cdr_pgsql.c

------------------------------------------------------------------------
r299130 | tilghman | 2010-12-20 11:41:24 -0600 (Mon, 20 Dec 2010) | 11 lines

If a call was not answered, then the billsec was calculated unusually large.

Also, due to a copy and paste error, a request for the answer field would have
given the start value, instead.

(closes issue ASTERISK-17095)
Reported by: joscas
Patches:
      20101215__issue18460.diff.txt uploaded by tilghman (license 14)
Tested by: joscas

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=299130

By: Digium Subversion (svnbot) 2010-12-20 11:47:11.000-0600

Repository: asterisk
Revision: 299131

_U  branches/1.8/
U   branches/1.8/cdr/cdr_pgsql.c

------------------------------------------------------------------------
r299131 | tilghman | 2010-12-20 11:47:10 -0600 (Mon, 20 Dec 2010) | 18 lines

Merged revisions 299130 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

........
 r299130 | tilghman | 2010-12-20 11:41:24 -0600 (Mon, 20 Dec 2010) | 11 lines
 
 If a call was not answered, then the billsec was calculated unusually large.
 
 Also, due to a copy and paste error, a request for the answer field would have
 given the start value, instead.
 
 (closes issue ASTERISK-17095)
  Reported by: joscas
  Patches:
        20101215__issue18460.diff.txt uploaded by tilghman (license 14)
  Tested by: joscas
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=299131

By: Digium Subversion (svnbot) 2010-12-20 11:48:10.000-0600

Repository: asterisk
Revision: 299132

_U  trunk/
U   trunk/cdr/cdr_pgsql.c

------------------------------------------------------------------------
r299132 | tilghman | 2010-12-20 11:48:09 -0600 (Mon, 20 Dec 2010) | 25 lines

Merged revisions 299131 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r299131 | tilghman | 2010-12-20 11:47:10 -0600 (Mon, 20 Dec 2010) | 18 lines
 
 Merged revisions 299130 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ........
   r299130 | tilghman | 2010-12-20 11:41:24 -0600 (Mon, 20 Dec 2010) | 11 lines
   
   If a call was not answered, then the billsec was calculated unusually large.
   
   Also, due to a copy and paste error, a request for the answer field would have
   given the start value, instead.
   
   (closes issue ASTERISK-17095)
    Reported by: joscas
    Patches:
          20101215__issue18460.diff.txt uploaded by tilghman (license 14)
    Tested by: joscas
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=299132