Claudio

We are already in the 6th week since last message, and over 3 months since our first notification of this bug, and still no update, neither a workaround. We are bleeding here and anxiously waiting for bugfix of a full payed enterprise WIN 2008 version. Our patience has almost ended. What can be the reason of this taking so long? Some other software of NCH has been updated twice already. By the way... the bugged software is still available for download and purchase without any warnings about this important issue.

thanks for reply DJ.

We are waiting almost 2 months for this very important bug fix. When is the fixed version expected to be released?

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!

Isn't there anybody out there who has the Windows Server 2008 installed with IVM, just to try out an simple command line "ivm.exe -outbound xxxxxxxxx" ??? This takes a minute to test. This is a serious bug of an full payed premium enterprise version. Only because of this, we were not able to switch to WIN 2008 to production, and have to run on WIN 2000 that reached end of life cycle this week in a production environment. Now we are about to switch to another software. Notified support and bug report more than a week ago, got a contact from NCH Support then, but still no help or comments for any workarounds or planned fixes.

Has anyone tested the IVM command line option (e.g. ivm.exe -outbound 63636363) within an WIN2008 Server environment? We have been using IVM for quite a long time with WIN2000 (IVM 2.43 and IVM 3.0 Pro and Enterprise since 2005). Because of Win2000 End-Of-LifeCycle we have to switch to WIN2008 now and bought the IVM 5.03 Enterprise Edition. Everything is set up, and ready to go to production environment. But when using the command line option, for example ivm.exe -outbound 63636363 (or any other option), the ivm.exe returns error: -2. When launched within a program by shell it returns an "abnormal execution problem". We made a bug report that has been opened by IVM.exe itself and are now waiting for reply. Did somebody had experience with the command line options in WIN2008? Can somebody test command line on WIN2008 if available to see if it is an WIN2008 issue? Thanks

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.

TO ALL!!! VERY IMPORTANT TO KNOW, MIGHT BE AN SECURITY ISSUE DEPENDING OF 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 immediatly! When running on multiple line with concurrent connections, 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!!!!!!

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.

TO ALL!!! VERY IMPORTANT TO KNOW, MIGHT BE AN SECURITY ISSUE DEPENDING OF 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 immediatly! When running on multiple line with concurrent connections, 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!!!!!!

Hi Christopher, maybe the comISDN driver would help you. Some modems are compliant to TAPI, but their drivers are a total mess! ComISDN is not free of charge, but at least it has a free-trial that might help you to try out, and figure out your problem. They have a real great support. http://www.comisdn.com/tsp/download.htm ComISDN TAPI Service Provider - Version 4.0.64 (CAPI).

Yep lacalacaloca!!! You are absolutely right. I think too they need to think about it. But I am sure that an implementation of this feature will raise the price of the IVM. But I am still a good friend of the approach we did. It was hard to find the right way, and finally it was very simple and straight forward. Hope some IVM-consultants won't get this info and sell it later:))) Well... We have a set of OGM-folders, something like "ogms_fr"(french),"ogm_us"(english),"ogm_de"(german), etc... and those folders are all an absolute copy of the other, just the wav-files inside each folder have been recorded in different languages (with higher quality). We totally avoided using systemprompts, just made everything via OGMs. So we have lots of OGMS, but it keeps all very structured, so it is easy to manage. If something changes, we change the folder of one OGM, copy it to all others, and simply overwrite the recordings of the other languages. So, when somebody calls, there is a Language-Switching-OGM, that can be either be switched by menu-pressing by the caller, or it switches automatically by recognizing the called line-number. So it switches to the welcome-ogms that are in their respective ogm-language-folders. Well, well... the IVM is very buggy, and I think it is not fair: We spent weeks figuring out how to avoid some bugs, such as plugins aborting because the OGM has finished first, or the language-functionality, and even chopped recordings due to driver and hardware problems. We tested DOZENS of modems. Spent nights with coffee, trying to get steps further. Every important issue I've found I've posted in this forum (just to avoid other users of spending as much time (and coffee=)) as I did in finding a suitable workaround). But after all I think the IVM is still a very powerfull solution because of its flexibility, and I really think that a fine working language-plugin, or language-selection-option at least for the most common languages, would boost the softwares popularity.

Hi!!! I really don't think they will fix it. The problem is that the "number read out functionality" is difficult to achieve for different languages, because the language constructions are different for each other. For example let's take a look at the number 194: English: First the hundreds are spoken, then the tens, and finally the units. So the system says: "one hundred"+ "and"+ "ninety" and then "four". But in German the units are spoken before the tens: something like "one hundert"+"four"+"and"+"ninety". More difficulties can be found in french, where they say something like "one hundred"+"four times twenty"+"fourteen". As you can see... for each language the NCH-Programmers should have programmed different types of algorythms, and fixed language-option to choose in the OGMs, in order to have the numbers read out correctly in the right sequence. For this reason, multilanguage functionality of english, french and german just by copying folders can be excluded by itself! Some languages like spanish and portuguese are very similar to english, so it might work there. Conclusion: The different requirements of your needs for "reading numbers out"-functionality must be analyzed first, in order to decide in which way to go. In my personal case we had a simple read out of a fixed number of digits, so it just needed to be read out digit by digit, so I did it with simple OGMs, playing %digit1%.wav then &%digit2%.wav etc. But you should be able to find a soultion for your needs too. Good luck to all!!!

Ah si... y otra cosa... si el problema es un loop indefinido (que es un problema que tb teniamos), le metimos a cada OGM la repiticion de maximo 3 vezes, y luego AND THEN "HANG UP IMMEDIATLY". Eso nos soluciono por lo menos el problema del indefinite loop, por que asegura que el IVM cuelga la llamada, si no hay ninguna entrada hecha por el llamador.

Hola Horacio... te cuento que si he tenido algo similar, y tambien hemos tenido unos otros problemas con el IVM que es V 3.00... pero caso tuyo puede depender mucho del hardware que estas usando. la cosa es que el sonido de colgar el telefono (end-of-call tone) no tiene un standard mundial (mira http://nch.invisionzone.com/index.php?showtopic=9487 ), y dependiendo de como es el hardware, se puede tener problemas al usar lo en la red en ciertos paises. Primero de todo yo jugaria con la configuracion en la seccion del IVM SETTINGS->DEVICES-> ADVANCED LINE SETTINGS por ahi tienes las configuraciones que te podrian ayudar. Pero recuerdate de anotar la configuracion inicial. En nuestro caso nuestro driver de la placa isdn alemana no funcionava con el IVM con la placa AVM ISDN-Controller B1 para nada, ni tocava los wavs, menos colgava. Solo cuando pusimos el driver de COMISDN todo funcionó de una, eso acabó con todos nuestros problemas. Pero te tengo que decir que fue en la red de telefono digital en Alemania. No se si te funcionaria en Uruguay. De todas formas lo puedes testar, si no tienes exito con la configuracion en el IVM . El comISDN es un Driver TAPI, tiene un Demo que es valido por unos 14dias creo. http://www.comisdn.com/tsp/download.htm Nosotros usamos el ComISDN TAPI Service Provider - Version 4.0.64 (CAPI). Nosotros luego lo compramos, y desde entonces todo quedo estable. El soporte es bastante bueno, pero en ingles o frances. Abrazo desde Rio !!!! Y suerte!