Issues with TURN candidates when RTCPeerConnection is the controlling agent

[jp-fournier-dev]

Short description : when SIPSorcery's RTCPeerConnection is the controlling agent in the ICE session, the relay candidates never get chosen before a timeout occurs in situations where the relay was the only available choice between all other host, srflx candidates.

This issue occurs with calls between a mobile app and a backend that uses SipSorcery as the WebRTC Peer Connection. These both have configurations that enable usage of STUN and TURN. In this case, the mobile application is using the mobile network and will necessitate the usage of the relay candidate.

When I'm looking at logs, I can see that we receive successful BindingResponses and send BindingRequests through the relay candidate pairs (either (host) -> (relay), (relay) -> (host) or (relay) -> (relay)). Adding a bit more logs shows me that we actually hit the ProcessNominateLogicAsController section.

With a given response, we'll go through this and check if other candidates of higher priority are still ongoing checks and we'll choose to wait if that is the case. The issue is that nothing seems to be making us go back in there and decide to nominate the candidate in question. The following if branch is never entered

  //Nominate Candidate if we pass in all heuristic checks from previous algorithm
  if (possibleMatchingCheckEntry != null && possibleMatchingCheckEntry.State == ChecklistEntryState.Succeeded)
  {
      possibleMatchingCheckEntry.Nominated = true;
      SendConnectivityCheck(possibleMatchingCheckEntry, true);
  }

I will continue investigating the issue on my side.

I'm wondering if there is a necessity to also nominate the checklist entry once we receive a request binding from the peer, if we are the controlling agent. This would match this section in RFC 8445, Figure 4 : Nomination. I have not seen anything that would generate such behaviour yet in SipSorcery

What do you think ?