[asterisk-users] CDR problems with Queue

[Håkon Nessjøen]

On Wed, Jan 27, 2010 at 8:22 PM, Danny Nicholas <danny at debsinc.com> wrote:

>  This stands to be corrected, but as I understand it, the queue command on
> it’s own would not generate a second CDR any more than a transfer to an
> extension.  The way I understand the queue/agent/call relationship is this:
>
>    1. agent(s) login to queue – this may or may not create a CDR entry
>    2. caller calls asterisk – this creates a CDR for that incoming call
>    3. caller is sent to queue by context or dialplan – this creates a CDR
>    only if forkCDR is used since the queue command isn’t a “new call”
>
>
>
> It seems to me that would be “desirable” for queue to act as a “second pbx”
> where queue activity (login/logout/transfer etc) is logged in the CDR as new
> calls,
>
>
>
> Since my queue experience and $5 will get you a decent starbucks in some
> places, take this with a grain of salt, please.
>

Hi,

I'm not sure if you understand me correctly. I'm not interested in cdrs for
agent logins. For me, that is not call detail.
But when you call into the pbx, thats one leg, and one cdr. And when a
queue() calls out to an agent, that is also a call. And for me, it's logical
that this would be two cdr lines. Because if this is going in and out of a
PRI/SS7 line, you would get money and pay money for these calls. And
therefore it's very important that queue() would start the cdr duration a
the exact moment the agent answers. etc.

But the weirdest thing, is that the CDR for leg A is written when queue() is
done, even if leg A is still active.

I can't understand how people would accept this behaviour as logical? There
must be a way to make queue() create valid cdrs? The one I get isn't correct
for either legs.

Regards,
Håkon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100127/40cf2a44/attachment.htm