IMPORTANT WHEN USING COMMAND LINE AND VARIABLES FOR OUTBOUND CALLS

[Claudio]

TO ALL!!! VERY IMPORTANT TO KNOW, MIGHT BE AN SECURITY ISSUE DEPENDING ON APPLICATION:

 

We just have experienced some problems with IVM, we thought it was an threading problem. Conclusion: when using command lines with -set be aware that all the vars that are set by "-SET" are GLOBAL, NOT LOCAL!!! And they are set immediatley! When running on multiple line with concurrent connections or creating outbound calls by command line during an already ongoing outbound call created just a few moments before, it will use the last vars that have been set. Example.: calling ivm.exe per command line D:\Prog\ivm\ivm.exe -outbound 12345 -set id=102

using the SQLplugin for an "select * from table where id=%id%" YOU MUST BE AWARE THAT VAR ID=102 WILL BE OVERWRITTEN, as soon as another command line instance is being created during the first call!!! For example with an "D:\Prog\ivm\ivm.exe -outbound 12345 -set id=110" just some seconds later. If the Plugin of the 1st call hadn't started, the id will be overwritten (THE VARS ARE GLOBAL and are valid for ALL CALLS). If the IVM-Call is going to give data back to the caller, the first caller might hear information destined to the second caller!!!!!! Still don't know how to make the vars LOCAL.

[Claudio]

TO ALL!!! VERY IMPORTANT TO KNOW, MIGHT BE AN SECURITY ISSUE DEPENDING ON APPLICATION:

 

We just have experienced some problems with IVM, we thought it was an threading problem. Conclusion: when using command lines with -set be aware that all the vars that are set by "-SET" are GLOBAL, NOT LOCAL!!! And they are set immediatley! When running on multiple line with concurrent connections or creating outbound calls by command line during an already ongoing outbound call created just a few moments before, it will use the last vars that have been set. Example.: calling ivm.exe per command line D:\Prog\ivm\ivm.exe -outbound 12345 -set id=102

using the SQLplugin for an "select * from table where id=%id%" YOU MUST BE AWARE THAT VAR ID=102 WILL BE OVERWRITTEN, as soon as another command line instance is being created during the first call!!! For example with an "D:\Prog\ivm\ivm.exe -outbound 12345 -set id=110" just some seconds later. If the Plugin of the 1st call hadn't started, the id will be overwritten (THE VARS ARE GLOBAL and are valid for ALL CALLS). If the IVM-Call is going to give data back to the caller, the first caller might hear information destined to the second caller!!!!!! Still don't know how to make the vars LOCAL.

 

 

After a sleepless night with this issue, I've just found a good workaround for this problem. If interrested, please post here. I'am too tired now to write everything down here.

[kengurukleo]

After a sleepless night with this issue, I've just found a good workaround for this problem. If interrested, please post here. I'am too tired now to write everything down here.

Hi!

A have same problem...

Help pls...

[kathyclem]

Hi!

A have same problem...

Help pls...

 

 

Yep, let me know the solution you came up with. The only thing I can think of to to have one run as a batch file, then another as a different batch, etc.

[Claudio]

Yep, let me know the solution you came up with. The only thing I can think of to to have one run as a batch file, then another as a different batch, etc.

 

 

Sorry guys... didn't get any notification about this issue. Just saw it now. Maybe it's too late. But here I'am posting you one solution that worked for us anyway. We used a table in our data base to get an interface between IVM and the application that was triggering the "outbound call" to get it done. Here a simple quick solution. This example will pass variable named %say_digits% to ivm:

 

1. Create a table named ivm_outboundcalls. Add a field named outboundnumber that will be used as the reference key for the SQL in the IVM SQL-Plugin. Also add the fields for the data you need to pass to ivm. In our example it would be something like create table ivm_outboundcalls with fields id(autoincremental int), outboundnumber(varchar), say_digits(varchar).

 

2. Just before making the outbound call, make an insert to that table from your application. For example, if IVM should say 0999 to the call receiver, make an insert as follows: 'insert into (id, outboundnumber, say_digits) values (null,'1234567','0999');'

 

3. Just right after that, trigger the outbound call with the shell "ivm.exe -outbound 1234567". Notice that the number 1234567 will be available to IVM through the %cid% variable, and this number will be the reference for selecting the right row in the SQL-Plugin).

 

4. In the outbounding call OGM put an SQL-Plugin to work, and make the SQL with the %cid%: select say_digits from ivm_outboundcalls where outboundnumber='%cid%' order by id desc limit 0,1; The PLUGIN will pass the data to the ivm-variable %say_digits%.

 

5. Use the %say_digits% in the OGMs you need with the readoutnumber function.

 

You can pass any variable data you want. Just add the field to the table and edit the SQL. Be careful not to use a name that is already used within IVM by default, such as %cid%.

 

Hope it helps! Good luck!