By "ports being dropped" I can imagine two things. Either that nothing comes to these ports at their side, which may have other reasons than ports being "blocked", or that they send RTP to the phones from these ports and get back some "icmp destination unreachable" messages.
I suppose the phones are on private IPs so there is a NAT on the Mikrotik and the pinholes for the RTP traffic are created dynamically, and unless you've created some super tight firewall rules on the Mikrotik, it does not restrict access of LAN hosts to particular remote UDP ports in any way.
If the WAN address of the Mikrotik is assigned dynamically, or if the WAN interface goes briefly down and up again from time to time, and you use an action=masquerade for NAT, it can be that whenever the WAN port gets a new address or goes down briefly, all connections src-nated using that rule get dropped (which is a normal behavior). But since the phone keeps sending RTP, they should be re-created again, so only the change of WAN address sounds to be a likely reason to me.
Another possibility is that in the affected calls, the media path is indeed rebuilt due to call transfer or something similar and for some reason the RTP doesn't get through following that rebuild.
A sniff from the Mikrotik side, ideally matching on the IP address of the cloud system, is necessary to say more.
Don't write novels, post /export hide-sensitive file=x. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.