Save this as a last resort solution. We need to make sure that PJ-SIP is working, and if you’ve found an edge case where it’s having a problem, the troubleshooting you do can fix a problem.
Having said that, however, the assumption with one-way audio is that 90%+ of the time, it’s a NAT setting. With PJ-SIP, some of this goes away, but still the assumption should be that a “local” address is leaking out into a “non-local” space and screwing you up. It might be time for a PJ-SIP Debug session. Turn on PJ-SIP debug stuff and see where the disconnect is. There are supposed to be automatic NAT settings throughout PJ-SIP, but make sure that all of the networks (local, external, and VPN) are all routed correctly and set up to work accurately. Don’t forget that the remote end could be interacting in an “unexpected” way, so you’ll need to pay attention to the other end of the VPN to make sure that the routing at both ends is working.
Now, once you’re convinced it isn’t NAT, check your CODEC details. This is usually easier (but far more rare) in that Codec mismatches show up in the /var/log/asterisk/full log as a notice from the server about not being able to transcode from something to something else.
When responding back, you need to tell us what is and isn’t working, what you tried, and what the result was. Answer that sound like “Nope, guess again” are the fastest way to get people to stop helping you entirely. Yes, it means you type a lot. Sucks to be you, but we can’t really help you unless we know what you know.