Krisz's Microsoft Teams adventure

  Introduction:  Discover how the Interactive Connectivity Establishment (ICE) protocol, defined in RFC 5245, enhances the security of peer-to-peer communication in applications like VoIP and WebRTC. We'll delve into the safety measures implemented within ICE and explore how it helps protect systems from potential threats.   1.      Demystifying RFC 5245 and ICE for Secure Connections The ICE protocol, established in RFC 5245, efficiently finds the best network path between peers, even when hindered by Network Address Translation (NAT) devices or firewalls. ICE gathers candidate IP addresses and ports, then tests connectivity with the help of STUN and TURN protocols, ensuring secure communication. 2.      Security Mechanisms Within ICE ICE incorporates a range of security features to safeguard signaling and media traffic. Here's a closer look at how it achieves this:   a. Securing Signaling: Signaling security is a crucial aspect of the Interactive Connectivity Establishment (I

 Overview Last week, I started a series of article about ICE protocol and its implementation for Microsoft Teams. Today, I'm going to write a bit more about ICE builds up the candidate pairs and how ICE test those connectivities.  Here you can find part 1. ICE article Part 1 Build candidate pairs Before we can build a candidate pairs we also have to run a process called Determining Role. For each session, each agent takes on a role. There are two roles; controlling and controlled. The controlling agent is responsible for the choice of the final candidate pairs used for the communications. This means nominating the candidate pairs that can be used by ICE for each media stream, and for generating the updated offer based on ICE's selection, when needed. The agent that generated the offer which started the ICE processing MUST take the controlling role, and the other MUST take the controlled role. Both agents will form check lists, run the ICE state machines, and generate connectivi