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-0600 | Date Closed: | 2019-12-02 12:00:03.000-0600 |
Priority: | Minor | Regression? | |
Status: | Closed/Complete | Components: | Applications/app_cdr Applications/app_dial |
Versions: | 17.0.0 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Debian 9 | Attachments: | |
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 |