Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate targeting other application in USSD Collect menu #243

Open
otsakir opened this issue Oct 18, 2017 · 4 comments
Open

Investigate targeting other application in USSD Collect menu #243

otsakir opened this issue Oct 18, 2017 · 4 comments

Comments

@otsakir
Copy link
Contributor

otsakir commented Oct 18, 2017

It may make sense to be able to target another USSD application from a USSD menu instead of a module inside the application. Keep in mind that Restcomm parameters may not be exactly the same when an app starts or when it is continued and this may break things.

@JonDiDoe
Copy link

the interest of this feature are:
firstly: not to open a lot of shortcode but only one, so the client does not have to remember a lot of shortcode but only one
secondly: you can divide an app into several smaller apps, it's easy to maintain them than to maintain a huge big app

@FerUy
Copy link
Contributor

FerUy commented Oct 22, 2017

@otsakir

It may make sense to be able to target another USSD application from a USSD menu instead of a module inside the application.

Good idea. But instead of another USSD application I'd rather targeting another type of project: block. A block would comprise a special type of RVD project that would contain all verbs (including the ones for USSD, voice, SMS), and could not be assigned to a number. Of course, it should have the ability to go back to the original application. Furthermore, it would avoid having enormous amounts of USSD RVD projects, which would turn out difficult and confusing to manage.

@JonDiDoe

firstly: not to open a lot of shortcode but only one, so the client does not have to remember a lot of shortcode but only one.

Correct, and it's the only way possible, as you can't jump/interact between different TCAP dialogs. Besides, the user can only have one open USSD session at a time.

secondly: you can divide an app into several smaller apps, it's easy to maintain them than to maintain a huge big app.

100% agreed. The block type of project goes hand-in-hand with this idea.

@JonDiDoe
Copy link

There may be a way to not open a new session, ie to jump between modules of different projects.

Option 1: on a "ussd collect" then on the drop-down menu "continue to" we can choose the project and the module in this project on which it is worth the jump. Maybe put 2 drop down menus, the first to choose the project and the second to choose the module.
Option 2: Use URL for jumps, type of "http://192.168.0.3:8080/restcomm-rvd/services/apps/APcb0b0b052d8e41b8b8a728361a7e3eca/controller"

The session could continue in the new project, I suppose.

@otsakir
Copy link
Contributor Author

otsakir commented Nov 2, 2017

@JonDiDoe , jumping between applications is not only about being able to target the module 'foreign' application modules. Modules DO have some sort of interface i.e. make some implicit assumptions in terms of state (transferred on action URLs). For example a moduleB-2 of application B uses an application variable set by moduleB-1. This state stays consistent because the designer of the application makes it so. For the outside world (such as other applications are) application B is partly a black box. We can assume that it starts with under link like .../APplicationB/controller and that it respects parameter contracts of Restcomm requests but other bets are (and should be) off.

So, back to the example what happens if you just target moduleB-2 from moduleA-1 of another application A. A does not know anything about B's variables.

There is some sort of session but this has not to do with USSD. It's RVD's.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants