Envox Developer Blog

TATAA!! Error is solved. Our developer found the problem. The Envox (.NET 1.1) is not compatible with Axis 1.1 or Axis 2.0 (strange!). This is a a problem with .NET, as envox mentioned. We had to rebuild the wsdl. Now it works. Sad but true, it has some serious disadvantages if a system like envox runs on windows. It would be great if envox could also deliver a linux solution. I am sure this would increase the performance and stability dramatically. Maybe envox will turn away from windows in future…

Ok, I think we have to solve the problem by ourselve. We should ask some web developer with more SOAP and .NET experince.

The solution from envox is not working. We still can not communicate with our webserver.

Envox tries to find the error, but is still not successfull. We showed the wsdl to envox. It seems to be correct. No error was found. The .NET problem is still open.

we have some t serios troubles with the wsdl communication between envox and our soap engine. Nothing works, so we decided give the envox support root access to our system. I don’t know why, but the were not able to establish a vpn to our server, so accepted the teamviewer, which was the proposal of the german envox partner, bressner.

This was the solution:

I connected to customers machine with Teamviewer but all I can see is black screen. We tried from 3 different machines, and all we got is black screen.

We think we identified customers problem. The customers WSDL document seems not to be compatible with .NET 1.1 which is what SCP 7.2 supports. Tried using command “WSDL.exe voiceService.wsdl” on both .NET 1.1 and .NET 2.0 Frameworks, here attached. The .NET 1.1 version of WSDL.EXE complains and cannot generate error free WSDL, see the file.

A workaround to try is to temporary move EnvoxStudio.exe.config and EnvoxEngine.exe.config files from Envox install directory and restart Engine and Studio and try again…. or change number in those files to “v2.0.50727“ (this forces Envox to use .NET2.0 which is not supported!!!)

Other solution would be to rewrite webservices against .NET 1.1
Cool,  I hope this is the solution of our problem.