Summary:ASTERISK-05847: Allow setting of channel with CDR function
Reporter:vortex_0_o (vortex_0_o)Labels:
Date Opened:2005-12-15 08:16:12.000-0600Date Closed:2011-06-07 14:03:27
Versions:Frequency of
Description:Would be good to allow the below - currently read only


This is particularly relevant when used in conjunction with agent call back login so that we know which agent generates the call.

Also allows forcing of the cdr records to be consistent if required - other examples where cdr channel is already listed as the agent by default:

- ami originate with agent channel sets the cdr channel to be the agent
- agentmonitoroutgoing (with option c) sets the cdr channel to be the agent
Comments:By: Tilghman Lesher (tilghman) 2005-12-15 12:08:19.000-0600

Could you show what the channel was, that you're replacing?

By: vortex_0_o (vortex_0_o) 2005-12-15 13:26:11.000-0600

for example replacing SIP/1012-a02a with Agent/123

By: Tilghman Lesher (tilghman) 2005-12-15 13:39:00.000-0600

Is there a good reason why the CDR userfield wouldn't work?  We'd really like to be able to keep certain fields as "hands-off" as possible.  Once you start enabling the alteration of certain fields, the CDR can become quite a mess.  The problem is, what in the CDR can you rely on being correct, if you've allowed the dialplan to set any identifying field?

By: vortex_0_o (vortex_0_o) 2005-12-15 17:31:26.000-0600

The specific use that brought this to mind is to make the cdr consistent when an agent (using agent callback login) places a call manually. Also in this case the userfield and other fields are already heavily in use as well.

See what you mean about possible issues  I would count the dialplan as a trusted item though.
Maybe there is better and  more specific way to change it to the agent? like a Dial option? AgentCallbackLogin option? or a spcific function? - rather than carte blanche to change the cdr channel to anything?

By: Tilghman Lesher (tilghman) 2005-12-16 09:58:46.000-0600

An alternative might be to allow setting the destination channel, but only if blank.  This would allow you to store the information that you're looking to save, in a field that would be blank in the situation that you describe, without compromising the integrity of the CDR.  And further, it would describe to you exactly which channel logged in as the agent you want to reference, providing yet another bit of useful information.

By: vortex_0_o (vortex_0_o) 2005-12-16 12:33:09.000-0600

In my case destination channel normally has an entry - and this info can be useful as well.

What would be absolutely ideal is a separate agent field in the cdr.

By: Jason Parker (jparker) 2005-12-16 14:15:33.000-0600

I've never really looked at CDRs, but the README.cdr file is saying you can put in arbitrary data, like:


Is this only for custom, or does it work for any?

By: Tilghman Lesher (tilghman) 2005-12-16 14:51:33.000-0600

You can store any arbitrary fieldname, as long as it doesn't conflict with one of the reserved names.  However, any CDR backend is free to log the fields it chooses and to ignore others.

For example, I have a custom CDR for a particular customer, into which special fields are stored that do not log anything for the default CDR engines.

By: Russell Bryant (russell) 2005-12-20 12:37:13.000-0600

> What would be absolutely ideal is a separate agent field in the cdr.

Since setting arbitrary CDR variables is already supported, I'm closing this out.