STUN Binding (ICE connectivity check) Failing for Specific Peer - webrtc

Question

We have a TURN fleet that has presence with the AWS Regions US-EAST-1 and US-WEST-2.
A client in the Ukraine is trying to connect to a peer in the United Kingdom. Both the client and the peer are behind a symmetric NAT.
The client does not have access to TURN credentials.
The peer does have access to TURN credentials.
The result is:
client:
host
server reflexive
peer:
host
server reflexive
relay
Our TURN fleet creates permissions in IP addresses ONLY, and ignores the port variations.
Success case: Client initiates a call through US-EAST-1.
Client gathers its host, and server reflexive candidate. Sends them to peer.
Peer receives the clients candidates, and gathers its own host, server reflexive and relay candidate. Sends them to the client.
The client sends a STUN binding to the relay transport address.
The TURN relay sees the request, attaches an XOR-PEER-ADDRESS to it and forwards it to the client via a DATA indication.
The client sees the request, generates a response, and sends it to the relay via a SEND indication.
The relay accepts and forwards the message to the peer.
The peer unwraps the XOR-PEER-ADDRESS, determining it to be a peer reflexive candidate and sets the active pair as local: prflx | remote: relay.
Media flows, everyone is happy.
Failure case: Client initiates a call through US-WEST-2.
Steps 1 to 6 occur as they did above.
The peer never receives the response from the TURN server containing the peer reflexive candidate in the XOR-PEER-ADDRESS.
Since it is a symmetric NAT, the call fails.
This only happens to a particular peer, as we see thousands of prflx / relay calls happening in US-WEST-2 even at this very moment. I don't have any reason to believe that the TURN server failed to send the response.
Security groups for outgoing are fully permissive (for IPv4/6) and are identical.
0.0.0.0/0
::/0
The config files in both regions are identical. As far as my exhaustive search has taken me, the only difference between the two calls is the AWS Region that the calls are made through. I could be mistaken, but I've combed through every little detail I could think of.
I've even tested US-EAST-1 and US-WEST-2 myself through a symmetric NAT and was able to establish a prflx-relay call.
Has anyone encountered this before?
Binding Request (peer -> TURN)
1094 5.262769 192.168.1.202 TURN_IP_ADDRESS STUN
170 Binding Request user: 0kZJvRw4xieMyZWtgrfSvGh6EzfhRzxP:5Vi8
TURN to Client DATA indication:
3942 8.729590 TURN_IP_ADDRESS 192.168.1.202 STUN
150 Binding Success Response XOR-MAPPED-ADDRESS: 1.2.3.4:9976 user: ttsEVBZnkpBftWENErHh+3HkiEj3xoU2:8/DZ
Client Receives message:
3272 7.757723 TURN_IP_ADDRESS 192.168.88.108 STUN
250 Data Indication XOR-PEER-ADDRESS: 1.2.3.4:9976
Client Creates a permission:
CreatePermission Request XOR-PEER-ADDRESS: 1.2.3.4:9976 with nonce realm: amazonaws.com user: { USERNAME }
Client responds:
3358 7.930904 192.168.88.108 TURN_IP_ADDRESS STUN
186 Send Indication XOR-PEER-ADDRESS: 1.2.3.4:9976
TURN to Peer response:
nothing received by the peer
Client continues to receive DATA indications of:
3272 7.757723 TURN_IP_ADDRESS 192.168.88.108 STUN
250 Data Indication XOR-PEER-ADDRESS: 1.2.3.4:9976
and continues to respond with:
3358 7.930904 192.168.88.108 TURN_IP_ADDRESS STUN
186 Send Indication XOR-PEER-ADDRESS: 1.2.3.4: 9976
Eventually the call times out.