Add dialog duration to SS7 statistics API

[FerUy]

Objective: add calculation of dialog time periods from establishment (begin) to release (end).

[faizann]

The dialog time from begin to end will be misleading as there are also CONTINUE dialogs in between. What type of insight can we gain for time between begin/release?

[FerUy]

Hi @faizann, thanks for the good question. The rationale for registering the whole dialog average/max/min periods are mainly for traffic quality of service and accounting purposes (e.g. the holding time of the Erlang model), then also for performance. For instance, if USSD dialogs takes too long in average, they will impact on performance and might lead to an investigation of poor application design or a problematic external service. This can also explain customer's why they are being billed for an X amount in a metered pricing model and push them to better designing or investigate point of failures, etc.

[faizann]

In case of USSD I guess the app could easily keep track of how long the dialog was open. Anyway, the RTT of TCAP dialogs will rely on variety of factors including network/type of application and even the radio coverage quality of a handset. An application level of such stat might make more sense as then the context is better known for such statistical/billing analysis. I once had a similar idea but after looking at variables that can affect such RTT, it didn't seem useful information to me without context of the application.

[FerUy]

@faizann, sure, but those are not the rationale of this issue. To make the long story short by touching only one topic, dialog duration statistics become important for both customer and vendor on a metered license scheme in products like USSD Gateway (where dialogs can vary a lot and introduce several impacts, either from a commercial or technical point of view).

[faizann]

Yeah that is true. It will apply in that case.

[vetss]

we do not need of this issue now, will not implement