Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: CDR/General
    • Labels:
      None
    • Mantis ID:
      11849
    • Regression:
      No

      Description

      At the moment there is one CDR generated per generic bridge. This tends not to create any problems when the bridge has been created by something like:

      SIP User -> Asterisk -> PSTN

      The CDR generated will have the PSTN number as the destination and the SIP User's accountcode.

      When a transfer is undertaken the one CDR per generic bridge approach breaks down. An example call flow for a blind transfer is:

      SIP User -> Asterisk -> PSTN
      PSTN <- Asterisk -> PSTN (this is after the user has blind transferred the first call to a second PSTN number)

      At the moment Asterisk will correctly generate a CDR for the first call leg but for the second call leg there is a problem. For the sconed call leg both ends of the bridge are now billable but as Asterisk only generates a single CDR per bridge one of the legs will not get billed.

      A straight forward fix (at least architecturally) would be to generate a CDR for each end of the bridge instead of combining both ends into a single CDR. It would mean some extra CDR's for the standard SIP User -> PSTN call but it's a lot easier to filter out CDR's to ignore than it is to try and work out how to handle ones that are missing.

      I've classified this as major since it's costing me (and other providers) money every time a user does a transfer .

      1. attendedtransfer.agi
        9 kB
      2. cdr_transfer_function.patch
        9 kB
        frawd
      3. settransferfield.agi
        1 kB
      4. v2-attendedtransfer.agi
        5 kB
      5. v2-blindtransfer.agi
        4 kB
      6. v2-settransferfield.agi
        1 kB
      7. v2-setuniqueid.agi
        1 kB

        Activity

        Hide
        Matthew Nicholson added a comment -

        Workarounds like the one you have described here are basically the only way to handle this situation given the present CDR architecture. CDR records are currently very bridge centric, but to satisfy your requirements, a cdr record would need to be generated for each channel. This sort of thing will be possible with future versions of asterisk 1.6.

        Show
        Matthew Nicholson added a comment - Workarounds like the one you have described here are basically the only way to handle this situation given the present CDR architecture. CDR records are currently very bridge centric, but to satisfy your requirements, a cdr record would need to be generated for each channel. This sort of thing will be possible with future versions of asterisk 1.6.
        Hide
        Sverre G added a comment -

        I mentioned it earlier but it's worth repeating. I have accounts with a number of SIP providers that use Asterisk. I have verified that I can currently make near free mobile or international calls by placing the call, then doing a transfer to a local number. The timer for the mobile call stops, and the local call is a flat rate.

        I've heard stories of hacked Asterisk machines being used to place huge numbers of expensive international calls, so there's clearly a motivation for people with malicious intent to exploit this security hole.

        Show
        Sverre G added a comment - I mentioned it earlier but it's worth repeating. I have accounts with a number of SIP providers that use Asterisk. I have verified that I can currently make near free mobile or international calls by placing the call, then doing a transfer to a local number. The timer for the mobile call stops, and the local call is a flat rate. I've heard stories of hacked Asterisk machines being used to place huge numbers of expensive international calls, so there's clearly a motivation for people with malicious intent to exploit this security hole.
        Hide
        Matthew Nicholson added a comment -

        Yes I saw that. I am aware of this, and it is a fairly serious problem. Unfortunately, this can only be fixed in future 1.6 asterisk releases, without dramatically changing the way CDR records are generated.

        This could be fixed if there was one CDR record generated per bridge, and one generated per channel, but this could potentially break existing billing systems. Perhaps this could be added as an optional feature.

        Would generating one CDR record per channel resolve this issue for you?

        Show
        Matthew Nicholson added a comment - Yes I saw that. I am aware of this, and it is a fairly serious problem. Unfortunately, this can only be fixed in future 1.6 asterisk releases, without dramatically changing the way CDR records are generated. This could be fixed if there was one CDR record generated per bridge, and one generated per channel, but this could potentially break existing billing systems. Perhaps this could be added as an optional feature. Would generating one CDR record per channel resolve this issue for you?
        Hide
        Sverre G added a comment -

        I can think of a few scenarios where having 1 CDR per channel would be superior. Currently when one customer calls another customer on Asterisk, the "incoming" CDR for the destination customer is missing (only 1 CDR to share between two customers, and we'd rather keep the billable outgoing one!).

        That being said, I can't figure out in my mind how we would figure out which channels are billable and which aren't - in most cases you'd only want to bill for 1 of the 2, though I'm sure there'd be a way.

        I'm going to say "yes it would resolve it", but I imagine there'd be quite a process in figuring out how to implement a billing system around it.

        Given that people can use my hack workaround to fix the problem for now, my feeling is that any time spent fixing the current CDR system is time that could be spent on the new CDR system, though it depends on how far off it is. If we can expect to see it in the next month or so, I wouldn't worry about it. If it's going to be 6 months on the other hand, then yes I'd start playing with one CDR per channel.

        Show
        Sverre G added a comment - I can think of a few scenarios where having 1 CDR per channel would be superior. Currently when one customer calls another customer on Asterisk, the "incoming" CDR for the destination customer is missing (only 1 CDR to share between two customers, and we'd rather keep the billable outgoing one!). That being said, I can't figure out in my mind how we would figure out which channels are billable and which aren't - in most cases you'd only want to bill for 1 of the 2, though I'm sure there'd be a way. I'm going to say "yes it would resolve it", but I imagine there'd be quite a process in figuring out how to implement a billing system around it. Given that people can use my hack workaround to fix the problem for now, my feeling is that any time spent fixing the current CDR system is time that could be spent on the new CDR system, though it depends on how far off it is. If we can expect to see it in the next month or so, I wouldn't worry about it. If it's going to be 6 months on the other hand, then yes I'd start playing with one CDR per channel.
        Hide
        Matthew Nicholson added a comment -

        This bug is being closed as won't fix in anticipation of channel event logging being released with Asterisk 1.6.3. Channel event logging will allow for properly tracking and billing channels that are transfered one or many times. This bug will NOT be fixed in Asterisk 1.4.

        Show
        Matthew Nicholson added a comment - This bug is being closed as won't fix in anticipation of channel event logging being released with Asterisk 1.6.3. Channel event logging will allow for properly tracking and billing channels that are transfered one or many times. This bug will NOT be fixed in Asterisk 1.4.

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development