How can ICE Connectivity Check tell if a network route between a candidate pair exists or not?

Question

How can ICE verify that the STUN Request packet of the Connectivity Check went through R-SR (Server Reflexive Transport Address of NAT R) when checking the ICE Candidate Pair (local candidate, remote candidate)=(L-SR, R-SR)?

My understanding upon reading RFC 8445 is, the Connectivity Check on the pair (L-SR, R-SR) is to verify that there is a route between L-SR and R-SR through which a STUN Request packet can hop through.

RFC 8445 - 2.2. Connectivity Checks

   Once L has gathered all of its candidates, it orders them by highest-
   to-lowest priority and sends them to R over the signaling channel.
   When R receives the candidates from L, it performs the same gathering
   process and responds with its own list of candidates.  At the end of
   this process, each ICE agent has a complete list of both its
   candidates and its peer's candidates.  It pairs them up, resulting in
   candidate pairs.  To see which pairs work, each agent schedules a
   series of connectivity checks.  Each check is a STUN request/response
   transaction that the client will perform on a particular candidate
   pair by sending a STUN request from the local candidate to the remote
   candidate.
The basic principle of the connectivity checks is simple:

Sort the candidate pairs in priority order.
Send checks on each candidate pair in priority order.
Acknowledge checks received from the other agent.

With both agents performing a check on a candidate pair, the result
   is a 4-way handshake:
              L                        R
              -                        -
              STUN request ->             \  L's
                        <- STUN response  /  check

                         <- STUN request  \  R's
              STUN response ->            /  check

                Figure 3: Basic Connectivity Check

Problem

When Peer L executes the Connectivity Check on (L-SR, R-SR) with Peer R, L sends a STUN request. When it arrives at peer R, the source IP address of the request is T-R and there will be no information what hops the request went through.

Then, the STUN response from Peer R can only tell that T-R was on the route. Hence, Peer L cannot confirm that there is a network route including L-SR and R-SR as their hops.

Question

What mechanism or tool is actually used to see if the STUN request did go through (L-SR, R-SR) or not? Is it using ICMP as a supplemental mechanism?