[asterisk-dev] No unique identifier for CDR

[Nick Lewis]

Atis

Thanks for describing the good work that is underway on CDR

Regarding call_id, I am personally more concerned with distinguishing
parts of a call than associating them. For call monitor recordings the
system needs to be able restrict parties to reviewing only the parts of
a call in which they participated. For example if a receptionist
transfers a call to a CEO, the receptionist should not have access to
the recording of the part of the call after the transfer. Only with a
unique cdr identifier can this be restricted. (I appreciate the need to
associate parts of a call with different channels from a call logging
point of view though).

I do not think that having a ResetCDR(w) increment held in a dialplan
global variable comes to quite the same thing as a native CDR field. I
feel that a CDR row should be able to be uniquely identified without
recourse to application specific data such as the userfield. This is
because a row id is something fundamental to the management of a data
structure. Only by automating the generation of a row id within cdr.c
can this be assured.

If my proposed uniqueid + cdrinstance identifier for a CDR row is too
focused on channels then how about a genuine atomic row id such as
"cdrid" that is lock generated for every post_cdr (or batch equivalent)?

Best Regards
Nick

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Atis Lezdins
Sent: 26 August 2009 21:29
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] No unique identifier for CDR

On Wed, Aug 26, 2009 at 6:31 PM, Nick Lewis<Nick.Lewis at atltelecom.com>
wrote:
> I have come up against a problem that there is no unique identifier
for
> a CDR. This makes it difficult to associate other things such as call
> monitor recordings with a CDR.
> Each call does have a unique identifier which is stored in the CDR as
> "uniqueid" but there may be multiple CDRs representing one call. For
> example ResetCDR(w) saves a CDR and creates a new one for the call.
Both
> CDR have the same "uniqueid".
>
> I propose a new read-only CDR field named something like "cdrinstance"
> that automatically increments after a ResetCDR(w) command. This can be
> used in conjunction with the "uniqueid" field to form a unique CDR
> identifier.
>
> Do you agree that the lack of a unique identifier for a CDR is a
> problem. If so what do you think of my proposed approach for a
solution?
>
> https://issues.asterisk.org/view.php?id=15180

Actually, uniqueid represents unique channel, but there might be many
of them in a call.

There is linkedid field and variable in trunk, and You can expect them
in 1.6.3 releases which is not that close.

What I have done is at beginning of each call initialize an inherited
variable:

if ("${call_id}"=="") {
  Set(__call_id=${UNIQUEID});
}

so that it stays always the same for duration of call. It will be
repaced by linkedid when that release comes.

As for incremented variable - i have it too in a macro that calls
ResetCDR(w). However You also have to set it global, and if You're
updating it in a child channel, You have to use database (built-in or
some SQL) so that it's passed to parent channel.

Then it's quite easy to append that variable to CDR userfield after
each ResetCDR(w) or whenever new channel is created. However You can't
set variables for completely all CDR's, as there are some channels
that never execute dialplan. For me this is enough, i just delete
CDR's with empty userfield - they are basically some internal mirrors
of actual "dialplan executing" channels.

Regards,
Atis



-- 
Atis Lezdins,
VoIP Project Manager / Developer,
IQ Labs Inc,
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2009 - October 13 - 15 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

______________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
______________________________________________________________________

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre.
_____________________________________________________________________
Disclaimer of Liability
ATL Telecom Ltd shall not be held liable for any improper or incorrect use of the  information described and/or contained herein and assumes no responsibility for anyones use  of the information. In no event shall ATL Telecom Ltd be liable for any direct, indirect,  incidental, special, exemplary, or consequential damages (including, but not limited to,  procurement or substitute goods or services; loss of use, data, or profits; or business  interruption) however caused and on any theory of liability, whether in contract, strict  liability, or tort (including negligence or otherwise) arising in any way out of the use of  this system, even if advised of the possibility of such damage.

Registered Office: ATL Telecom Ltd, Fountain Lane, St. Mellons Cardiff, CF3 0FB
Registered in Wales Number 4335781

All goods and services supplied by ATL Telecom Ltd are supplied subject to ATL Telecom Ltd standard terms and conditions, available upon request.