RestComm / visual-designer

Restcomm Visual Designer
http://www.restcomm.com/
GNU Affero General Public License v3.0
4 stars 15 forks source link

Push SMS in RVD USSD projects #61

Open otsakir opened 7 years ago

otsakir commented 7 years ago

From @FerUy on October 29, 2015 18:11

As it is contemplated for voice project, RVD should add a push SMS option for USSD projects. It's a widely used feature in classical USSD projects (e.g. the result of a monetary transaction should be sent by SMS rather than thru USSD, as it would likely take longer than the USSD single interaction timeout and would be stored in the user equipment either).

Copied from original issue: RestComm/Restcomm-Connect#588

otsakir commented 7 years ago

From @deruelle on November 9, 2015 14:25

This should be factored in the RVD future refactoring

otsakir commented 7 years ago

Hi @FerUy,

You mean that one should be able to send an SMS from a USSD application. Correct ? Indeed, RVD misses such an element. I also think that this is not supported at the RCML either. @gvagenas ?

Also, @FerUy, can you please briefly give an example on the use case with USSD timeout you described? If i got this right, it may occur that restcomm/RVD takes too long to build a USSD response because the application operation takes too long (e.g. a monetary transaction). In that case it's good practice to make the application should also send an SMS to the mobile device to make sure the user got the message. Is that correct ?

otsakir commented 7 years ago

From @FerUy on January 20, 2017 13:42

@otsakir exactly, you got it right.

A use case that is very common: Top ups (recharge prepaid subscriber's accounts). Not only the interaction with the online charging system may take time and it's better to close the USSD session, release resources and send an SMS when the time is right (which also has the advantage of store and forward in case of failure), but as a security notification for either the retailer and customer (they both get the same transaction id, so the customer is sure he's not been cheated). All mobile financial services have similar behaviours regarding receipts/bills notifications, and SMS is better for that (as it is also stored in memory).

Another one: SIM activation via USSD. The process always takes some time (1-2 minutes or more), so depending only on USSD to notify a successful or failed transaction is inconvenient.

All in all you got it right from the beginning, just giving you some more examples (there are more).

Thanks

otsakir commented 7 years ago

From @FerUy on January 20, 2017 13:48

Oh... I forgot another one I'm working for a lot @otsakir: location services in cellular networks. To retrieve current geographic information of the user equipment, positioning methods take some time (30 seconds in average for triangulation and processing information), so it's better also to release resources taken by the USSD session and later send the SMS when the network returns the location information back to Restcomm. This location information could also be tied to mobile advertising for example, then more than one SMS could be needed (one for the location information itself, another one for other kind of related info).

otsakir commented 7 years ago

Thanks for the feedback @FerUy. Let me discuss this with @gvagenas to see what can be done in the context of a USSD application.

otsakir commented 7 years ago

From @FerUy on January 20, 2017 13:54

You're welcome @otsakir, anytime.

otsakir commented 7 years ago

From @gvagenas on January 20, 2017 14:0

@otsakir USSD application is an extension of the RCML so no worries to break any spec if we add SMS for USSD apps. If SMS in USSD applications make sense and there are use cases where we need this, I am fine to support this. To support SMS in USSD applications we need support from Restcomm side besides RVD. I created Issue #1730 for this and provided label "Help Wanted"

FerUy commented 7 years ago

@otsakir @gvagenas @deruelle @abhayani, just for your information we are currently dealing with a very important prospect that is requesting this feature to be implemented.