Hi,

The ext-xxx-ip is only needed if your external IP is private and nated to a public one defined on your router. This setting tells freeswitch to put directly the public IP in the contact and the SDP.

If it's not already the case, you should use a different internal profile (attached to your internal IP) to discuss with your IS. In this profile, you don't need to define any NAT setting.

Best Regards,
-- 
Vallimamod Abdullah
SIP Solutions
vma@sip.solutions
linkedin.com/in/vallimamod

.

On 25 May 2018, at 14:46, M Yudkowsky <speech@pobox.com> wrote:

Hi,

Thanks for your response, quite helpful.

On May 25, 2018, at 03:56 , Vallimamod Abdullah <vma@vallimamod.org> wrote:

<param name="inbound-proxy-media" value="true"/>
<param name="local-network-acl" value="localnet.auto"/>
<param name="ext-rtp-ip" value="$${external_rtp_ip}"/>
<param name="ext-sip-ip" value="$${external_sip_ip}"/>

These are not channel variables but profile params. So they have to be set on the profile configuration file under sip_profiles.

I expect I was not clear: the params are set in sip_profiles/(profile name).xml, where "profile name" is a valid profile name.

And for your case, if all your traffic is internal on this profile, remove the last 2 params (ext-sip-ip and est-rtp-ip) as freeswitch use them to set the public ip on the contact and SDP if your server is nated.

Going back to my original diagram, let me add the external leg explicitly:

IS (internal IP)  == INVITE ==> FS (internal IP)
IS (internal IP)  <== 100 == FS (internal IP)
IS (internal IP)  <== 183 == FS (internal IP)

 FS starts a call to the external provider:

                                FS (external IP) == INVITE ==> SIP PROVIDER
                                FS (external IP) <== 200 OK == SIP PROVIDER
                                FS (external IP) == ACK ==> SIP PROVIDER

 FS continues the internal call:

IS (internal IP)  <== 200 OK == FS (internal IP)

 But the 200 OK from FS contains, in the Contact field, the *external* IP address:
 Contact: <sip:xxxxx@(external IP):5060;transport=udp>
 As a result, the IS sends a response to the *external* IP address:

IS (external IP)  == ACK ==> FS (external IP)

 FS resends several 200's, which IS properly ignores.
 Eventually FS gives up on hearing from IS and sends a
 BYE with a Reason of 408 ACK Timeout.

Just to check, then: is the   and ext-sip-ip somehow too aggressive, and I should rely on NAT and localnet.auto and other automatic discovery mechanisms instead? Or is this configuration correct, and I have a different problem?



--
 Moshe Yudkowsky
 Disaggregate Corporation
 2952 W Fargo
 Chicago, IL 60645 USA

 +1 773 764 8727
  speech@pobox.com

  http://www.Disaggregate.com
  http://www.PebbleAndAvalanche.com







_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org