[asterisk-dev] Possible Call Event Logging (CEL) Bugs

[Steve Murphy]

Nic--

Before diving into databasing the CEL events, I would suggest that you log
all events to a
text log file first, and then get a feel for the data you are going to
database. Then, after
that, I'd map out the queries you are going to need to do to get the
information you want.

Originally, I provided the same backends that CDR records have, but the
first implementation
based on CEL did not use any database, as the queries necessary to pick out
the information
desired were either impossible or impractically complex. It pulled the data
it needed directly
from the event list itself.

So, I'm interested in how you go about using CEL. I've offered to do a
CEL->CDR converter
before, but no-one seemed interested in actually having to pay something to
get a CDR
based system that actually works in the face of transfers, parking, etc.
And, if no-one
is willing to pay to get a job done, the job ain't worth doing.

murf


On Mon, Dec 28, 2009 at 9:58 AM, Nic Colledge <nic at njcolledge.net> wrote:

>  Hi,
>
>
>
> I’ve been playing around with CEL in asterisk trunk (SVN-Trunk-r236144) and
> have found some strange behaviour and am wondering if these are bugs.
>
>
>
> I have the CEL table in a postgreSQL database the layout of which was taken
> from the cel_pgsql.conf file. I also added a “id” serial to use a primary
> key. The SQL create statement is included below.
>
>
>
> CREATE TABLE cel
>
> (
>
>   uniqueid character varying(150) NOT NULL,
>
>   linkedid character varying(150) NOT NULL,
>
>   eventtime timestamp with time zone NOT NULL,
>
>   eventtype integer NOT NULL,
>
>   userdeftype character varying(100),
>
>   cid_name character varying(100),
>
>   cid_num character varying(100),
>
>   cid_ani character varying(100),
>
>   cid_rdnis character varying(100),
>
>   cid_dnid character varying(100),
>
>   exten character varying(100),
>
>   context character varying(100),
>
>   channame character varying(100),
>
>   appname character varying(100),
>
>   appdata character varying(200),
>
>   accountcode character varying(100),
>
>   peeraccount character varying(100),
>
>   amaflag integer,
>
>   userfield character varying(100),
>
>   peer character varying(100),
>
>   id serial NOT NULL
>
> )
>
> WITH (
>
>   OIDS=FALSE
>
> );
>
>
>
> Anyway, when I use cel_pgsql.conf to connect to the database the “id” is
> always set to zero (which when it were a primary key caused a violation and
> made errors to that effect show up in the asterisk console).
>
>
>
> Ok, so not the end of the world, I tried cel_adaptive_odbc.conf. Here the
> “id” serial is always set correctly by the database, but the following
> errors show up in the asterisk console:
>
> [Dec 28 16:30:38] WARNING[1416]: cel_adaptive_odbc.c:574 odbc_log: CEL
> variable amaflag is not an integer.
>
> [Dec 28 16:30:38] WARNING[1416]: cel_adaptive_odbc.c:574 odbc_log: CEL
> variable id is not an integer.
>
>
>
> Any idea what’s going on here? I’m working under the assumption that
> amaflag should be an int because the cel_pgsql.conf file comments say
> “amaflag (an int)”.
>
>
>
> Is there any way to make the pgsql backend ignore the ID (serial) column so
> that the database will sort its value out properly?
>
> What are these other two errors from the adaptive ODBC backend?
>
>
>
> I think it makes sense to have a primary key on this table, unless I’m
> missing something obvious I don’t think one can be made from the other
> columns, can it?
>
> Maybe it would be better to have asterisk make a extra field so that
> uniqueid + [somthing extra] can be used as a primary key? Of course I’m
> assuming it’s not possible to use something that already exists when I
> suggest this.
>
>
>
> Thanks in advance.
>
>
>
> Regards,
>
> Nic Colledge
>
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
Steve Murphy
ParseTree Corp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20091230/c31da618/attachment.htm