Hi guys I've just read this about the upcoming release of * 1.6: ?Better reporting through a new call event logging capability in Asterisk 1.6 will allow complete tracking of events that take place during a call. The goal, according to Fleming, is to provide more detail than traditional CDR (Call Detail Recording) features offer and to allow for more granular tracking and auditing.? That sounds brilliant! But I'm in desperate need of something to handle call tracing in 1.4... Does anyone know how I can accomplish this? I thought about using the originating uniqueid and populate for every event related to the call (transfers, etc), but I'm having trouble reading the dialplan to see what executes where :(
On 3/11/08, Louwrens Benad? <louwrens at jasper.co.za> wrote:> Hi guys > > I've just read this about the upcoming release of * 1.6: > > "Better reporting through a new call event logging capability in Asterisk > 1.6 will allow complete tracking of events that take place during a call. > The goal, according to Fleming, is to provide more detail than traditional > CDR (Call Detail Recording) features offer and to allow for more granular > tracking and auditing." > > That sounds brilliant! But I'm in desperate need of something to handle call > tracing in 1.4... > > Does anyone know how I can accomplish this? I thought about using the > originating uniqueid and populate for every event related to the call > (transfers, etc), but I'm having trouble reading the dialplan to see what > executes where :(That's the way how i have it workin. Of course, this wasn't done in one day, i've been working on details for weeks. Generally i use CDR, and manipulate it with ResetCDR, NoCDR, and link them together by first uniqueid. This works great for IVRs, extension2extension calls, outgoing calls, blind transfers, queues. So i can take any call and see what was done to it, where it was transferred, duration of each step and so on, so on. However it won't work for conferences (you don't know that person will join conference unless it joins, and then it's too late to change uniqueid, first cdr may be already writted), and i haven't implemented that for blind transfers. But generally if you want all that in DB, manipulating CDR is the way to go. When you will have more specific questions, please ask, i'm sure somebody will answer :) Regards, Atis -- Atis Lezdins, VoIP Project Manager / Developer, atis at iq-labs.net Skype: atis.lezdins Cell Phone: +371 28806004 Cell Phone: +1 800 7300689 Work phone: +1 800 7502835
On 3/12/08, Louwrens Benad? <louwrens at jasper.co.za> wrote:> > That's the way how i have it workin. Of course, this wasn't done in > one day, i've been working on details for weeks. Generally i use > CDR, > and manipulate it with ResetCDR, NoCDR, and link them together by > first uniqueid. This works great for IVRs, extension2extension > calls, > outgoing calls, blind transfers, queues. So i can take any call and > see what was done to it, where it was transferred, duration of each > step and so on, so on. However it won't work for conferences (you > don't know that person will join conference unless it joins, and > then > it's too late to change uniqueid, first cdr may be already writted), > and i haven't implemented that for blind transfers. But generally if > you want all that in DB, manipulating CDR is the way to go. > > When you will have more specific questions, please ask, i'm sure > somebody will answer :) > > > So I'm not the only one :) > > Ok, because of my lack of knowledge about using the dial-plan, I've resorted > to using Trixbox (don't laugh). I've managed to find where the initial > uniqueid is inserted which I then pump into a variable, and from there into > the 'userfield' in the CDR. > > The problem I'm having at the moment is that I can't figure out when the > next hit in the CDR takes place. I've found the macro that (I think) > generates it, but no matter what I try, I can't populate the 'userfield' for > the next event. > > So here are my questions: > > 1. Is the next event in the CDR inserted by ResetCDR or NoCDR?NoCDR wouldn't cause that, as that's supposed to skip posting current CDR. Next entry would be caused by either ResetCDR(w) or some application that creates new channel (i.e. Dial or Queue). You can enable "full" log and set verbosity and debug to higher values, to see all what's going on.> > 2. Can I use a locally defined variable ( exten => > s,n,Set(v_identme=${CDR(UNIQUEID)})) ) or do I have to use a global > variable?I'm not sure about value of ${CDR(UNIQUEID)}, but you can use just ${UNIQUEID}. If you want to pass variable to child channels, you should make it inheritable. I'm using: Set(__call_id=${UNIQUEID}) Regards, Atis -- Atis Lezdins, VoIP Project Manager / Developer, atis at iq-labs.net Skype: atis.lezdins Cell Phone: +371 28806004 Cell Phone: +1 800 7300689 Work phone: +1 800 7502835
On Tue, Mar 11, 2008 at 9:41 AM, Louwrens Benad? <louwrens at jasper.co.za> wrote:> > "Better reporting through a new call event logging capability in Asterisk > 1.6 will allow complete tracking of events that take place during a call. > The goal, according to Fleming, is to provide more detail than traditional > CDR (Call Detail Recording) features offer and to allow for more granular > tracking and auditing."Sounds semi-CALEA-compliant...