[asterisk-bugs] [Asterisk 0012724]: Asterisk does not log all legs of call transfers and/or logs wrong information

[noreply at bugs.digium.com]

The following issue has been set as RELATED TO issue 0010927. 
====================================================================== 
http://bugs.digium.com/view.php?id=12724 
====================================================================== 
Reported By:                johnlange
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   12724
Category:                   CDR/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.19 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-26-2008 15:10 CDT
Last Modified:              05-26-2008 18:05 CDT
====================================================================== 
Summary:                    Asterisk does not log all legs of call transfers
and/or logs wrong information
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.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0011093 CDR Created incorrectly on Transfer of ...
related to          0010927 Zap assisted xfer via hookflash yield C...
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-16-08 12:21  murf           Relationship added       related to 0010927  
======================================================================