[asterisk-users] Unique id used for call recording missing from CDR data for transferred call

[Scott Gifford]

Hello,

I have an application that needs to record outgoing calls.  It's
running on Asterisk 1.4.18, with CDR data stored in MySQL.

Outgoing calls are recorded based on their uniqueid.  When outgoing
calls are placed, there is a line like this on my extensions.conf:

    exten => _.,n,MixMonitor(/var/spool/asterisk/monitor/${UNIQUEID}.gsm)

For regular outgoing calls, this works fine.  The call is recorded in
a file named for its uniqueid, and if I need the recording I can pull
the information out of the CDR table, find the uniqueid, then pull up
the recording.  We have a Web application that does this
automatically.

When an incoming is transfered to an outgoing call via an attended SIP
transfer, however, the uniqueid assigned to the outgoing call does not
seem to end up in the CDR table at all.

Here's what happens:

  1. User A calls in to the queue on Zap/1-1 uniqueid 1247686911.203
  2. Operator picks up call.
  3. Queue application starts recording in 1247686911.203.gsm
  4. Operator talks for awhile, decides to transfer call
  5. Operator switches Line 2, calls User B on channel Zap/24-1 with
     uniqueid 1247686911.205
  6. Dialplan command MixMonitor(1247686911.205.gsm) starts recording
  7. Operator talks to User B for awhile
  8. Operator transfers call, connects User A to User B, and hangs up

This generates these 4 CDRs:

  1. 2009-07-15 15:41:51
     channel Zap/1-1
     dstchannel SIP/DEV-0078ebd0
     duration 175
     uniqueid 1247686911.203

  2. 2009-07-15 15:43:17
     channel SIP/DEV-0078ebd0
     dstchannel (none)
     duration 89
     uniqueid 1247686997.204

  3. 2009-07-15 15:43:47
     channel Zap/24-1
     dstchannel Zap/1-1
     duration 80
     uniqueid 1247687027.206

  4. 2009-07-15 15:43:47
     channel SIP/DEV-c4018700<ZOMBIE>
     dstchannel Zap/24-1
     duration 59
     uniqueid 1247686911.203

The uniqueid for the outgoing call, 1247686911.205, doesn't end up in
any of the CDRs, so is effectively lost.

Any ideas on how to handle this?  Is this something that's likely to
be fixed in a later version of Asterisk?

Thanks,

----Scott.