Due to the out of order message delivery nature and specially under trickle ICE scenario, it is possible that the Android SDK receives ICE Candidates before receiving an offer (when android is master) or answer (when android is viewer). Host candidates are usually the first ones to be received/sent and if SDP exchange is not completed, the addIceCandidate call fails and host candidates are not added for gathering. This leads to a case where the probability of non-host candidates getting selected increases even when a connection with host candidates is possible, increasing TURN candidates selection ratio. This PR addresses the issue by queuing up the ICE candidates received before peer connection is established, that leads to using host candidates as well in connectivity checks.
Testing:
A manual testing was done using android as viewer and C SDK as master. The selection of host candidate was verified through RTCStats by first checking for the nominated: true flag in RTCIceCandidatePair stats and then referencing the selected remote ice candidate.
For the case of android as master, a dry test was done to ensure the flags and queues are appropriately updated. This scenario would still require more targeted testing.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Issue #, if available:
47
Description of changes:
Due to the out of order message delivery nature and specially under trickle ICE scenario, it is possible that the Android SDK receives ICE Candidates before receiving an offer (when android is master) or answer (when android is viewer). Host candidates are usually the first ones to be received/sent and if SDP exchange is not completed, the
addIceCandidatecall fails and host candidates are not added for gathering. This leads to a case where the probability of non-host candidates getting selected increases even when a connection with host candidates is possible, increasing TURN candidates selection ratio. This PR addresses the issue by queuing up the ICE candidates received before peer connection is established, that leads to using host candidates as well in connectivity checks.Testing:
A manual testing was done using android as viewer and C SDK as master. The selection of host candidate was verified through RTCStats by first checking for the
nominated: trueflag inRTCIceCandidatePairstats and then referencing the selectedremote ice candidate.For the case of android as master, a dry test was done to ensure the flags and queues are appropriately updated. This scenario would still require more targeted testing.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.