[asterisk-users] CDR Design

[Steve Murphy]

On Tue, 2008-11-25 at 08:06 +0000, Grey Man wrote:
> >On Mon, Nov 24, 2008 at 6:56 PM, Steve Murphy <murf at digium.com> wrote:
> > For the moment, let's not worry about the implementation. Let's
> > get consensus on the spec first. In the scenario, where A calls B,
> > B xfers A to C, C xfers A to D, or some such similar scenario,
> > half the world wants a single CDR for A, from the time it started,
> > to the time it hung up with D. The other half wants A->B's dial and
> > bridge,
> > a cdr for A & C's bridge, a CDR for A & D's bridge, and mayhaps some
> > CDRs
> > to describe the xfers, where B xfers A to C and C xfers A to D.
> >
> > My document is pointing in the former direction, and either we need to
> > spec both, or pick one.
> 
> To me the obvious answer is to provide a CDR for every call leg so for
> A calling B via Asterisk there would be two CDRs produced. It's far
> far easier to disregard the unwanted CDRs than it is to try and
> generate the missing ones and in some cases it's virtually impossible.
> If it's weighed up I think people would vote to have accurate CDRs
> ahead of anything else and if single legs are the best way to do that
> then it's the way it should be done.
> 
> In addition with single leg CDRs it will solve the dilemna about
> acommodating every possible call scenario that I know has caused you a
> lot of consternation over the last 18 months.
> 
> Sure it's a change from the current situation so maybe needs to use
> the standard apporach of a configuration setting to opt in initially
> before becoming the default in the subsequent major release.
> 
> Regards,
> 
> Greyman.
> 
> P.S. Sorry about the duplicate post. I actually sent the email to the
> list 4 times with around 8 hour spacings and I'm not sure why there
> was a problem getting it through.

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.

Greyman is correct. By cutting the timeline into legs, 
we avoid all the nasty channel state problems, or so it
appears thus far. I threw out all the text about 
channel/peer state, fleshed in all the example 
cases, etc.

I added a section describing the linkedID field.

I provide a list of CDR record types at the end,
that will eventually be expanded to describe each
field that set in that type, and what they mean.

The types so far are:

3WAY
AXFER 
AXFER1
AXFER2
BARGE
BXFER
CALL
CONF 
HOLD 
PARK
RECALL
RECONN
USER 
WHISPER   


murf


-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20081201/b28265ed/attachment.bin