Freeswitch + NAT?

Question

FreeSWITCH

There is FS: Version 1.6.6 -13-d2d0b32 64bit
FS is behind nat, auto-nat works, ports are forwarded correctly. Gray address 10.10.10.10/30
I have client Alice behind nat, gray address: 10.1.1.1/24
I have client Bob behind nat, gray address: 10.2.2.2/24

Alice (10.1.1.1/24) [NAT] --- [NAT] FS (10.10.10.10/30) [NAT] --- [NAT] Bob (10.2.2.2/24)

Alice calls to FS to listen to moh or voice mail. FS ALWAYS correctly determines NAT, replaces the address 10.1.1.1 with a real external one, as a result we always have a vote.
Alice calls to Bob. As a result, Bob always gets audio, while Alice never does. In the logs, I can clearly see that FS changes Bob's address 10.2.2.2 to a real external one, but does not perform this procedure with Alice's address! As a result, voice data is trying to be sent from the gray address FS 10.10.10.10/30 to the gray address Alice 10.1.1.1/24. Confirmed by wireshark on the machine with FS, as well as on the default gateway where this traffic arrives for routing.
I googled up and down, tried everything I could. But no way.
UPD
=================
So the problem seems to be solved.
In short, for both SDP and RTP to work properly , your client MUST be able to STUN and ICE . And, of course, both of these settings must be activated.
Either: enable RPORT for both media and signal packets. Tested on Zoiper which lacks ICE.
If even longer. I hope this will be useful to someone.
Looking at the above example, we can see that Alice has the address 10.1.1.1.
When she sends an INVITE, it will have parts like this:

...
c=IN IP 10.1.1.1
...
m=audio 7076 RTP/SAVP 0 8 3 96 101
c=IN IP4 <b>10.1.1.1</b>
...

Pay attention to the second occurrence of the address: the client tells him where to expect voice data. Of course, this address is not accessible from the outside. It is necessary in any way to force the client to determine the real external address and put it here in order to expect voice data from outside.
Any possibility is suitable for this: UPnP, STUN + ICE, manually overwriting SDP, and so on.

Answer 1

in sofia-profile

<param name="apply-nat-acl" value="rfc1918"/>
<param name="nat-options-ping" value="true"/>
<param name="aggressive-nat-detection" value="true"/>
<param name="NDLB-force-rport" value="true"/>

Answer 2

Alice "receives" the voice data in the early-media stage, when she should hear the dial tone. However, the data is “sent” to the wrong address, so, of course, there is no beep, and after the connection is established, FS continues to send data “in the wrong direction”