You should use chan_pjsip, not chan_sip, as the latter is deprecated and will not even be in the source code for Asterisk 21.
Also, the suggested chan_sip configuration contains several common errors, and poor choices that are typically the result of copy and pasting, rather than designing from first principles and the documentation. In particular, the following settings should be reviewed: type, canreinvite, call_limit, and username (can cause misoperation, obsolete name, deprecated mechanism and value may not be appropriate or necessary, and doesn’t do what people seem to think it does and not useful without host=dynamic and a default host, as well as being an obsolete name).
The term “trunk” is not used by any SIP RFC that I know of. The term “extension” is similarly not a SIP term and is used differently in Asterisk.
Basically you configure the Asterisk daemon on 233 to act as a client on the endpoint for 235, passing some or all of the digits in the dial string, as you would if 235 was a provider. On 235, acting as a server, you treat 233 as though it were a provider with true direct in dialling, and have it act as client to the provider (which was missed from the diagram) providing PSTN access, in the same way as it would if the call came in from a phone type device.
Generally you would apply IP based authentication, with static addresses, between 233 and 235. In all cases, at least one of them must have a static address. One would expect either no password authentication, or both way authentication, not the one way authentication typically used with providers. With both way, you can either use the same secret in both directions (just secret in chan_sip, and both auth and outgoing_auth pointing to the same type=auth entry, or you can use different ones (secret and remote secret, or different type=auth sections).