I tried this again this morning with mixed results. This seems dependent on the firewall appliance in play and how they treat certain protocol traffic. I'm by no means an expert on any of this so I tried several scenarios to see why it fails sometimes.

It generally works from cell to cell or if users are behind generic, home user type routers with no real filtering or firewall features.

-Cell to cell through TMO works fine.

-Cell to cell between TMO and Verizon works fine.

-Cell to wired internet with one user behind generic Linksys router works fine.

-Wired internet to wired internet with one user behind generic Linksys and the other on generic Netgear works fine.

Where it didn't work.

-Wired internet to wired internet with one user behind generic Linksys and the other behind Ubituiti with DPI and other app security features turned on. If both users are behind same Ubiguiti it works fine but any additional user on the other side of it does not share video.

-Wired internet to cell with one user behind Netgate firewall is no good. Same as above. If both users are behind the Netgate device it works fine. Add a third on the other side of the Netgate and they do not share video.

Doing packet captures during video connections it looks like the actual video protocol is attempting to create connections in a 100.115.92.0/29 space which is reserved under RFC 6890 and should not be found in the public address space. The Ubiquiti and Netgate are properly blocking this traffic as it should not be seen on the WAN. The generic routers from Linksys, Netgear and the others don't seem to care so this traffic passes without issue.

The 100.115.92.0/29 is also trying to send/receive to 192.0.0.4 which is a protocol address that encapsulates IPV4 traffic in IPV6 only networks. I had IPV6 disabled internally but did open it all up all the way through but the problem persists since it is still trying to send/receive from the 100.115.92.0/29 network.

If anyone else can't connect to video, see if you also have blocks on your firewalls from 100.115.92.0/29 or 192.0.0.4

Thanks!

Anyone had a chance to test video chat in team workspace? Trying to see if anyone else is having an issue with video getting blocked between users across a firewall.

Yeah, it's not working for me either with a client behind a SonicWall.

Opened a ticket. Lets see what they come up with.

-Dave

Any feedback on your end?

It's dead on SM16, half works on 17. Maybe this is just one of those features to disable so I stop getting support requests for it.

With the work from home conditions changing lately I'm getting a lot more complaints about users not being able to share video between their locations.

Are the transport issues on video chat in SM17 being looked at?

That doesn't fix anything.

It depends on the firewall the client is using. Their device is the one blocking the connection. Clients on application and protocol aware devices are the ones having trouble connecting.  In doing my own testing across a pfSense device I saw traffic from the video client trying to connect to a 100.115.92.0/29  address space which should not be seen going across a WAN connection. The firewall properly blocked this connection.

Clients using dumb firewalls, generic home type routers or cell to cell connections are working fine.

Hello everyone, sorry for the delay in getting back to you on this. I do know we're investigating further on a couple of open tickets but are also getting mixed results. I personally found in one instance that an Avast Business Antivirus solution was preventing users from seeing each other though they were all successfully connected via video. After temporarily disabling this functionality users were able to see each other again. In other instances these issues appear to relate to the firewall in use as users have pointed out on this thread. I believe Universal Plug N Play may have something to do with this as well as the video connections likely need to be able to open dynamic ports. We'll continue investigating and will update as we find out more. Thanks for your time and efforts on this so far everyone!

100.115.92.0/29 is CG-NAT space, which is to be used by ISPs to assign end-users as a WAN IP Address.  This space was set up specifically for ISPs to use so that they could assign a NATted IP to end-users that would not conflict end-users' own NAT space (192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8).  Smartermail should not be using this IP space for their video chat because an end-user whose ISP assigns them an IP in that range will presumably not be able to connect.  Note that I have not done a packet capture myself, but I do know that video chat is not working for us at all.

Thank you Kyle
First, I am wondering how you could find a google public turn server !?
Stun server yes, but not a turn server...

With newest SM build I can connect i.e. Smartphone with Webmail and Desktop PC with Webmail for video and voice conferencing, but only if they are within same network.
As soon Android phone is on 4G network, only chat, no voice and no video anymore.

So I set up a coturn service and configured in SM, but even I set logging to all details my xmpp log has only few lines saying nothing and my coturn dws not even get a request.

If I test with https://test.webrtc.org/  everything is fine except IPv6(not used) and reflexive connectivity(guess not used)

If anybody out there has video and voice running with clients in webmail and in different networks, I would be happy to read about your config - thank you

...SM7516 xmpp log

[2020.08.02] 19:06:56.740 ERROR: System.NullReferenceException: Object reference not set to an instance of an object. [2020.08.02]    at MailService.Protocols.XMPP.Core.XmppServer.OnRoutePresence(Presence presence) [2020.08.02] 19:33:29.952 ERROR: System.NullReferenceException: Object reference not set to an instance of an object. [2020.08.02]    at MailService.Protocols.XMPP.Extensions.mam.MamLogic.ProcessMamQuery(XmppServerConnectionBase connection, IQ iq) [2020.08.02]    at MailService.Protocols.XMPP.Core.XmppServerConnectionBase.streamParser_OnStreamElement(Object sender, Node e)

Any updates to this? The issue is not really resolved.

We deployed Prexip TURN Server (vmware based) and everything works now. So you guys need a TURN server.