No CDR on API: Redirect

Asterisk Asterisk Support
1

Hi all,

We have an issue with CDR’s when calling the manager action “redirect” to divert a call to another agent. CEL is populated fine and CDR works fine for all other events.

Call flow is this:

  • Caller hits a queue for support
  • Agent is already on another call, so puts this on hold. Then calls a PHP script to do the manager redirect to pass the call on to his phone.
  • Redirect works fine, agent answers the call on second line, hangs up. CEL shows all the expected data, but nothing shows in CDR at all.

The code for the divert:

[i]Action: Login
UserName: ".$user."
Secret: “.$pass.”

Action: Events
EventMask: OFF

Action: Redirect
Channel: ".$Channel_name."
Exten: ".$agent_extension."
Context: phones //where agent extension numbers are housed
Priority: 1

Action: Logout[/i]

The entry in extensions.queues.conf (where the diverted channel hits first)

exten => [[our number]],1,Answer()
exten => [[our number]],n,ResetCDR()
exten => [[our number]],n,Set(CDR(accountcode)=80)
exten => [[our number]],n,Set(CDR(userfield)=inbound)
exten => [[our number]],n,Set(MONITOR_FILENAME=[[Our Queue Name]]_${UNIQUEID})
exten => [[our number]],n,Set(CALLERID(name)=[[Our Queue Name]])
exten => [[our number]],n,Queue([[Our Queue Name]])
exten => [[our number]],n,Hangup()

Note - ResetCDR() is needed in this context to have a seperate Billsec and Duration.

The entry in [phones]

exten => 1005,1,Answer()
exten => 1005,n,MixMonitor(1005_${UNIQUEID}.WAV)
exten => 1005,n,Dial(SIP/1005)

I have also tried this without Answer() in the agent number context, but this makes no difference.

CEL for a diverted call: (names removed to protect the innocent, etc)

±--------------------±-------------±--------±-----------------±-----------------+
| eventtime | eventtype | appname | uniqueid | linkedid |
±--------------------±-------------±--------±-----------------±-----------------+
| 2012-11-27 16:53:41 | CHAN_START | | 1354035221.27201 | 1354035221.27201 |
| 2012-11-27 16:53:41 | ANSWER | Answer | 1354035221.27201 | 1354035221.27201 |
| 2012-11-27 16:53:41 | APP_START | Queue | 1354035221.27201 | 1354035221.27201 |
| 2012-11-27 16:54:39 | ANSWER | Answer | 1354035221.27201 | 1354035221.27201 |
| 2012-11-27 16:54:39 | APP_START | Dial | 1354035221.27201 | 1354035221.27201 |
| 2012-11-27 16:54:39 | CHAN_START | | 1354035279.27217 | 1354035221.27201 |
| 2012-11-27 16:54:41 | ANSWER | AppDial | 1354035279.27217 | 1354035221.27201 |
| 2012-11-27 16:54:41 | BRIDGE_START | Dial | 1354035221.27201 | 1354035221.27201 |
| 2012-11-27 16:55:27 | BRIDGE_END | Dial | 1354035221.27201 | 1354035221.27201 |
| 2012-11-27 16:55:27 | HANGUP | AppDial | 1354035279.27217 | 1354035221.27201 |
| 2012-11-27 16:55:27 | CHAN_END | AppDial | 1354035279.27217 | 1354035221.27201 |
| 2012-11-27 16:55:27 | HANGUP | | 1354035221.27201 | 1354035221.27201 |
| 2012-11-27 16:55:27 | CHAN_END | | 1354035221.27201 | 1354035221.27201 |
±--------------------±-------------±--------±-----------------±-----------------+

However, nothing at all can be found in CDR for either the uniqueid or the linkedid.

To get around this, I have a cronjob which searches for linkedid’s in CEL that are not present in CDR and creates a record, but this is fraught with errors and a bodged fix for something that I suspect is some error in our config somewhere.

Has anyone had any experience of this issue? Any ideas on a fix?

2

Just for some more info - we’re using cdr_adaptive_odbc and cel_odbc to log CDRs onto a seperate server. If I look at the CLI with verbosity at 100, I can see all the CEL events, but nothing at all for CDR. The same issue occurs when using cdr_odbc and legacy MySQL.

If it is needed, I can upload the output from CLI, but don’t believe it to be relevant in this case.

3

CEL was introduced because CDRs don’t handle anything but trivial cases well, and because attempts to add support for one case generally broke another.

If you are doing redirects, etc.you should not be using CDRs.

4

Hi david55, thanks for your reply

In this situation, what is the standard means of billing customers if you are not using CDR? Would you use CEL for billing?

I can see how this could be done, but it would require a lot of effort…

5

bump

6

david55 already answered your question - use CEL if you want good billing only for “exotic” dialplan scenarios.

The only other option would be to modify the dialplan (remove the “exotic” dialplan scenarios), so CDR’s can handle everything properly.

7

Just for the record, for those who are still using 1.8 and 11:

Instead the AMI “Redirect” action, use AMI “Command” action:
Action: Command
Command: channel redirect $chan $context,$exten,$prio

Works as expected and generates the CDR