Asterisk
  1. Asterisk
  2. ASTERISK-10481

Zap assisted xfer via hookflash yield CDR errors and bad CDR's.

    Details

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

      Description

      While most assisted xfer scenarios seem to work OK
      within chan_zap, one sequence has CDR problems.

                • STEPS TO REPRODUCE ******

      Zap/52 picks up phone and dials Zap/51.
      Zap/51 answers, and they talk.
      Zap/52 hookflashes, and gets dialtone. Zap/51 gets MOH.
      Zap/52 dials Zap/50
      Zap/50 answers, and they talk.
      Zap/52 hookflashes. All 3 parties are connected.
      Zap/52 hangs up. (CDR errors happen at this point in time) 50/51 are still conversing.
      Zap/50 and/or Zap/51 hang up.

                • ADDITIONAL INFORMATION ******

      The only requirement is that zap/52 be a zap channel. Same error happens if connects any other devices together, like two SIP channels, etc.

      Oh, and remember that "zap/52" stands for ANY generic zap channel.

        Activity

        Hide
        deeperror added a comment -

        nullok is unrelated to this issue.

        Output CDR's seems find as I'm now getting both legs of the call in Master.csv.

        In our environment the only time I'm seeing "No Answer Time" is when an outbound call occurs and no one answers. So from what I see the warning doesn't need to be there.

        What is a time line or how long would a fix like this take to get into stable release?

        Show
        deeperror added a comment - nullok is unrelated to this issue. Output CDR's seems find as I'm now getting both legs of the call in Master.csv. In our environment the only time I'm seeing "No Answer Time" is when an outbound call occurs and no one answers. So from what I see the warning doesn't need to be there. What is a time line or how long would a fix like this take to get into stable release?
        Hide
        Steve Murphy added a comment -

        Well, since this set of fixes is aimed at closing several bug reports,
        it would be good to have a good amount of feedback. For instance, I've
        been hearing a lot of noise about dropped accountcodes... is that still a problem?

        Another fly in the ointment is that I plan to svnmerge in the dahdi
        code today, which will trade the zap for dahdi names, which shouldn't
        make any difference, but... you never know.

        I do have some requests to fix the CDR generation for things like
        attended xfers, to generate 3 CDR's instead of 2. But I need some sort
        of agreement about how the 3rd CDR should appear. I've been thinking
        on it, and the transferer should be the originator, even if he didn't
        participate in the call, because he's the one that dialed it. So, if
        he transfers the call to a long-distance external number, he should most
        likely get assigned the $400 expense. Perhaps the lastapp could be 'xfer',
        and the lastdata could indicate that he transferred the call to "Zap/11"
        or somesuch... at any rate, such structural changes to the way CDR's are
        getting generated will most likely not be welcome in 1.4, but depending
        on who you talk to, it could either be considered an enhancement or a bug fix.
        In such cases, I'd have to go with the guys whose apps would be broken,
        and call it an enhancement, and intro it in trunk for the next 1.6 release.
        What do you-all think?

        Show
        Steve Murphy added a comment - Well, since this set of fixes is aimed at closing several bug reports, it would be good to have a good amount of feedback. For instance, I've been hearing a lot of noise about dropped accountcodes... is that still a problem? Another fly in the ointment is that I plan to svnmerge in the dahdi code today, which will trade the zap for dahdi names, which shouldn't make any difference, but... you never know. I do have some requests to fix the CDR generation for things like attended xfers, to generate 3 CDR's instead of 2. But I need some sort of agreement about how the 3rd CDR should appear. I've been thinking on it, and the transferer should be the originator, even if he didn't participate in the call, because he's the one that dialed it. So, if he transfers the call to a long-distance external number, he should most likely get assigned the $400 expense. Perhaps the lastapp could be 'xfer', and the lastdata could indicate that he transferred the call to "Zap/11" or somesuch... at any rate, such structural changes to the way CDR's are getting generated will most likely not be welcome in 1.4, but depending on who you talk to, it could either be considered an enhancement or a bug fix. In such cases, I'd have to go with the guys whose apps would be broken, and call it an enhancement, and intro it in trunk for the next 1.6 release. What do you-all think?
        Hide
        Steve Murphy added a comment -

        OK, I've svnmerged and now we are dahdi based instead of zaptel based.
        What you need to do is check out:

        http://svn.digium.com/svn/dahdi/linux/trunk
        http://svn.digium.com/svn/dahdi/tools/trunk

        build and install first the linux half
        then build and install the tools half;

        then run ./configure in the CDRfix* dir make menuselect; make; make install
        there. Make sure the channel driver "chan_dahdi" is selected (if you use
        any zap stuff), and built.

        Show
        Steve Murphy added a comment - OK, I've svnmerged and now we are dahdi based instead of zaptel based. What you need to do is check out: http://svn.digium.com/svn/dahdi/linux/trunk http://svn.digium.com/svn/dahdi/tools/trunk build and install first the linux half then build and install the tools half; then run ./configure in the CDRfix* dir make menuselect; make; make install there. Make sure the channel driver "chan_dahdi" is selected (if you use any zap stuff), and built.
        Hide
        Steve Murphy added a comment -

        OK, I slightly modified that warning message to only be emitted if the
        CDR is marked "ANSWERED", and there is no answer time set. This makes
        it a little more useful; it should never appear in normal operating
        conditions. This has been committed to CDRfix4 and CDRfix6.

        Show
        Steve Murphy added a comment - OK, I slightly modified that warning message to only be emitted if the CDR is marked "ANSWERED", and there is no answer time set. This makes it a little more useful; it should never appear in normal operating conditions. This has been committed to CDRfix4 and CDRfix6.
        Hide
        Digium Subversion added a comment -

        Repository: asterisk
        Revision: 127663

        U branches/1.4/channels/chan_dahdi.c
        U branches/1.4/channels/chan_sip.c
        U branches/1.4/include/asterisk/cdr.h
        U branches/1.4/main/cdr.c
        U branches/1.4/main/channel.c
        U branches/1.4/main/pbx.c
        U branches/1.4/res/res_features.c

        ------------------------------------------------------------------------
        r127663 | murf | 2008-07-02 19:08:58 -0500 (Wed, 02 Jul 2008) | 30 lines

        The CDRfix4/5/6 omnibus cdr fixes.

        (closes issue ASTERISK-10481)
        Reported by: murf
        Tested by: murf, deeperror

        (closes issue ASTERISK-12240)
        Reported by: falves11
        Tested by: murf, falves11

        (closes issue ASTERISK-11309)
        Reported by: greyvoip

        As to 11849, I think these changes fix the core problems
        brought up in that bug, but perhaps not the more global
        problems created by the limitations of CDR's themselves
        not being oriented around transfers.

        Reopen if necc, but bug reports are not the best
        medium for enhancement discussions. We need to start
        a second-generation CDR standardization effort to cover
        transfers.

        (closes issue ASTERISK-10625)
        Reported by: rossbeer
        Tested by: greyvoip, murf

        ------------------------------------------------------------------------

        http://svn.digium.com/view/asterisk?view=rev&revision=127663

        Show
        Digium Subversion added a comment - Repository: asterisk Revision: 127663 U branches/1.4/channels/chan_dahdi.c U branches/1.4/channels/chan_sip.c U branches/1.4/include/asterisk/cdr.h U branches/1.4/main/cdr.c U branches/1.4/main/channel.c U branches/1.4/main/pbx.c U branches/1.4/res/res_features.c ------------------------------------------------------------------------ r127663 | murf | 2008-07-02 19:08:58 -0500 (Wed, 02 Jul 2008) | 30 lines The CDRfix4/5/6 omnibus cdr fixes. (closes issue ASTERISK-10481 ) Reported by: murf Tested by: murf, deeperror (closes issue ASTERISK-12240 ) Reported by: falves11 Tested by: murf, falves11 (closes issue ASTERISK-11309 ) Reported by: greyvoip As to 11849, I think these changes fix the core problems brought up in that bug, but perhaps not the more global problems created by the limitations of CDR's themselves not being oriented around transfers. Reopen if necc, but bug reports are not the best medium for enhancement discussions. We need to start a second-generation CDR standardization effort to cover transfers. (closes issue ASTERISK-10625 ) Reported by: rossbeer Tested by: greyvoip, murf ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=127663

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development