[asterisk-users] CDR Design

Grey Man greymanvoip at gmail.com
Tue Dec 2 09:01:39 CST 2008


>On Mon, Dec 1, 2008 at 3:26 PM, Steve Murphy <murf at digium.com> wrote:
> Everyone--
>
> I've just made some major changes to the CDRfix2.rfc.txt
> file in http://svn.digium.com/svn/asterisk/team/murf/RFCs
> to accommodate the Leg approach instead of a
> channel-based approach.
>

Hi murf,

I've got a couple of points (as always) from the new design.

First one would be the generation of CDRs when putting a call on hold.
I don't think that should occur. When a call is put on hold Asterisk
never changes the endpoints of a call all it does is possibly change
the media to one or both of the call ends. CDRs are about call
endpoints not about media transitions. In SIP terms putting a call on
hold is no different to changing codecs both operations are re-INVITES
and are irrelevant as far as CDRs and billing go.

As far as internal calls vs external calls go I would argue that
Asterisk can distinguish between them. Any call initiated with the
Dial (or equivalent) app is an outgoing call. Anything call request
arriving at Asterisk from the outside World is an internal call. For a
standard call from a SIP user there are two call legs; the incoming
call leg to Asterisk and the outgoing call from the dialplan. For a
DAHDI user there is only a single call leg being the outgoing call
from the dialplan since providing dialtone when they pick up the phone
is not a call leg. I guess it's not really relevant for the CDR design
but it's actually not a difficult thing to cope with when writing a
billing engine for Asterisk, I know as I've done it.

I like the new CDR fields. My number one concern would be to get the
CDRs accurate but additional useful information can only help as long
as it used the right way, i.e. not treated as definitive for billing
purposes.

For the linkedid and ideally the uniqueid I reaally think it would be
vastly more useful to use a GUID or UUID rather than a incrementing
sort of unique id. A lot of use are dealing with CDRs by writing them
to databases and it would greatly simplify and improve the robustness
of billing if Asterisk CDRs could be categorically be indentified as
unique. If we need to know which CDR came first we can use the
calldate ther is no need for the linkedid or uniqueid to double up for
that.

I'm not to sure about:

"In a leg-based sort of system, CDRs would follow bridging."

Does that mean whenever the end of a bridge changes a CDR is
generated? And does it mean there are two CDRs per bridge or one?



More information about the asterisk-users mailing list