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 ?

[michielpeeters]

Hello @jp-fournier-dev,

Did you find more information about this matter? I think I'm running into this as well.

Hope to hear from you!

[jp-fournier-dev]

Hello @michielpeeters ! We did end up modifying on our side the nomination logic to be less averse to TURN candidates, but that was in an older version. It seems that the logic has been modified in the more recent versions 6.0.0+ but haven't had time to revisit and test it again.

[michielpeeters]

Ah ok! Thank you for your answer. Well I guess it still doesn't work though. Then I need to grind into the sourcecode to see what is actually happening. Did you had opened an PR with your changes in it? Could you show me what you guys have actually changed? Maybe we can re-use that information as well. Thanks!

[jp-fournier-dev]

We did not have time to propagate to the original repository yet. The work that was done was a quick workaround that isn't perfect in any sense.

In ProcessNominateLogicAsController, right before the check would be done for if (findBetterOptionOrWait), we would add an extra logic that would look a the possibleMatchingCheckEntry and see if timewise we had passed a certain amount of time since the relay candidate in question had been seen valid.

Past a certain amount of time, if we still hadn't found a better candidate, we would nominate the TURN candidate that worked.

In our logs we would clearly see TURN candidates succeed but never be nominated by SipSorcery. I wish I still had the test bed to confirm if the newer version fixes this. I will eventually get there and I'll update whenever I can.