IceCandiates Anatomy

Its been a while since I had a post on the community. And, thought about writing a little-bit of my my known knowledge to share how to read the iceCandidates on a Call transaction. I hope this helps!

ICE stands for Interactive Connectivity Establishment , its a techniques used in NAT( network address translator ) for establishing communication. Typically ice candidate provides the information about the ip-address and port from where the data is going to be exchanged

ICE is the protocol chosen for NAT traversal in WebRTC. A snippet of the IceCandidate as below:

"iceCandidates": [

Host candidate for RTP on UDP - in this ICE line our browser is giving its host candidates- the IP 10.10.15.25 of the interface or interfaces the browser is listening on the computer. The browser can receive/send SRTP and SRTCP on that IP in case there is IP visibility with some candidate of the remote peer.

For example, if the other computer is on the same LAN, hosts candidates will be used. The number after the protocol (udp) – 2122260223 - is the priority of the candidate.

Host candidate for RTP over TCP - These lines are the same as the two ICE lines before but for TCP traffic. Please note that the priority is the lower – i.e 1518280447 is larger - as TCP is not optimal for real-time media transportation.

Relay candidate for RTP over UDP - next we have the relay candidates. Those candidates are obtained from a TURN server which must be provisioned when creating the peer connection. Thefirst IP/port couplecorresponds to the IP and port assigned by the TURN server (DirectMedia) for this media session. raddr and rport correspond to the public IPand the public port through which the WebRTC enpoint is reaching Internet. Note that the priorities are lower than the host and srflx type,