As discussed in the first answer, the UE then monitors the downlink for the Random Access (RA) - RNTI which can be calculated from the subframe and frequency resources (TDD Only) used to transmit the RACH preamble. The message returned from the eNB is called the Random Access Response (RAR). It must appear within a certain window that starts 3 subframes after the RACH transmissions and lasts for a number of subframes given by the ra-ResponseWindowSize. If this message is not seen at all by the UE it's indicative of insufficient transmit power and the diagram redirects us back to the Transmit Preamble box. Note the incrementing and checking of the preamble counter.
Probably not the best name for this box but ... Assuming the UE finds the RAR a couple of things could happen. One is that Random Access Preamble ID (RAPID) transmitted by the UE may not be identified by eNB in the RAR message. In this case, the eNB is responding to other UE that transmitted in the same RACH opportunity. In this case, it is again an indication of insufficient transmit power, and the diagram returns us to the Transmit Preamble box via a counter increment and check.
Another possible condition is that the UE finds it's RAPID in the RAR but fails the contention resolution process described in the first answer. In this case, the problem could have been congestion, or it could have been insufficient transmit power.
Note that I have smashed a couple of messages into a single box. Contention resolution actually involves 3 messages, the RAR, the RRC_Connection_Request, and the RRC_Connection_Setup. The UE will not will not wait forever for the completion of the calling ladder, via reception of the "setup" message and as such 2 timers are started after transmission of the "request" message, the Contention Resolution Timer and Timer T300.. The max value for the contention resolution timer is 64 subframes. The UE will not RACH while this timer is active.
Timer T300, has a much longer time scale, the minimum value of T300, (100ms) is longer than the maximum value of the contention resolution timer. Upon expiry of the contention resolution timer, the UE is allowed to transmit RACH preambles again, incrementing the counter. Upon expiry of T300, the UE abandons this "fork" of the process. (This seems another answer to "How does the UE know to abort the ongoing RACH process ... Although it's never 'done" here).
So the RACH process can be terminated successfully by successful reception of the RRC_Connection_Setup message.
On the "Unsuccessful" side, when the Max Preamble counter is exceeded, the higher layers are notified. What they decide to do is also another story.
I hope this helps and was actually the question you were asking!!!