ICE Negotiation (Part 2) – Candidate Process


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/

Advertisements

About Paul B

My name is Paul Bloem and I am employed at Lexel Systems in New Zealand as a Principal Consultant for Unified Communications. I have been working on enterprise voice solutions for over 20 years. My first 10 years were spent working for a Telco in South Africa (Telcom SA). This is where all the groundwork happened as I was exposed to just about every aspect of telecommunication you could imagine. I develop an interest in PBX technologies and eventually became the go-to guy. Next, I had a 10 year run at Siemens South Africa, most of my time there was as a Technical Trainer. During this time VoIP hit the world stage, I had the privilege of introducing VoIP both as H.323 and later SIP across the Siemens HiPath 4000 solution stack. In 2008 I immigrated to New Zealand with my newly attained MCSE, I was ready to go where no PBX Techie had gone before. I was employed to explore OCS 2007 and that was pretty much the beginning of the end for me. I have been working on OCS and Lync ever since. My current role focuses exclusively on Lync and associated technologies.. That includes pre-sales, consulting, architecture and design, training and support. I even get to play in the development space from time to time - focus on play ;-) I was nominated as a Microsoft VTSP for Lync early in 2013 and also awarded Microsoft's MVP award for Lync in 2014.
This entry was posted in Candidate, Invite, SDP. Bookmark the permalink.

One Response to ICE Negotiation (Part 2) – Candidate Process

  1. Pingback: ICE Negotiation (Part 1) – MRAS Process | UC Sorted

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s