One more piece of information to help you in this fight… Teams has a very specific behavior when setting up a call that you might be able to exploit… Lets say the user you are calling is on 192.168.1.25 on his local network, NATed somewhere on the internet to lets say 2.2.2.2, now remember there are 2 people involved in every call and 2 directions, so this happens in each direction…
Your PC Attempts a UDP connection to
- 192.168.1.25 Which fails… This connection works when 2 people are sitting in the office together.
- 2.2.2.2 Depending on the other users Firewalls and NAT type, has a decent chance of working.
- Microsoft TURN server
It does all these on UDP, and if they all fail it goes to TCP and SSL depending on configuration, but that’s not important for my thought here.
Now here’s the fun part… When it succeeds with one of the 3 above… it will have 2 active sessions in your session table… One of the 3 options above as primary… AND a connection to the MS TURN server for backup. If you end up using a TURN server as your primary connection for the call, the software opens a secondary connection to a different TURN server. There are always 2 UDP sessions established for the same call. So There may be something in outbound policy you can do by looking at the sessions established and try to get them to take different paths… Again not a fully baked thought, just some more info to help you in your quest for reliability.
Oh also, I noted that a user who left his wireless and wired NICs both connected had everything above done twice by the software… meaning 2 primary paths and 2 backup paths… the software on the laptop seems to think… hey if I have 2 NICs, I better use them both for reliability.