3CX via VPN with RDS hosts (Terminal Server)

[Srdan]

Hello,
I most likely don't understand the thing as maybe I should, so please bear with me.
Couple of years back when we got 3CX unfortunately we got really bad consulting from an external company, and was said that 3CX should work as expected in our environment - which it does not for one reason: we have a site-to-site connection with our datacenter, and we access terminal servers on other side. And we use DATEV integration.
So, in order for 3CX to read the data from our software, it either needs to do VOIP or LDAP via VPN. Both are not allowed. Currently we only have 3CX client installed on our terminal server, to at least have calling from our software.
We are currently looking how to solve that, since next year our 3CX contract will expire and I got an request to solve the problem.
We were told by our datacenter to take a software that is compatible with ECSTA driver (like ProCall Enterprise), since it's possible to transfer data via VPN with ECSTA interface.
So this is the question: can 3CX be used in conjuction with ECSTA, to finally solve our problem of transferring the data via VPN?
Thank you.

 

[edossantos]

Not sure to understand the issue. Where do you have the problem? In the integration with DATEV? With phone calls? Can you elaborate a bit more on your architecture? Where you have the 3CX server, where you have the 3CX clients, where you have DATEV, etc?

 

[Srdan]

Hi,
thanks for the answer.
On our local network reside our workstations, 3CX server and telephones.
On a remote side (DATEV datacenter) reside our RDS server - with DATEV software and 3CX client. That allows us to call our customers by clicking at the number in the software.
The two sites are connected with a site-to-site VPN tunnel.
A limiting factor is that this tunnel can neither transfer VOIP nor LDAP.

Before we bought 3CX, we had ProCall. We were used to seeing callers NAME. Not only the number, but also the name. For which to work, 3CX would have to pull some metadata from our software. Not sure any more what ProCall did, but I remember it had some kind of interface with DATEV (I think it is called ESTOS Metadirectory).
Were we to have DATEV locally installed, there would be no problem. However the limiting factor is the VPN connectiong between us and the datacenter.
I was told that using ProCall (or XPhone), which uses CSTA-protocol, would allow us to have what we had before.
Upon reading about it, I found out that were we to buy another telephony service, like Openscape, we would have to implement ECSTA/ProCall/XPhone on our RDS for it to work.
So, now idea how 3CX fits into the whole thing, what the difference between Openscape+ProCall vs 3CX is... I wasn't here 5 years ago when the contract with 3CX (indirectly) was made.

What I currently care for, is making an educated and right decision in 2021 when our contract expires. If we can or cannot keep 3CX depends solely on the fact if we can implement it so that it works correctly (reading data from our software).

Additionally, we had huge stability issues, however I found out that my coworker, who is supposed to take care of the 3CX (it's not my area of expertise), actually missed the fact that v16 was released last year and that we almost went over the deadline. So now I am making it my own priority. v16 is online and currently no issues.

So in the end, that is why I am asking whether 3CX supports CSTA, as this is by my understanding, the only way to get what we want in our configuration.

 

[edossantos]

The integration with DATEV only runs in the 3CXPhone for Windows client. So, the Windows client is something that you need in order to see the caller name taken from DATEV.

Do you need CSTA to control the deskphones on the other side of the VPN from the 3CXPhone for Windows client in CTI mode?

 

[Srdan]

Well, it doesn't work. Windows client IS installed on the terminal server. We can dial from DATEV, but we do not get a caller-identification.
According to our specialists in the datacenter, CSTA is the only protocol allowed. And it is what is used by the solutions to transfer the metadata over the VPN connection.
They told us that for 3CX to read the data from DATEV (caller name), 3CX and terminal server would have to be "beside" each other, same or different network, but not like in our case, separated by VPN.
My understanding is like this:
In such case Procall or XPhone would be used to control the deskphones.
We would keep 3CX as a telephone server, our terminal server would have ProCall (or XPhone) installed, which would communicate via CSTA with 3CX. 3CX would communicate with our Snom 320 via CTI...
Don't know if that is right...
Our 3CX Client starts of course in our terminal server session (we have published apps with Citrix), and the user sees only the client (be that 3CX currently, or other in the future).

 

[edossantos]

Well, it doesn't work. Windows client IS installed on the terminal server. We can dial from DATEV, but we do not get a caller-identification.

Maybe it's not clear what the integration with DATEV does. The contact name will not be shown in the desk phone. You will only see the number. The integration will just notify DATEV about the incoming call from a contact, so DATEV shows the contact record. For outbound calls, the integration will notify DATEV when the call ends, but no information is sent to the phone.

3CX doesn't support CSTA to receive call commands from a third party app, if that's what you need. It only supports it to control a desk phone, when you make a call using the 3CXPhone for Windows or the 3CX Web Client. In this case the 3CX client controls the desk phone using CSTA (only for supported phones). But you can't control 3CX using CSTA....

 

[Srdan]

Thank you, that clarifies the situation. It is now clear that we were consulted badly, and that 3CX definitely cannot do what our previous system could. 3CX can though more other things, but I find that caller ID from metadata directory is way more important than some other stuff. In any case, thank you.