On Tue, 2008-11-25 at 08:06 +0000, Grey Man wrote: > >On Mon, Nov 24, 2008 at 6:56 PM, Steve Murphy <[EMAIL PROTECTED]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
