|Summary:||ASTERISK-07442: CDRs scrambled on attended transfers|
|Reporter:||Jan-Peter Koopmann (jkoopmann)||Labels:|
|Date Opened:||2006-08-02 04:39:18||Date Closed:||2006-09-06 10:52:48|
|Description:||Incoming call on Zap. Call is taken on a SIP phone. The call is then transfered to another SIP phone using Asterisks attended transfer feature (not SIP transfer of the phone itself). The resulting CDRs do not seem to be correct.|
Call is taken --> no CDR (correct).
Attended transfer is initiated --> no CDR (correct).
The transferring phone hangs up and call is transfered to the second phone:
| 2006-08-02 11:29:40 | | | Zap/1-1 | 43 | SIP/phone_100-b0d5 |
The call is hungup:
| 2006-08-02 11:30:01 | 43 | "Koopmann, Jan-Peter" <0015112345678> | Local/44@transfer_ctx-dc32,1 | s | Zap/1-1 |
| 2006-08-02 11:29:53 | 43 | "Koopmann, Jan-Peter" <0015112345678> | Local/44@transfer_ctx-dc32,2 | 44 | SIP/phone_110-bc22 |
Colums are calldate, src, clid, channel, dst, dstchannel. Note that I changed the src information via DB triggers so please do not pay attention to that. Two things are strange:
The first CDR created does not have a src or clid while the information clearly is still somewhere in asterisk. The cdr itself appears to be correct since the call was initiated to extension 43 and was taken by SIP/phone_100. But where is the src/clid info?
The second CDR is strange. I suppose it is the call from the first phone to the second phone (attended transfer). If this is the case: Why is this cdr written after the external call is hungup and not after the transfer is finished? Why is dstchannel Zap/1-1 which is wrong since SIP/phone_110 took the call? Zap/1-1 is the src channel of the original call not the dstchannel of the attended transfer call from phone_a to phone_b.
The third CDR looks ok to me.
****** ADDITIONAL INFORMATION ******
I cannot test with trunk unfortunatly.
|Comments:||By: Thiago Maluf (malufrj) 2006-08-10 13:01:34|
if possible, do upload this files with the CDR and your extensions.conf.
By: Serge Vecher (serge-v) 2006-09-06 10:52:47
no response for a month. Please reopen if you are able to reproduce with 1.2 branch r > 42000 and have the sample CDR data available showing the problem.