Multi-Site via VPN "Audio Call FAILED"

[coolie1101]

Hi,
I have 2 Connect 536's on v8.2.17.4 software in LAN Host Mode setup for multi-site (controller & branch), both are connected via an existing Ubiquiti UXG Site-to-Site VPN, all users and handsets show up on both systems, all test past except for "Audio Call" which fails on both sides with (Fail. Call denied by remote end), and I cannot call any extension in either direction form either site, any idea what the issue may be?

Both systems show Inbound and outbound Links as Active, and (SIP registration expires: June 15, 2022 23:9).
Event Log on both systems show:
tWebThread1-06: Multi-site test: ip_address [name]: HTTP PASSED
tBlf: Multi-site test: ip_address [name]: BLF PASSED
tSmtpC01: Multi-site test: ip_address [name]: Voice Mail PASSED
tSip: Multi-site test: ip_address [name]: SIP PASSED
tSip: Multi-site test: ip_address [name]: Audio Call FAILED

Hope I provided all necessary info.

[wshrader]

I think the denied message may be inaccurate. You should get a packet capture of the traffic to analyze the SIP signaling. If the far-end server is actually denying the test call that's a different problem. I suspect it says denied simply because the some NAT is not happening correctly through the VPN tunnel. In other words, I suspect the audio may have gone to an IP address that is not the intended recipient and it's being reported as denied though I would also expect the error to be "not answered". A packet capture to analyze the SIP traffic is definitely needed to get a better idea of what is actually happening (or not happening).

I recently had a customer with a complicated mish-mash of VPN tunnelling between about 7 sites and had similar symptoms. I don't know the technical details of how they fixed it but the cause was misconfigured routing (NAT).

[coolie1101]

misconfigured routing (NAT).

I had them configure port forwarding in an effort to try the connection over the WAN, but the result is exactly the same.

On another note, reach handsets work without issues to either location.

[wshrader]

misconfigured routing (NAT).

I had them configure port forwarding in an effort to try the connection over the WAN, but the result is exactly the same.

On another note, reach handsets work without issues to either location.

Were packet captures between both Allworx servers during the Multi-Site audio test analyzed? I think this will tell you what the failure is and that it will probably be that the RTP is being sent to the wrong IP address or the firewall(s) are blocking this traffic. Since it still fails from server-to-server then it still implicates the firewall(s). Do you have static routes configured on the Allworxen? This shouldn't be necessary but depending on the specific details of your network configuration might help. It would help if Allworx documented technical details on how these processes work. I know for a fact that Reach does not work exactly like an 92xx or 93xx deskphone. It is possible that one will work while the other fails in some manner. That's very frustrating. I had a customer who would lose audio with Reach even on the internal WiFi but generic SIP WiFi applicaitons worked perfectly. This was on a flat network too. BTW, this was on a network using all UniFi equipment.

In my opinion the most trouble-free configuration is to give the Allworx server it's own dedicated public IP address and use NAT/Firewall mode and bypassing any firewalls. If the edge device is the ISPs then any troubles can be blamed on that. I've seen very many old installations that also had an entirely dedicated Internet connection for the Allworx.

A silly question I should have asked at the beginning...did this EVER work?

[coolie1101]

Thanks for the info, as you stated, it had something to do with the firewall (didn't get specifics), but I reconfigured the multi site over the vpn again earlier after they mentioned making some changes and it worked even though the ui audio call test failed, and yes, if was working prior to them upgrading the network.

On another note, is it normal that reach clients cannot call extensions on the other side (reach client on site A cannot call any extensions on site B)?

[wshrader]

Thanks for the info, as you stated, it had something to do with the firewall (didn't get specifics), but I reconfigured the multi site over the vpn again earlier after they mentioned making some changes and it worked even though the ui audio call test failed, and yes, if was working prior to them upgrading the network.

On another note, is it normal that reach clients cannot call extensions on the other side (reach client on site A cannot call any extensions on site B)?

That is not normal. Any device registered to Allworx A should be able to dial an extension on Allworx B. If that Multi-Site audio test still fails that would explain why Reach audio between servers fails. First step, get that MS test to pass then everything else should just work. Since you know this all worked before changing the network that, though not consoling, proves the network changes are what broke it and that it's not an Allworx problem, it is a network problem. It seems from your comments that you are not in control of the networking equipment. This sort of problem is an excellent test of the expertise of those who are managing it. I am not a network engineer but I have worked with some good ones and this sort of problem shouldn't be that difficult to fix.
From a recent case I learned that if you make changes to network routing, try rebuilding the Multi-Site afterward. I guess the MS isn't self-correcting in this regard.

[coolie1101]

If that Multi-Site audio test still fails that would explain why Reach audio between servers fails.
>
It seems from your comments that you are not in control of the networking equipment.

The troubling part is that we can call extensions in either direction from desk phones.

[wshrader]

If that Multi-Site audio test still fails that would explain why Reach audio between servers fails.
>
It seems from your comments that you are not in control of the networking equipment.

The troubling part is that we can call extensions in either direction from desk phones.

This is why packet captures and analysis are critical to solving the network problem. As I mentioned, Reach does NOT work exactly like a 92xx or 93xx deskphone does. Analyze a packet capure of both a "good" call and a "bad" call to determine the difference. If the "good" call uses different ports than the "bad" call then try to configure, in this case Reach, to use that port range.

[coolie1101]

So, I did a packet capture, and downloaded the file as a ".pcap" file, how do I view it?

[wshrader]

So, I did a packet capture, and downloaded the file as a ".pcap" file, how do I view it?

The most popular and useful program for this is Wireshark.
https://www.wireshark.org