RE: SM17 build 7242, video chat in team workspaces
Problem reported by Christopher Hiatt - 1/24/2020 at 3:32 PM
Has anyone tried to use video chat in team workspaces across different networks? I setup a new install of SM17 to test everything out and am having an issue with this feature. If users are on the same network everything works fine. But users on separate networks will not connect the video. All other features still work fine.

I looked at the firewall logs on one location and when video starts there are connections created in a reserved IP range between the clients that the firewalls are correctly blocking. Something like 100.115.92.x. 

I can see no special setup instructions for the video chat other than having the site SSL secured which it is so I'm a bit stumped here.

12 Replies

Reply to Thread
Christopher Hiatt Replied
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 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 is also trying to send/receive to 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 network.

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


Christopher Hiatt Replied
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.
Dave Feuer Replied
Yeah, it's not working for me either with a client behind a SonicWall.
Opened a ticket. Lets see what they come up with.
Christopher Hiatt Replied
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.
Christopher Hiatt Replied
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?
Christopher Hiatt Replied
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  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.
Kyle Kerst Replied
Employee Post
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!
Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com
David Sovereen Replied 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 (,, and  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.
Kyle Kerst Replied
Employee Post Marked As Resolution
Quick update for you all on this one! I just finished a retest under our latest MAPI codebase and was able to successfully get multiple users on multiple device types and different networks connected to video chat successfully, and believe you too should be able to make this work once the new release is out. 

With that being said, there are some caveats. Once the new version is installed, you'll need to do/note the following: 

- STUN/TURN server will need to be implemented in server configuration. Google operates a few public STUN/TURN servers that I was able to use for these purposes and I recommend starting there. 

- Users will need to ensure they are not using the camera or microphone on any other applications/meetings, otherwise access to those devices will be blocked. 

- STUN/TURN server coordination will require specific ports be opened as outlined in this post here: https://docs.pexip.com/rp_turn/rpturn_ports.htm and these will need to be opened on the server firewall.
Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com
Urs Replied
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)
Christopher Hiatt Replied
Any updates to this? The issue is not really resolved.
Chris Replied
We deployed Prexip TURN Server (vmware based) and everything works now. So you guys need a TURN server. 

Reply to Thread