-
Notifications
You must be signed in to change notification settings - Fork 15
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
Comments
the interest of this feature are: |
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.
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.
100% agreed. The block type of project goes hand-in-hand with this idea. |
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. The session could continue in the new project, I suppose. |
@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. |
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.
The text was updated successfully, but these errors were encountered: