Module '3CX.com.vxi'. Error ID 210.

[Jernau]

I've used the VAD to design an IVR which does quite a few things, but which is failing at random with "Module '3CX.com.vxi'. Error ID 210." in the 3CXIvrServer.log file.

My IVR has three main sections (which i've created as components to keep thing simpler to read) and each section has a loop, a request for user input, a webservice call to validate the entered codes, some database logging, and some text to speech. All of this works (really well infact, the VAD is an awesome piece of software) until the IVR just stops with the 210 error.

I've googled and have found another post on this forum relating to this error which suggests that there is a limit of the number of components that an IVR can process in one session, but that post is from two years ago.

http://www.3cx.com/forums/3cx-com-vxi-error-id-18414.html

Could you let me know if this component limit (500 for release, 250 for debug) is still present in the VAD runtime and if this is the only thing that error 210 could be, or is there some other problem that might be causing it?

If this is the case i'll have to redesign the IVR to use more than one extension (as suggested in the other thread) and do transfers between extensions to get round this (bit disappointing if so).

We're using VAD version 3.0.3853 and 3CX system 11 with SP2 (SP3 is waiting to be installed).

Thanks

 

[VAD_Support]

Hi,

That limitation is still present. If you use the Loop component, then you may experience this problem.

In order to bypass this limitation, you should deploy the release build to production environment, which extends the limitation a bit. But if you still have problems, then you will need to redesign some parts of your callflow. The key is trying to avoid too many loops, or reduce the quantity of components inside the loop. So for example, if you can eliminate some components from inside the Loop, you will get it better. A possible way of doing this could be concentrate many function calls into a single external code execution component, which could be doing everything. You would have to make some coding, but the callflow will be simpler. That is something you could try before making big changes.

Kind regards,

 

[Jernau]

Thanks for the reply

The structure of my IVR is as follows, and each Loop involves User Input, webservice validation of the input, then either progression to the next Loop or return to the start of the current one (if validation failed).

Loop #1 has 15 components (7 of which are writes of a log to the database).
Loop #2 has 12 components (5 are logs).
Loop #3 has 13 components (7 are logs).

I could remove the log inserts but really they need to be there for audit purposes.

My main problem is going to be that once a caller reaches Loop #3, the caller needs the option to go back to Loop #2 to enter a different account number, which will then progress through Loop #3 again. Whatever i do i'm not going to be able to simplify the call flow to avoid the 500 step limit.

So, if i can't increase the 500 limit on a Release IVR, will the suggestion from the other forum thread to use call transfer to reset the step count work? I have one flow in my project at the moment so i'll add another two making one for each loop, and then chop up what i have to redirect between these call flows (i.e. their different receptionist numbers). Can you confirm that when the call is transferred the step counter is reset? Are the values of the variables that i've declared in the project maintained after a call transfer?

And as an aside i've learned quite alot today. I now understand how the VAD creates ASPX files and also VXML files which are handled by the TcxIvrHandler, and how errors are caught by the TcxUnhandledException module. What i can't figure is where the 500 step limit arises from - i can't see it being a HTTP page redirect limit - so is it just there as a resource limit within TcxIvrHandler, or perhaps to stop an infinitely looping IVR from crippling the server? 500 seems a very low number, and it would be nice to increase it (perhaps to 5000), but if it's a hard fast limit then i'm happy to work with it

Thanks for all your help

 

[VAD_Support]

In regards to the logs to the database, maybe you can simplify it to make a single log containing all the information you need. That way you could reduce the quantity of components into each loop.

You can also transfer the call between different callflows, and that will reset the counter. The counter is the quantity of pages fetches from the web server, and is hardcoded into a library used by the 3CX IVR to execute VoiceXML, so it can't be easily changed by 3CX. This counter is per call, so it is reset when you transfer it to another callflow.

But, if you transfer the call between callflows, the variables defined during the first callflow will not be valid on the second callflow. They are 2 different calls, so you need to use another mechanism to send the variables values to the second call. For example, you could save them into a database and then retrieve them back.

Hope the information helps.

Regards,

 

[Jernau]

I've built a test IVR with two call flows, and have confirmed that after a call transfer all variables are reset, so I'll be adding a new db table to store state for each call - good suggestion!

I do think that the 500 step limit is a serious limitation in the VAD runtime though - could an increase (or even a removal) of this limit be logged as a future feature request? I'd also suggest this is included in the documentation, because if i'd known about that and the call transfer workaround i'd have approached the design of the IVR differently.

Either way I think i have everything now to achieve the desired result, so big thanks for all of your help!

 

[VAD_Support]

Please submit the suggestion here:
https://apps.facebook.com/threecxideas

Thanks!