Expose Completed USSD Dialog/Session statistic

[abdulazizali77]

@vetss Sergey, there is a need to know the total number of completed USSD dialogs.

• It seems that for all instances where RecordStatus.SUCCESS cdr is saved, there is no corresponding statistic incremented. However, when USSD Dialog fails with RecordStatus.${FAIL|ABORT|*} there is usually a corresponding failure statistic.
• As a workaround, can we derive Completed dialog session statistic from the total Push and Pull statistics?

Should we add a new Completed dialog statistic or would it suffice to derive it from some preexisting statistics?

[vetss]

Hello @abdulazizali77

do you mean "statistics" as http://documentation.telestax.com/core/ussd/USSD_Gateway_Admin_Guide.html#statistics ?

If "there is no corresponding statistic incremented" we need to repare it. Can you make some monitoring may be to figure out which CDR types are not included into statistic. Is it reproducable at a low traffic so we can just test it ? Is it SIP or HTTP (or may be both).

[abdulazizali77]

Yes @vetss the USSD statistics, there exist *Established (dialog which was started), *InProcess (dialog still active), *Failed (dialog which ended with failure) Im not sure how to derive dialog ended with success Can we derive it from ProcessUssdRequestOperations + UssdRequestOperations ?

[FerUy]

hi @abdulazizali77 @vetss, let me give my 2 cents in this discussion...

See next some graphics which portray some use cases we deal with all the time in USSD.

Below, an example of PULL USSD with Restcomm-Connect acting in between the Gateway and the application:

So, back to your question:

I'm not sure how to derive dialog ended with success Can we derive it from ProcessUssdRequestOperations + UssdRequestOperations ?

That's a tricky one. We could indeed derive it from ProcessUnstructuredSSRequest MAP operation (for PULL USSD), but IMHO that would be simplistic and not cover every scenario. For example, we might send UnstructuredSSRequest MAP operation (inside a TCAP Continue message) to the user including information and expecting an input from the user. This is a very common use case (for example: account balance information is sent to the user and a promotional option to continue). If the user decides it doesn't want to go further, it closes the session (or times out by doing nothing) and we get a TCAP End or TCAP Abort message, no MAP operation included. So, philosophically speaking, is this a success ended dialog or a failed one? From the user perspective it might be a success (e.g. he just wanted his account balance information and didn't want to go further). So, in my opinion, there's not an easy straightforward answer... maybe we could decide a dialog ended with success in any case we don't receive a TCAP Abort message? (this is only from the SS7 perspective of course). Thoughts?

PUSH USSD is different... see below a graphic example:

Also and talking about statistics... I wouldn't use red colour for showing UnstructuredSSRequest MAP operations (USSD Various graph), as it might be confusing (we tend to associate red with failure or problems).

[vetss]

@abdulazizali77

*Established (for example DialogsAllEstablished) is how many dialogs are successfully established for a observed time interval. *Failed (for example DialogsAllFailed) is how many establishes dialogs are failed. We can say successed == Established - Failed , but the problem is that a dialog may be created in one statistic interval and succeded or failed in another interval (later). This means that dialog ended with success will be more or less correct for a big time statistic aggregation. If you want to get it for short interval (several seconds and even several minutes) it may give not exact results. If you do want this counter (dialog ended with success) with very exact value we need to add a new counter into USSD GW.

I can provide a funny example from statistic monitoring. We were monitoring a counter "Call drop rate" (CDR) for phone calls. It is calculated as CDR == "failed calls count" / "established calls count". If this parameter is 2-3% it is good then all is ok, if more then we make some checking. We monitored 60 minutes intervals. This works fine in daytime when there are many calls, but in the night it may give some strange results. 100% (when we have only one call and it is dropped) and even 200% (one call was started this statistic interval and another call was started at the previous statistic interval and was included into statistic results for that previous hour, both calls were dropped in the observed hour and we have 200% CDR).

[vetss]

Hello @abdulazizali77

do we need to do anything for this issue ?