>On Mon, Dec 1, 2008 at 3:26 PM, Steve Murphy <[EMAIL PROTECTED]> 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? >From your examples there only seems to be one CDR per bridge which straight away I can think of a scenario that would cause a problem. If I supply toll free numbers that need to be billed for incoming calls and that can be forwarded out to billable destinations then I want a CDR for both ends of the bridge. In your first blind transfer example what if the initial incoming call to A is billable? I can't see any easy way to get the duration of that call leg. Regards, Greyman. _______________________________________________ -- 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
