In basic SIP, endpoint carrier traffic is typically connected in P2P mode, as you said. They do this by indicating each other the address / port in the SIP SDP negotiations.
In an “ideal” networked world, this works great because all endpoints can talk directly to each other.
As we know, this is not so.
In most cases, NAT is the main barrier in the IPv4 world.
The first solution that people came up with is STUN . STUN will give you your “public” IP address, which you use because of NAT, and the SIP stack will use this IP address in SIP / SDP packets. This works as long as the perforation hole works.
The next solution people have come up with is TURN . TURN is a UDP proxy and allows a client (for example, a SIP client) to allocate and use an IP address / port on a private network from a public network (i.e. the Internet). It should work in all cases, but can incur a lot of network overhead on the TURN server. It will not be as effective as P2P connections. The potential use of TURN is that both parties do not have to support it in order for it to work. So good when you are talking between a softphone on the Internet on a hardware SIP device on the internal network.
The next solution people come up with is ICE . ICE must be supported at both SIP endpoints. It works by expanding the SDP protocol to allow it to add all possible connections to the SDP negotiation (all local network adapters, public addresses provided by STUN and TURN, assigned addresses in priority order). Then one side scans the listed connections and tries to establish a connection. This allows both connections to "try" to connect P2P and fall back to the TURN connection if nothing works. It should also work in any network environment in any network environment and find the most efficient network path between SIP endpoints. The disadvantage of ICE is that both SIP endpoints must support ICE for it to work. (Aside, ICE / TURN / STUN is now a requirement for the WEBRTC protocol for web browsers to talk to each other for the same reason)
Other possible solutions for you may be some kind of “smart” proxies in the middle, which can fake ICE on the one hand, if the other side does not support it. The other is to have some kind of media gateway or B2BUA, if transcoding is required, this would have the same problems as TURN tho.
I would suggest that you configure your SIP client with STUN, TURN, and ICE, if possible, and this will increase the likelihood that the SIP call really works.
As to why your case is not working now, accessing the network protocol and / or SIP logs will require understanding what the exact obstacle is.