Asterisk
  1. Asterisk
  2. ASTERISK-12083

Asterisk does not log all legs of call transfers and/or logs wrong information

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: CDR/General
    • Labels:
      None
    • Mantis ID:
      12724
    • Regression:
      No

      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.

        Activity

        Hide
        John Lange added a comment -

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

        Show
        John Lange added a comment - I should also mention that this bug applies to 1.4.20 as well.
        Hide
        Steve Murphy added a comment -

        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!

        Show
        Steve Murphy added a comment - 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!

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development