Re: [asterisk-users] Call tracing - Asterisk 1.4

2008-03-13 Thread Andreas van dem Helge
On Tue, Mar 11, 2008 at 9:41 AM, Louwrens Benadé <[EMAIL PROTECTED]> 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...
___
-- 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

Re: [asterisk-users] Call tracing - Asterisk 1.4

2008-03-12 Thread Louwrens Benadé
Thanks Atis

I'll give that a shot and see where I end up.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Atis Lezdins
Sent: 12 March 2008 06:09 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Call tracing - Asterisk 1.4

On 3/12/08, Louwrens Benadé <[EMAIL PROTECTED]> 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,
[EMAIL PROTECTED]
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835

___
-- 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


___
-- 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


Re: [asterisk-users] Call tracing - Asterisk 1.4

2008-03-12 Thread Atis Lezdins
On 3/12/08, Louwrens Benadé <[EMAIL PROTECTED]> 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,
[EMAIL PROTECTED]
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835

___
-- 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


Re: [asterisk-users] Call tracing - Asterisk 1.4

2008-03-12 Thread Louwrens Benadé

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?

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?




___
-- 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


Re: [asterisk-users] Call tracing - Asterisk 1.4

2008-03-11 Thread David Van Ginneken
Atis Lezdins wrote:
> On 3/11/08, Louwrens Benadé <[EMAIL PROTECTED]> 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
>
>
>   

We have a patch we wrote for a client of ours which does something 
similar which should apply to 1.4 cleanly.  Basically it will write to 
callpath_log for every app start and app end event.  We use it to log 
every step a channel takes in the dialplan for reporting purposes.  It 
is VERY verbose.  One thing it does require which you can change is we 
require a uid channel variable to be set for it to log.  (Long story 
short, we pass around the uid between servers in sip headers to have a 
global overview of the call paths throughout the enterprise.)

Anyway here is the code, and some other patches we have:

http://svn.btwtech.com/svnview/coolvocals/trunk/asterisk-customizations/1.4/ 


___
-- 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


Re: [asterisk-users] Call tracing - Asterisk 1.4

2008-03-11 Thread Atis Lezdins
On 3/11/08, Louwrens Benadé <[EMAIL PROTECTED]> 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,
[EMAIL PROTECTED]
Skype: atis.lezdins
Cell Phone: +371 28806004
Cell Phone: +1 800 7300689
Work phone: +1 800 7502835

___
-- 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


[asterisk-users] Call tracing - Asterisk 1.4

2008-03-11 Thread Louwrens Benadé
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 :(


___
-- 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