search

RestComm / Restcomm-Connect

The Open Source Cloud Communications Platform
http://www.restcomm.com/
GNU Affero General Public License v3.0
244 stars 215 forks source link

Misleading CDR status 'completed' when updating incomplete calls #2423

Open FerUy opened 7 years ago

FerUy commented 7 years ago

Tied with issue #2162, when updateInCompleteCallDetailRecordsToCompletedByInstanceId applies, 'completed' is written in the CDR status field (whenever PR #2422 is merged, up to this moment instead is written in uppercase). This is misleading.

For example and just to name one, connected with the Zendesk ticket that originated issue #2162, if a USSD RVD project depends on an external service, whenever the latter is in bad shape, updateInCompleteCallDetailRecordsToCompletedByInstanceId will very likely apply and the problem would be "hidden" in the CDRs (this could apply to any kind of project, not only USSD). Likewise, CDRs would tell a different story from reality, as a large % of them would tell that the service (voice call, USSD session, etc.) was completed, when actually it didn't.

We should choose another word rather than 'completed'.

FerUy commented 7 years ago

Complementing information provided here, as commented in already merged PR #2422. The origin of Zendesk ticket #34316 comes from the fact that right now and since the beginning, the customer's 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 https://github.com/RestComm/ussdgateway/issues/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.