The remote SDP will always show what the client sends, that can only be corrected at the client side. The NDLB options all refer to the return ip/port for sip, generally sending sip replies to where the packets came from. Unfortunately you can't do the same for RTP because it runs on a different port, which will be randomised by most NAT implementations, and may not even be the same ip. There's simply no way to guess it from the FS end. The mechanism FS does try to use in this situation is that when the client starts to send audio to a FS ip:port (the one in the local SDP), FS will see where the audio is coming from and auto-adjust to using that ip:port to send back to. The log shows when that happens. Perhaps this is what is happening on the conference server, but not on your own? It requires that the call be answered by FS, until then the client won't be sending audio. That does mean you won't hear ringing. Properly correcting the SDP IP is only possible on the client, or failing that on their NAT router (the latter is less preferable as the SIP ALG may interfere with other clients that do it correctly). The client can learn its external RTP ip:port through STUN - look to see if your client has any options to enable this. Sent from my iPad On 15 Dec 2012, at 12:09, Mimiko <vbvbrj@gmail.com> wrote:

Hello.

External profile is bind to port 5080 on public IP of FS server connected directly to server. Server has a public IP for serving external connections to some local services like IVR without any registration.

client -> internet -> FS -- is ok. client -> nat -> internet -> FS -- no sound.

I don't need any client registration for this calls, so no directory users are used. The external sip profile is from git. Only sip-ip and rtp-ip is equal to ext-sip-ip and ext-rtp-ip and is equal to external IP of FS server.

When a client behind a nat calls, in FS log remote SDP shows client's local lan ip, not public IP of the router thru which client get access to internet. Also channel name is sofia/external/internal-ip. I've tried aggressive-nat-detection, NDLB-force-rport, NDLB-sendrecv-in-session in sofia profile "external" ad even:

<extension name="sip_nat_detected" continue="true"> <condition field="${sip_nat_detected}" expression="^true$"> <action application="set" inline="true" data="sip-force-contact=NDLB-connectile-dysfunction"/> </condition> </extension>

in public.xml to no available. I tried two different soft phones. One does not get audio at all, other softphone get audio after about 5 sec, and in log I see that remote SDP IP had changed to client's public ip.

Interesting thing that the same softphone which never gets audio, does not have problem to connect to FS conference server.

What I am missing? -- Mimiko desu.

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

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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