fix: resolve parseCDR error and add concatenated CDRs update #37
Conversation
|
Hi @TungChiaMing , Thanks for the PR! |
|
Hi @TungChiaMing , I have tested this code via this senario: https://free5gc.org/guide/Charging/setting/#3-test-with-ueransim I used I'm sorry but can you provide your testing process?😣 |
Hi Alonza0314, The decode function used by the Webconsole may not be this CHF with fix error in your environment. Did you replace the go module of Webconsole by using 'replace'? the decode function of CHF will be used in the webconolse. |
Oh, I didn't notice it. Thanks a lot. I will replace and test it now.❤️ |
| {"intTest4", -128, "020180", ""}, | ||
| {"intTest5", -129, "0202ff7f", ""}, |
There was a problem hiding this comment.
Why these two test cases be deleted?
There was a problem hiding this comment.
Since I remove 2’s complement conversion so these two test cases will not be passed.
The function parseInt64 in the file cdr/asn/ber_unmarshal.go originally handles the 2’s complement conversion to deal with the negative value.
If the first byte value greater than 127, the function will convert the input to a negative number.
This will eventually cause the parseCDR error because the next value will become negative.
The byte value here is the cdrBytes, which is from the asn.BerMarshalWithParams with input CHF ChargingRecord. (Actually, removing the 2's complement conversion may have issue in the online charging because the value may become negative but I didn't notice it.)
There was a problem hiding this comment.
removing the 2's complement conversion may have issue in the online charging because the value may become negative but I didn't notice it.
This means that the online charging CDR file is not correct if we merge this PR?
There was a problem hiding this comment.
Not sure, but we’d better test the online charging first.
There was a problem hiding this comment.
Hello @andy89923,
I have tested the online billing functionality and found no issues. During the testing, I observed that online billing uses the Quota variable to manage the remaining traffic quota rather than directly deducting available traffic from the CDR. As a result, there are no concerns about negative cdrBytes values.
Based on this, we can proceed with merging this PR.
There was a problem hiding this comment.
Hi @TungChiaMing ,
Thanks for your testing result!
@ianchen0119 FYI!
Fix Two Issues in CHF When Processing CDR
When the traffic exceeds a certain threshold (around 700KB), the Webconsole displays the error:
[ERRO][WEBUI][BillingLog] parseCDR error when unmarshal with params: offset > next,and the usage data cannot be displayed on the Webconsole.
According to TS 32.297 Section 5.2 "File Format Principles," a CDR file contains multiple CDRs. However, in CHF, charging data is updated to only one CDR. This causes the
cdrByteslength ininternal/sbi/processor'sdumpCdrFile()to grow increasingly larger, eventually exceeding theuint16range and resulting in an overflow incdrHdr.CdrLength.