[Home]

Summary:ASTERISK-28610: CDR fields in second leg use wrong variables from first leg
Reporter:Schneur Rosenberg (thesipguy)Labels:
Date Opened:2019-11-07 06:43:00.000-0600Date Closed:2019-12-02 12:00:03.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Applications/app_cdr Applications/app_dial
Versions:17.0.0 Frequency of
Occurrence
Related
Issues:
Environment:Debian 9Attachments:
Description:Hi, I have a platform that when called through a outside DID the caller receives a DISA and can complete a call to a outside line, the system creates 2 legs in the CDR’s one for the incoming channel and one for the dial command to the outside line.

I recently upgraded from version 11 to 17 and I’ve noticed that the second leg does not store the correct info in the dst , dcontext and channel fields, it copies the data from the original leg instead of using the info from the second leg, and for example if the first leg had the did number in the dst field, then the second field will have the same info and therefore I get almost zero info on the destination of the call besides some hints in the lastdata field, and hence I can’t properly bill for these calls.

Scott Rosenberg

Comments:By: Asterisk Team (asteriskteam) 2019-11-07 06:43:02.225-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Joshua C. Colp (jcolp) 2019-11-07 07:30:45.962-0600

As part of Asterisk 12 CDRs were completely rewritten and a specification defined[1]. Which scenario are you using? Does it match the specification, or is it behaving differently? What is the console output? Do you have dialplan that can reproduce the problem?

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification
By: Schneur Rosenberg (thesipguy) 2019-11-13 10:45:15.170-0600

I have read the new CDR specs but I dont see my scenerio, also after doing some testing I've realized that I havent reported the problem properly, I saw 2 records and thought they were 2 legs but they were really 2 attempts to dial a outside number through my LCR hence the 2 legs, but my issue is previously when I called in to the system through a outsdide DID and got a disa, the Disa ended up terminating the call to a POTS line, I would get 2 records in the DB, one for the incoming channel that called the disa with the billsecs of the entire call from when the first leg was picked up, and second record would be the number called and the billsec started when the second leg answered, now with the new version of Asterisk it creates only one leg and the billing seconds and duration are for the entire call which makes it imposible for me to bill for those calls because the seconds and the dst are both wrong.


By: Joshua C. Colp (jcolp) 2019-11-13 13:23:30.296-0600

Can you please provide example configuration including dialplan and instructions which reproduce the problem, as well as the CDR records you see.
By: Schneur Rosenberg (thesipguy) 2019-11-14 05:02:47.070-0600

Ok, so for testing purposes I created a very simple context that the call starts there, all it does it it sends the call to a DISA, I have the same code on a server running Asterisk 11.25.3 and on a server running Asterisk 17, the only difference is that on the new server I used CHANNEL(accountcode) instead of CDR here is the dialplan

exten => _12125551212,1,set(CDR(accountcode)=testAccount)    
exten => _12125551212,n,disa(no-password,usa_customer_out_full)

I placed a call on both systems and here is the first leg in the CDR of the old system
            id: 100561913
      calldate: 2019-11-14 05:32:39
          clid:
           src: blankedOut
           dst: 18004312121
      dcontext: opensips_incoming
       channel: SIP/opensipsout-00109ad2
    dstchannel:
       lastapp: DISA
      lastdata: no-password,usa_customer_out_full
      duration: 8
       billsec: 8
   disposition: ANSWERED
      amaflags: 3
   accountcode: testAccount
     userfield:
      uniqueid: 1573727559.1233080
   destination: NULL
          cost: NULL
          rate: NULL
         total: NULL
 RecordingFile:
   IncomingDid: NULL
      ServerIP: NULL
      SourceIP: NULL
  IncomingPlan: NULL
      fullcost: NULL
 wholesaleRate: NULL
wholesaleTotal: NULL
  incomingRate: NULL
 incomingTotal: NULL
includedMinutes: NULL

Here is leg 2 which represents the outgoing call
            id: 100561916
      calldate: 2019-11-14 05:32:48
          clid:
           src: blankedOut
           dst: 18004312121
      dcontext: usa_customer_out_full
       channel: SIP/opensipsout-00109ad2
    dstchannel: SIP/verizonDirect-00109adb
       lastapp: Dial
      lastdata: sip/verizonDirect/18004312121
      duration: 4
       billsec: 4
   disposition: ANSWERED
      amaflags: 3
   accountcode: testAccount
     userfield:
      uniqueid: 1573727559.1233080
   destination: USA.
          cost: NULL
          rate: 0.0136
         total: 0.00090666666666667
 RecordingFile:
   IncomingDid: NULL
      ServerIP: blankedOut
      SourceIP: NULL
  IncomingPlan: NULL
      fullcost: 0.00090666666666667
 wholesaleRate:
wholesaleTotal: 0
  incomingRate: NULL
 incomingTotal: NULL
includedMinutes: NULL

So far everything is fine, but once I run the same call on the Asterisk 17 server both legs get combined, which means I cant bill for both legs if neccessary, here is the CDR

            id: 100562375
      calldate: 2019-11-14 10:41:41
          clid:
           src: blankedOut
           dst: 18004312121
      dcontext: usa_customer_out_full
       channel: SIP/opensipsout-00006cfb
    dstchannel: SIP/verizonDirect-00006d02
       lastapp: Dial
      lastdata: sip/verizonDirect/18004312121
      duration: 4
       billsec: 4
   disposition: ANSWERED
      amaflags: 3
   accountcode: testAccount
     userfield:
      uniqueid: 1573728092.28103
   destination: USA.
          cost: NULL
          rate: 0.0136
         total: 0.00090666666666667
 RecordingFile:
   IncomingDid: NULL
      ServerIP: blanked out
      SourceIP: NULL
  IncomingPlan: NULL
      fullcost: 0.00090666666666667
 wholesaleRate:
wholesaleTotal: 0
  incomingRate: NULL
 incomingTotal: NULL
includedMinutes: NULL


By: Benjamin Keith Ford (bford) 2019-11-18 11:12:52.754-0600

Can you explain what fields are wrong and what values you would expect them to be? If there is a problem with the CDRs being combined, can you utilize other applications such as ForkCDR[1] to determine billing?

[1]: https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification#Asterisk12CDRSpecification-ForkCDR
By: Asterisk Team (asteriskteam) 2019-12-02 12:00:02.540-0600

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines