ICE candidate pairs not including my local srflx candidate

[Axel Delmas]

Hello,

I'd like to understand better how candidate pairs are formed by the user agent.

We use datachannels to do P2P video streaming, and we don't use TURN (the fallback when we can't connect to other peers is to get the content from the media server instead of peers). We're observing an abnormally high number of ice connection failures using only STUN. Most clients are perfectly capable of opening connections using only STUN with some other peers, so we almost always succeed to match most peers with other peers, but still the amount of connection failure is unexpectedly high.

From what I observed using chrome's about:webrtc-internals and Firefox's about:webrtc, it appears that in almost all of the observed failure scenarios the UA is only forming and checking candidate pairs with local host candidates. This happens although it also has local srflx candidates, which rules out an connection issue with the STUN server.

Here's a screenshot of one such connection that timed out from Firefox's about:webrtc:

From my understanding of this tool, it looks that Firefox did not include my local serverreflexive ICE candidate in any candidate pair it tried. The remote peer being on a different network, it failed to make establish a connection using my local host candidate.

On connections that succeed, I can see a line in this table pairing my local srflx candidate with a remote srflx candidate.

Similarly, from chrome's about:webrtc-internals:

For connections that fail, I can only see my host candidate in the list of localCandidates on the right column. The googCandidatePair entries only show my local host candidate as well.

However, one of the "onIceCandidate" event on the left column shows my srflx candidate when expanded. When logging my local SDP upon ICE failure, I can see my local srflx candidate in it as well.

For connections that succeed, I can see my local srflx candidate both in a "localCandidate" and in one (or more) "googCandidatePair" entry in the right cloumn.

From what I understand of these stats, it looks like both Firefox and Chrome sometimes ignore local srflx candidates when forming candidate pairs. 

I'd like to make sure that I understand these stats right (are they actually ignored, or just not somehow not showed in the stats?).

If they are actually ignored, what could possibly be the reason?

Thanks,

Axel

[Taylor Brandstetter]

I believe what you're seeing is expected. When ICE forms candidate pairs, it replaces "srflx" local candidates with "host" ones.

Section 5.7.3:

"For each pair where the local candidate is server reflexive, the server reflexive candidate MUST be replaced by its base."

However, once a STUN binding response is received, if it includes the srflx address, then the new candidate pair will have a "srflx" local candidate.

Section 7.1.3.2.2:

"It will be very common that the pair will not be on any check list. Recall that the check list has pairs whose local candidates are never server reflexive; those pairs had their local candidates converted to the base of the server reflexive candidates, and then pruned if they were redundant.  When the response to the STUN check arrives, the mapped address will be reflexive if there is a NAT between the two. In that case, the valid pair will have a local candidate that doesn't match any of the pairs in the check list."

Basically: one a check succeeds, if it turned out there was a NAT between the peers, the local candidate will be "srflx". Otherwise it will be "host". But until that check succeeds, all local candidates in candidate pairs will be "host" (or "relay").

So, what you're probably seeing is just that you need a TURN server.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/821c4bc3-638a-4ce3-ace1-7f9d844b29a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.