Why sometimes there is no outgoing sound on an outgoing call?

Question

Asterisk

Hello!
For a very long time I can not deal with one problem.

There are prehistoric versions of Asterisk + FreePBX, but most likely that's not the point.
There is a sip trunk with a provider (bee):

type=friend
nat=force_rport,comedia
qualify=yes
insecure=port,invite
host=beeline_ip
dtmfmode=inband
disallow=all
allow=alaw

There is a Mikrotik as a router in the office. Asterisk is located behind Nat from its own subnet. Let's say 10.1.130.9 is his address. Mikrotik is configured to forward ports 10004-61000 (ports are specified in the TOR) to the internal address of Asterisk.

Telephone sets are located in different places, and in different subnets (but not outside of NATA, internal routing is everywhere). All internal subnets are added to localnet in settings.

And now the case:
Subscriber A: internal telephone
Subscriber B: random mobile phone, landline number, etc...

Subscriber A calls subscriber B (ie this is an outgoing external call).
Approximately one time in 10-15 - subscriber B will not hearsubscriber A. The call is not dropped by timeout. In a call dump, RTP is set to both directions. The dump taken from Asterisk hears both directions, which means that ATSka sends the outgoing sound correctly.
In Wireshark, there are suspicious "Inserted Stubs" on the playback graph, I did not find out their origin.

What is checked:

• disabling/impacting SIP ALG on Mikrotik
  
• codec change
  
• similar behavior for incoming calls
  
• disable qualify
  
• rtpkeepalive=1
  
• disable/change NAT settings in FreePBX
  
• Various ways to forward ports on Mikrotik
  
• interrupted call pause and unpause
  

UPD, what hasn't helped yet:

• ISP traffic dump shows RTP packets in BOTH directions. Port numbers match on both sides
  
• switching to a new version of Asterisk\FreePBX
  
• switching to another provider (of the same name as the trunk provider)
  

Again, I don't think it's a NAT issue, since it doesn't always happen, all the specified ports are forwarded, and other than that, the connection works fine.
The provider looked at the dump of my call for a week, which they themselves recorded. We talked with the vendor, in their words:
The logic of the SDP version number formation was corrected to the fact that the parameter in the "o=" attribute line increases by 1 only if the SDP body changes.
but it did not help.

In what other direction can you look?

Answer 1

see how the traffic goes with a sniffer and dig there already?
wireshark is able to restore the conversation from the recorded traffic and play it back

Answer 2

Without a call dump, you can only guess, send a dump of a problem call (you can in a personal message if you are afraid of attacks). It would be ideal to see the DUMP on the WAN port of Mikrotik. If the problem is floating, I would sin on Mikrotik.
qualify=yes why do you need it? if registration insecure=port,invite