Why do you have two “trunks” between the same two points? This causes problems with the peer being unable to distinguish between the two halves of the artificial split.
You haven’t but should have provided, protocol logs, but I suspect that the ITSP simply isn’t able to cope with two user accounts with the same IP address, given that it seems that it is outbound calls that are failing. I’m guessing it is determining the account and therefore the authentication data required, from the IP address, and challenging for trunk01’s account data, even for calls from trunk2.
I’ve not used chan_pjsip in anger, but I’m pretty sure that this is the first time I’ve seen the wizard configuration mode, which I assume generates multiple sections automatically. Although I suspect that there isn’t going to be a solution, if there is a solution, my feeling is that those who can give it to you will know it in terms of full format configuration, not the wizard configuration.
My best guess, based on my best guess of the failure mode, is that the only solution may be to bind the two endpoints to transports bound to different local port numbers. I think PJSIP allows that, but SIP didn’t.
Whilst setting the authentication data the same for both, I think the result will be that the ITSP treats all outbound calls as being on trunk01, and presumably the reason you want two trunks means that is not desirable.
I suggest temporarily removing trunk01 and trying with just trunk02. If that works, then consider the separate port/transport idea offered by @david551, along with the “line” option.
Also you might try to streamline your config by abstracting/inheriting some things between sections (and thus reduce possibility of typos, maintain better readability, etc.):