Issue #76: Save Ussd response string to CDRs

[abdulazizali77]

@vetss Sergey, this is an incomplete proposal for saving Ussd response strings to the CDR.

• Add UssdString property with getter/setter to USSDCDRState
• Add new configuration flag to enable disable saving of response strings. Add new cdrNavigationSave property with new getter/setter to UssdPropertiesManagement

Is this approach correct? There are obvious things missing here of course, reading and saving the new config (additionally the duration changes got added by mistake)

[vetss]

Hello @abdulazizali77

I am little bit confused.

1) you said that the update for "Ussd response string" but I see there records like setDialogStartTime. Does this update also for another staff ? Also if you have added a new functionality then we need to update of CLI, GUI , manual

2) "Ussd response string" - can you explain a desired behaviour when we have a USSD dialog that contains several Unstructured messages. Are you going to include first, last or all Unstructured reponses ?

[abdulazizali77]

@vetss sorry Sergey, the addition of setDialogStartTime was a mistake (from #72 ) The desired behaviour is to be able to capture USSD menu responses in a log, for example *1111#,2,3,4,1,3
*1111# being the service number 2,3,4,1,3 are the sequence of choices/responses which the user make/send

@croufay Charles, is my description of the desired behaviour correct?

[abdulazizali77]

@vetss Sergey, In regards to your comment https://github.com/RestComm/ussdgateway/issues/72#issuecomment-329573009 , I agree with minimization of effort, but im not entirely sure if the team has completely agreed on the development/delivery of this #77 feature. Im of the opinion that everyone will want to go forward with it if the effort is minimal, which is why i put up this hasty #77 PR to get your opinion whether my approach is correct or not.

In regards to CDR schema changes, one compromise i can think of is that we can make both CDR schema changes necessary for both features in #75 and leave out the functional changes for #77 until later, (so that we wont have to have multiple schema updates) what do you think?

@marca56 @deruelle @croufay @FerUy Guys, appreciate some comments on the status of this feature

[vetss]

@abdulazizali77

we have a CDR field "serviceCode" that is filled by a service code like *1111# for PULL and with a first message from application server for PUSH. I think we need to add a new separate fileld for "2,3,4,1,3 are the sequence of choices/responses which the user make/send" and we do not need to add a configurable option for this (it does not consume more resources).

Concrete format of 2,3,4,1,3 is term of discussion of everyone who has an experiense.

PS: please avoid of usage of string+"xxx"+string, let's use StringBuilder fopr this.

[abdulazizali77]

Noted @vetss In regards to https://github.com/RestComm/ussdgateway/issues/72#issuecomment-329732844 I will:

• Make table changes to Schema for the new UssdString column,
  • Should we rename the interface to get/setResponseString and table column RESPONSE_STRING? Or is get/setUssdString and table column USSD_STRING adequate/appropriate ?
• Remove the setUssdString call in onProcessUnstructuredSSRequest
• Remove new configuration from UssdPropertiesManagement
• Use StringBuilder for catenation
• Update docs for Schema 6.3
• Test CDR db and plain logging locally for both features
• Potentially provide a patch to GSS to test

[vetss]

@abdulazizali77 I can not advise in the best name of a ResponseString . SubscriberResponseString ?May be @croufay can give an advice. Anyway we need to provide a clear description of this parameter and serviceCode parameter. Please check if that parameter description fits to my description in my comment of this issue (It contants not only a serviveCode as I found).

[abdulazizali77]

Committing the changes in this PR #79 , so closing this