<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">1.6 is now multiple years EOL. I would strongly suggest updating first to confirm if the same issue still exists before you spend more time on this issue.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 24, 2019, at 3:20 PM, Sandro Bordacchini <<a href="mailto:sandro.bordacchini@nems.it" class="">sandro.bordacchini@nems.it</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi everyone.</div><div class=""><br class=""></div><div class=""></div><div class="">I have a FS 1.6.16 on a machine with public IP X.Y.Z.102. Server configuration has bypass_media=true.</div><div class="">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
).</div><div class="">They correctly register against the same internal profile:<br class=""></div><div class=""></div><div class=""><br class="">root@freeswitch:~# egrep "media|negot|hold|nat" /etc/freeswitch/sip_profiles/internal.xml<br class=""> <param name="hold-music" value="$${hold_music}"/><br class=""> <param name="apply-nat-acl" value="nat.auto"/><br class=""> <param name="inbound-late-negotiation" value="true"/><br class=""> <param name="inbound-codec-negotiation" value="generous"/><br class=""> <param name="rtp-hold-timeout-sec" value="1800"/><br class=""> <param name="inbound-late-negotiation" value="true"/><br class=""> <param name="media-option" value="resume-media-on-hold"/></div><div class=""><br class=""></div><div class="">"show registrations" show for both fs_nat=yes and a correct fs_path.</div><div class="">Calls between them are fine.</div><div class=""><br class=""></div><div class="">I have a problem when one of the parties puts the other one on hold.</div><div class="">See here when 204 puts 202 on hold: <a href="https://pastebin.freeswitch.org/view/d1a94c8b" class="">https://pastebin.freeswitch.org/view/d1a94c8b</a></div><div class="">202 does not hear music on hold.</div><div class="">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).</div><div class=""><br class=""></div><div class="">2019-09-24 17:53:42.414911 [DEBUG] switch_core_media.c:6803 AUDIO RTP [sofia/internal/<a href="http://202@192.168.16.187:65532/" class="">202@192.168.16.187:65532</a>] X.Y.Z.102 port 31828 -> 192.168.16.187 port 50028 codec: 8 ms: 20
</div><div class=""><br class=""></div><div class="">In other cases I have seen logs like "<span style="color:rgb(38,50,56);font-family:Roboto,sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;display:inline;float:none" class="">Auto Changing audio port from</span> ... to ..." that "redirect the stream from the private ip to the public natted ip, but this is not the case.<br class=""></div><div class=""><br class=""></div><div class="">If I set bypass_media to false, everything works fine.</div><div class="">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.<br class=""></div><div class=""></div><div class=""><br class=""></div><div class="">Am I missing some configuration parameter?</div></div></div></blockquote></div><br class=""></body></html>