[Freeswitch-users] moh, bypass_media and nat

[Sandro Bordacchini]

Hi everyone.

I have a FS 1.6.16 on a machine with public IP X.Y.Z.102. Server
configuration has bypass_media=true.
Two SIP phones 204 (Cisco SPA504G,192.168.16.212) and 202 (Snom M300,
192.168.16.187) are in a lan behind a NAT device ( X.Y.Z.98 ).
They correctly register against the same internal profile:

root at freeswitch:~# egrep "media|negot|hold|nat"
/etc/freeswitch/sip_profiles/internal.xml
                <param name="hold-music" value="$${hold_music}"/>
                <param name="apply-nat-acl" value="nat.auto"/>
                <param name="inbound-late-negotiation" value="true"/>
                <param name="inbound-codec-negotiation" value="generous"/>
                <param name="rtp-hold-timeout-sec" value="1800"/>
                <param name="inbound-late-negotiation" value="true"/>
                <param name="media-option" value="resume-media-on-hold"/>

"show registrations" show for both fs_nat=yes and a correct fs_path.
Calls between them are fine.

I have a problem when one of the parties puts the other one on hold.
See here when 204 puts 202 on hold:
https://pastebin.freeswitch.org/view/d1a94c8b
202 does not hear music on hold.
I dumped the traffic and i realized that FS is sending (some) media to the
phone, but not to the NAT address: it is sending it to the private IP (and
of course that gets lost in routing).

2019-09-24 17:53:42.414911 [DEBUG] switch_core_media.c:6803 AUDIO RTP
[sofia/internal/202 at 192.168.16.187:65532] X.Y.Z.102 port 31828 ->
192.168.16.187 port 50028 codec: 8 ms: 20

In other cases I have seen logs like "Auto Changing audio port from ... to
..." that "redirect the stream from the private ip to the public natted ip,
but this is not the case.

If I set bypass_media to false, everything works fine.
Even if I start the call with bypass_media set to true, then get back FS in
the rtp stream with uuid_media and finally hold 202, everything works fine.

Am I missing some configuration parameter?

Thanks in advance to everyone.

Sandro B.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20190924/32d12900/attachment.html>