In the context of liubtorrent’s ut_holepunch lets assume that:

• initiating peer local endpoint is 1.2.3.4:6881 and the mapped address is 5.6.7.8:5881
  now when the peer announce to the tracker the tracker will save 5.6.7.8:6881 since 6881 is the port that the peer announced but it’s not the real world facing port.

• target peer local endpoint is 9.10.11.12:6882 and the mapped address is 13.14.15.16:5882
  now when the peer announce to the tracker the tracker will save 13.14.15.16:6882 since 6882 is the port that the peer announced but it’s not the real world facing port.

bep0055 states this:

The initiating peer sends a rendezvous message to the relaying peer,
containing the endpoint (IP address and port) of the target peer. If
the relaying peer is connected to the target peer, and the target peer
supports this extension, the relaying peer sends a connect message to
both the initiating peer and the target peer, each containing the
endpoint of the other. Upon receiving the connect message, each peer
initiates a uTP [2] connection to the other peer.

so when the initiating peer sends a rendezvous message to some relaying peer then the relaying peer has to be connected to the target peer for it to work, but if the tracker has the wrong target peer port, then no relaying peer will be connected at all to that peer