Status fails to update and gets stuck

[adam-law]

Using ice4j has been mostly hit than miss, for our purposes. On some occasions of connectivity establishment, when only one side succeeds reaches IceProcessingState.COMPLETED status, the other side is stuck at this:

INFO: timeout for pair: 192.168.0.5:44356/udp/host -> 192.168.0.20:45338/udp/host (mote.RTP), failing.

Without the status properly updating to IceProcessingState.FAILED, an application cannot properly react, and, in the case of our app, remains stuck, waiting for a status that never comes. I see that this happens in the part of the code:

    public void processTimeout(StunTimeoutEvent ev)
    {
        CandidatePair pair
            = (CandidatePair) ev.getTransactionID() .getApplicationData();

        logger.info("timeout for pair: " + pair.toShortString() + ", failing.");
        pair.setStateFailed();
        updateCheckListAndTimerStates(pair);
    }

where it gets stuck when there is only one stream when Agent.checkListStatesUpdated() runs, because the stream is already failing, but is still considered running. This then enters the check

        if (!allListsEnded)
        {
            return;
        }

where it never gets to the part:

        if (!atLeastOneListSucceeded)
        {
            //all lists ended but none succeeded. No love today ;(
            if (logger.isLoggable(Level.INFO))
            {
                if (connCheckClient.isAlive()
                    || connCheckServer.isAlive())
                {
                    logger.info("Suspicious ICE connectivity failure. Checks" +
                        " failed but the remote end was able to reach us.");
                }

                logger.info("ICE state is FAILED");
            }

            terminate(IceProcessingState.FAILED);
            return;
        }

When we amended the faulty check to:

        if (!allListsEnded && streams.size() > 1)
        {
            return;
        }

it fixes the issue. I'm not sure if the amendment goes against intended design. Please advise.

Thanks.

P.S. On previous experiences there were more than one logged lines of

INFO: timeout for pair: 192.168.0.5:44356/udp/host -> 192.168.0.20:45338/udp/host (mote.RTP), failing.

for different pairs. I'm not sure if these pairs also had just one stream associated.

Edit:
I found that fix was naive, since processResponse also leads to the end method. I placed in another check for when it comes from processTimeout and it seems to work fine.