we have very severe problems with Teams communications during working hours.There is extremely high jitter and often it is not possible to establish a video communication.We set up a sensor in PRTG which is based on the SFB Network Assesment tool.Links (only German)https://www.msxfaq.de/tools/end2end/end2end_sfb_network_assessment.htmhttps://www.msxfaq.de/skype_for_business/tools/microsoft/skype_for_business_online_network_assessment_tool.htm
As we see no issues from the outside (e.g. homeoffice) this is very unlikely a Microsoft problem.
We strongly suspect that the Sophos XG is causing the issue however we also investigating in other directions. We have an XG550 cluster and are running on XG550 (SFOS 17.5.12 MR-12.HF062020.1) .This is not an issue with bandwith or a special provider as we see it occuring on both of our internet lines.Firewall rule is straightforward.Wireshark shoes that most times UDP is chosen as communication protocol. The jitte seems to be more a problem for incoming packets than for outgoing ones.Anybody else noticed this? Are there any tweeks that could resolve the problem?Best regards,BF
There is a section in the XG online help about VOIP and how to troubleshoot certain issues.
Maybe this help? docs.sophos.com/.../FirewallVoIP.html
Thank you for contacting the Sophos Community!
Have you run the following commands:
console > set advanced-firewall udp-timeout-stream 150
You might need to add some exceptions in the IPS for Teams using UDP.
This link and this link will tell you which ports to exclude from IPS and which IPS.
Good Morning. Thanks. does this require a reboot?
This won't help you, but it may help others that come across the post. We had issues with Teams but once adding a rule for the below, skipping the web filters etc. everything worked fine:
Microsoft Teams / (Skype For Business)Destination: 22.214.171.124 - 126.96.36.199Dst Ports: UDP-50000:50059, UDP-3478:3481 / HTTPS
old school planetarion: http://ricarion.com/
No it does not need a reboot.
Thanks. This seemed to help in the first glance but on the second day we still saw the issues - maybe somwhat less intensive.
Thanks. We have not limited communication from LAN -> Internet. The problems seem to arise when data flows from the internet to the clients in the LAN.
Thanks. I wil look at this after my holiday (or my colleagues will when I am out - of -office).