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:37 | Date Closed: | 2008-07-03 15:44:23 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | 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! |