/ip firewall service-port set sip sip-direct-media=no

• if the PBX puts itself into the RTP path, the fact that the helper changes the connection address in the SDP is correct because it must put there the outer address (of the Mikrotik) instead of the actual address of the PBX (which is most likely private so unreachable to the phones),
• if the PBX tells the phones to send RTP to each other directly, changing the connection address in the SDP is a wrong action to take

But unfortunately I can't change the PBX. My PBX is Huawei u1911 and it isn't so flexible as opensource PBX. What's more it doesn't have any options to solve NAT problem.

But unfortunately I can't change the PBX. My PBX is Huawei u1911 and it isn't so flexible as opensource PBX. What's more it doesn't have any options to solve NAT problem.

Then do not use NAT, as I already mentioned. Put it on a public IP address.

But there are only two interfaces on the PBX: mgmt and phones. And I think it isn't a good idea to public any of them. That's why I use NAT

If you can put the "phones" interface of the PBX to a public IP address and use a firewall to permit access to that interface of the PBX from the internet side only to the IP address of your VoIP provider, that approach is ways better than putting a NAT with an ALG between the PBX and the internet. I was expecting that you use that "emergency means" because do not have an available public IP you could use for the PBX.

But, also I thought about the phones (clients of PBX I mean) . Of course, I can't put them in public net with public addresses.

But I'm not sure if the PBX will send correct SDP in case it isn't NATed. I mean if Mikrotik doesn't have to NAT the PBX, will it change connection address field in the SDP from my the PBX?

• two of your own phones call each other
• your own phone talks to someone in the public voice network via your VoIP provider's exchange
• your PBX forwards a call coming from outside to a number of your phone back to a number in public network while it remains in the signalling path (so some kind of RTP loopback to the VoIP provider's exchange is necessary)

• if both the VoIP provider's exchange and your PBX are at public addresses, and your IP phones stay at private addresses and there is a NAT with SIP ALG activated between the phones and the "rest of the world" (which means both your PBX and the VoIP provider's exchange), the SIP ALG is doing what it has been created for. The only thing I'm not sure about is how the SIP ALG behaves if the PBX asks the phones to send RTP directly to each other, so you may end up having silent calls between your own phones. Here you may need to test both settings of "ip firewall service-port set sip-direct-media", i.e. "yes" and "no". If you try this way, I'd be really interested in the result, especially in the SDPs before and after transit through the Mikrotik
• if you permit transparent routing (i.e. without NAT) between the PBX and the phones and the SIP ALG will not interfere, the SDPs will be OK between the PBX and the phones in any case (no NAT = no problems), but the question is what happens when the phones call outside.
  • If you can configure your PBX to force itself into the RTP path between the phones and the uplink trunk (or also the RTP path between your phones as you say it is anything but flexible), you're good and this would be my preferred solution
  • if you cannot and thus the PBX will forward SDPs provided by the phones to the VoIP provider, you would have to configure NAT between the phones and the VoIP provider's IP address. It would be actually used only for the RTP as the signalling doesn't flow directly between the phones and the VoIP provider. Now,
    • either the VoIP provider is able to ignore the connection address in the SDPs coming from a client and instead send RTP to the remote socket from which it actually receives it, and make an exception if the connection address in the SDP is one of its own ones (for the forwarded calls). If this is the case, the ALG must be off.
    • or, if the above does not work, you would need the SIP ALG to manipulate SDPs in SIP packets between your PBX and the VoIP provider's one to make ordinary calls between your phones and the world work, but this is the scenario we've started from and needed to avoid because it breaks the forwarded calls, so game over at this point.

I definitely don't have enough public addresses to assign them to all my phones.