Your client should be doing the NAT Traversal in this case, using STUN to discover its public IP, then using that IP in the packets, along with enabling rport on the client side, that would help this greatly, FreeSWITCH will auto adjust the rest if you can get that media part to work. On Tue, Nov 11, 2014 at 11:11 AM, Bill Ross <rossbcan@gmail.com> wrote:

Folks

FS: 1.4.13 / OpenWrt

Topology

SIP Phone <-> WIFI AP / NAT <-> Cloud <-> Router / NAT <-> Router / NAT <-> FS

192.168.10.x Public IP 192.168.1.x 10.0.0.128

The SIP packets traverse the NAT chain correctly.

The RTP packets from / to Phone are from / to 192.168.10.x, so, not getting through (because private N/W addresses embedded in SIP messaging)

I am considering the following methods of handling this, but, before doing a lot of work / research, is there a better method?

1 - Using firewall rules (somehow, if possible, connection tracking?) to SNAT/DNAT packets to/from private network ranges which are not local lan range

2 – (appears simplest) Using channel variables (addresses) from SIP messaging to alter addresses prior to bridge.

Any thoughts?

Thanks;

Bill Ross

_________________________________________________________________________ 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

-- *Brian West* brian@freeswitch.org *Twitter: @FreeSWITCH , @briankwest* http://www.freeswitchbook.com http://www.freeswitchcookbook.com *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378) *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest