[Home]

Summary:ASTERISK-12083: Asterisk does not log all legs of call transfers and/or logs wrong information
Reporter:John Lange (johnlange)Labels:
Date Opened:2008-05-26 15:10:37Date Closed:2008-07-03 15:44:23
Priority:MajorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:This blog posting explains in detail how call transfers should appear in the logs:

http://www.asterisk.org/node/48358

However, several of the scenarios do not appear to be working as they should.

Specifically in the log examples below, call from PSTN source "EPIC INFORMATIO" <2044775516> (device A) to "John Lange" <2049757113> (device B) is answered and then transfered to "SIP/00085d0383a7x1" (device C).

Scenario 3 from the blog: Unattended transfer via SIP transfer button. Only the final leg of the call (device A <-> C) is logged. The information is correct but the initial call (device A <-> B) is not logged at all.

Scenario 8 and 11 from the blog: Attended xfer via SIP (Polycom/Snom), 201 (polycom/Snom) hangs up first. (I actually tested this with Polycom And Aastra phones since I don't have a Snom)

All 3 legs of the call are logged but every leg has the wrong information.

Here is a detailed explanation. Scenarios 8 & 11 basically describe a typical receptionist situation. A call comes in via a Zap channel and is answered by the receptionist on a Sip hardphone and the Receptionist then does an attended transfer to another Sip hardphone.  Here is what the log shows with line numbers added by me:

1. "","2049757113","2049757113","from-pstn","""John Lange"" <2049757113>","SIP/0004f2167c2bx1-b6297248<ZOMBIE>","SIP/00085d0383a7x1-085f9f90","Dial","SIP/00085d0383a7x1|20|rtwk","2008-05-26 19:24:41","2008-05-26 19:24:44","2008-05-26 19:24:47",6,3,"ANSWERED","DOCUMENTATION","1211829876.16761",""
2. "","2049757113","2049757113","from-pstn","""John Lange"" <2049757113>","SIP/0004f2167c2bx1-085f4858","","","","2008-05-26 19:24:36","2008-05-26 19:24:38","2008-05-26 19:24:47",11,9,"ANSWERED","DOCUMENTATION","1211829876.16762",""
3. "","2049757113","2049757113","from-pstn","""John Lange"" <2049757113>","Zap/1-1","SIP/0004f2167c2bx1-085f4858","Dial","SIP/0004f2167c2bx1","2008-05-26 19:24:36","2008-05-26 19:24:38","2008-05-26 19:24:47",11,9,"ANSWERED","DOCUMENTATION","1211829876.16761",""

As you can see, in every case there is a problem.

1. Is device A <-> C. The source should be "EPIC INFORMATIO" <2044775516>. The destination is correct.

2. Is device B <-> C. The source is correct "John Lange"" <204975711>, but the destination should be "103" (the local extension of device SIP/00085d0383a7x1).

3. Is device A <-> C. The source should be "EPIC INFORMATIO" <2044775516>, and the destination should be "103" (the local extension of device SIP/00085d0383a7x1).

I flag this as major because it completely breaks billing based on the logs.
Comments:By: John Lange (johnlange) 2008-05-26 15:52:12

I should also mention that this bug applies to 1.4.20 as well.

By: Steve Murphy (murf) 2008-07-03 15:44:18

Rats! I thought I got all the bugs that would be fixed by

1.4 = rev 127663  (merged the CDRfix4 branch into 1.4)
trunk = rev 127793
1.6.0 = rev 127830  (merged CDRfix6 into trunk and 1.6.0)

but this one was overlooked.

If you find that problems remain, please re-open this bug
and explain in detail what problem remains.

If the fixes that were made to solve these bugs introduce
new problems, please open a new bug report.

many thanks!