What is Candidate and how does it work?

In Microsoft Lync land a Candidate is a possible combination of IP Addresses and Ports for media connectivity.

This process (ICE negotiation) happens each time a call is made or received to determine how to connect the media.
ICE Process for basic peer-to-peer call

Why do you need to know this? It will save you heaps of time in pinning down AV connectivity issues!

The candidate process is as follows:-
 
1. Address Discovery (local endpoint send list of possible candidates)
2. Address Exchange (far end send list of possible candidates)
3. Connectivity Checks (check to see which candidates work)
4. Candidate Promotion (nomination of candidate to use)
 
You could say that the candidate process is part 2 of the ICE process (Part 1 is the MRAS process, read about that here)
 
Using Snooper to read the logs we will now dive a bit deeper into the ICS negotiation process.
 
In client side logs capture an Audio call and filter by candidate
 
The above example is of an outbound call to a Federated partner. Thus the INVITE show as outbound.

1.  Address Discovery

In reality the first message discovers and sends the candidate information in the call INVITE message.
Looking into the invite we see the SDP of the caller (Federated contact) telling the other end (my local client) the media type, codec capabilities and candidates.
 
You will see 2 sets of candidate data. The first set is for backward compatibility to OCS 2007 so can usually be ignored. Seen in image below:-
 
The second set of candidate data is what’s being used in my Lync environment. 
Also you will see the media type defined, main-audio as per below.
Breaking the candidate messages down so that it is understood.
I have taken the candidate data and formatted it so that its more easily readable in the table below:-
 
Column 1- Pair – the candidates always come in pairs.
Column 2 – Pair Number – either 1 (RTP) or 2 (RTCP)
Column 3 – Protocol – UDP takes preference over TCP – TCP, either Active [expecting traffic sent from this candidate]  or Passive [expect to send traffic to this candidate] TCP ports are the same for RTP and RTCP (using multiplexing) UDP ports are always different. Notice how pair 2 and 4 are identical with exception to Active vs Passive
Column 4 – Priority – Highest number defines most preferred candidate
Column 5 – Candidate Source IP (above we see 172.20.11.57 – local host and 203.171.4.18 -IP of Federated Partners AV Edge)
Column 6 – Candidate Source port
Column 7 – Type – Host (connect directly), relay (connect via), srflx (server reflexive address) Notice how there is never a TCP-PASS for srflex (for security reasons)
Column 8 – Relay IP – Connect via IP
Column 9 – Type – Destination
Column 10 – Relay Port – Connect via port
 
Looking at the IP Addresses we find the following:
192.168.10.206 – My local PC
60.234.48.202 – My Lync Edge Servers public IP
219.89.175.232 – My local PC’s Public IP
 

2. Address exchange

Message 2 – SIP 183 Session Progress

Message 2 is the candidate information from the called party (in this case my Federated contact)
 
 
Once again I have dropped the candidate information into a spreadsheet to make it readable.
In this instance you will notice the IP deatals as follows:
192.168.10.75 –  my Federated Partners local IP address
124.157.109.46 – Federated Partners Edge Server Public IP Address
219.89.175.232 – Federated Partners Public IP Address (same as mine as both were on my test network)
 

3. Connectivity Checks

These are not shown in the Snooper logs, STUN binding requests are made to determine the most direct media path possible between endpoints.
The ICS Protocol candidates are tested in the following sequence:

  1. UDP Direct 
  2. UDP NAT (Public IP of local\home router)
  3. UDP Relay (Through Public AV interface of Edge)
  4. TCP Relay (Last resort)

4. Candidate Promotion

Searching for “remote-candidate you will find the Candidate Promotion details
Selection order:
  • Highest Priority (Usually most direct)
  • UDP preferred over TCP
The Selected candidate is then presented in the SDP of a final INVITE followed by a 200 OK with just one candidate in SDP as seen below:-
 
The Final INVITE
 
 
The 200 OK
 

NOTE

If these messages are missing and instead you have a BYE then there were no successful candidates discovered

Again to make it more easily readable I have put the pertinent info in a table as below:
 
 
Thus the candidate will use the following path:
 
192.168.10.206 ↔ 219.89.175.232 ↔ 192.168.10.75
 
Local Lync Client ↔ My Public IP ↔ Federated Users Public IP ↔ Federated users 
 
NOTE
Both my client and my Federated Test user were on the same network 🙂
Basically the traffic was hairpinning across the ports on my Public IP, this would be the 2nd best choice (UDP NAT). UDP Direct was not possible in this case.
 
In Conclusion
This has been a fairly deep dive into candidate discovery and I hope that this is most useful in troubleshooting AV issues.
 

For Reference
https://ucsorted.com/2013/09/28/ice-protocol-warnings/

Advertisement