[Asterisk-Users] re: Asterisk CDR & UniqueID

Freddi Hansen fh at danovation.dk
Mon Jul 26 01:29:41 MST 2004


> Hey All,
>
> We are running a small SIP/IAX termination service at the moment
> (planning on growing it) with 2 asterisk machines. One terminates the
> SIP/IAX calls from our customers and one is our gateway to our upstream
> provider. Both machines are logging CDR data to the same postgres table
> using the cdr_psql module.
>
> The problem I am having is I'm trying to work out how to link the CDR
> records into a single 'call stream', rather than having separate records
> per machine the call passes through.
>
> Reading around on the Wiki and doing a bit of googling, I've worked out
> that what I'm trying to do is the "normalization" step of "CDR
> mediation", but I have not been able to find out any specifics about how
> to go about it.
>
> I would have thought that the originating asterisk machine would
> generate the UniqueID for the call (Message-ID in SMTP terms) and pass
> that along the call path, but each machine is using the epoch timestamp
> of when it sees (or records, not sure which) of the call.
>
> I know I can use the NoCDR app on the first machine in the chain, but
> that does not scale if we need to add more machines to our network.
>
> Does:
> a) anyone have any idea of what I'm trying to explain, and
> b) have any pointers of where I can find more information about doing 
> this?
>
> Thanks
> Darryl 


Hi,
I had the same problem. One solution is to include the ip-adr or uname 
of the gateway that serves the call, then you can have a true unique-id.
I did patch cdrcsv.c to include an exstra field which is the uname of my 
* server. Another possible way today is to use the 'SetCDRUserField'
to let the 'uname' into your  cdrstream.  For DB scaling issues I would 
recommend that you to use a 'global unique' table to convert your uname
to an integer so you dont get something like a char(32) in your DB key.
Freddi




More information about the asterisk-users mailing list