Change CDR status in uppercase to lowercase for 'completed'

[FerUy]

Change CDR status to lowercase completed when updateInCompleteCallDetailRecordsToCompletedByInstanceId applies. This is for partially solving issue #2162 and related Zendesk ticket #34316. New issues will be raised to solve other problems mentioned in the concerning issue.

[abdulazizali77]

@FerUy Fernando, can we in the interim just set it to cleanedup instead of completed ? What do you think?
Potentially we can add the additional enum for CLEANEDUP later
Fernando, i think we should wait for George's comments on this, this has larger implications than the two line change

[FerUy]

OK @abdulazizali77, let's wait for @gvagenas input, but I certainly prefer cleanedup (or similar) rather than completed, as it would put completed and uncompleted transactions in the same category (this is why I created issue #2423 -and related #2424-).

[abdulazizali77]

@FerUy Fernando, from a customer point of view/process, are the statistics for calls already exported before any RC nodes are restarted (and hence cleaned up?)

Im trying to understand whether the call statistics before RC restart is important enough to analyze (i assume it should be!) after the restart. Obviously with all the statuses set to some identical value whether its COMPLETED or CLEANEDUP this would not be possible.

[FerUy]

Indeed @abdulazizali77, that's the origin of this (Zendesk ticket #34316). Right now and since the beginning, their IT department consolidates reports everyday and they have a list with a % of USSD sessions completed and another % of COMPLETED (in their case it's more due to external services in bad shape -answering slowly, generating timeouts, but not creating canceled status CDRs as they still don't have RC #2410 and #2411 and RestComm/ussdgateway#69 solved-).

So, it's important for them to have the proper metrics. Even after these aforementioned issues are solved, they will still eventually get some of these events (much fewer of course), so being able to discriminate a really completed USSD session from a cleanedup one is important from accounting and statistics perspective (and for us, from a monitoring perspective, as we use CDRs as a monitoring/debugging tool).

Furthermore, imagine a USSD session that while in-progress, an air time or data bundle is attempted to be purchased, and suddenly there is a problem (either in our system or the external service, or due to signaling congestion, or in the radio access). The user will very likely generate a call to customer service (which is expensive for the operator). Then, while in our system the CDR will tell completed, in the CRM from the prepaid or postpaid system it will tell otherwise. Got me better now?

[abdulazizali77]

@FerUy Thanks Fernando, what you described is exactly the scenario i imagined. But wouldnt it be more visible if we had:
in-progress-cleanedup for call 1 which was in-progress and completed-cleanedup for call 2 which completed
instead of both cleanedup for call 1 and 2?

[FerUy]

@abdulazizali77 I'd rather keep it simple, just with cleanedup (or similar).

[abdulazizali77]

@gvagenas George, Fernando confirms that from this specific customer perspective, setting cleanedup to calls that existed before RC restart seems to suffice.
What are your thoughts? How does this impact RC and other use cases?

[gvagenas]

@FerUy @abdulazizali77 to change state COMPLETED to completed is a minor change and you can proceed.

To introduce a new state cleanedup, is a different story and should be carefully designed before you proceed because it will have implications for other services that depend on CDRs, such as Conferencing, thus I believe we shouldn't proceed with the new cleanedup state.

Keep in mind that we are in the process of redesign and implement a new CDR service that will change everything in that space. In that regard, we should invest the minimum time on fixes for the existing CDR service.

[abdulazizali77]

thanks @gvagenas @FerUy , merged.

[FerUy]

Thanks @gvagenas & @abdulazizali77. For the other situation, I have already created #2423 ;)