You need to experiment with nathelper module and while doing that, you need to inspect the SIP messages in order to understand how it works. Only when you fully understand your scenarios, you will be able to properly configure, debg and setup kamailio. Best thing to do here is to use rtpproxy and relay media if needed. Another option would be to let the SDP untouched and let freeswitch do it's magic (if it can). Not sure if this will work in all scenarios. Calling fix_nated_sdp() on the SBC will definitely not work (you are just messing with the IP on the SDP and you don't know if the real RTP port on the NATed side will match the advertised port in your "fixed" SDP). Regards, Ovidiu Sas On Tue, Jan 25, 2011 at 1:23 PM, Bernhard Suttner <bernhard.suttner(a)winet.ch> wrote: could maybe break something. I am sure, that the fix_nated_sdp() would work in "some" cases but I am not sure, if the function could break something: fix_nated_sdp(3) Auftrag von Carsten Bock [mailto:sr-users-bounces@lists.sip-router.org] Im Auftrag von Bernhard Suttner (phones, pbxes, gateways) are using Kamailio as SBC. The SBC does t_relay() the message to a pool of FreeSWITCH Servers. kamailio to the PBX and the PBX does have a forwarding back to kamailio and in the end to freeswitch I have no audio because the PBX is behind a NAT and uses private ip addresses in all the SDP of 200 OK and 183 Session Progress. Therefore FreeSWITCH could not do the (very cool) RTP Auto-Adjustment (check if IP in incoming packet is different to the IP in the SDP) to detect the real IP address. function could break therefore I want to be very sure and use it only, if really necessary. Test which User-Agent or Server the peer (in this example the PBX) has, is not really possible because some devices does not send this header. fix_nated_sdp(3)