[Serusers] nathelper & rtpproxy forward call to other SER

Problem: One-way audio when forwarding that must go thru another negociate SER server before reaching Endpoint. I have gotten calls from SER with nathelper and rtp proxy to work reliably btw phones registered with SER box but when I trie to forward the call to a EXT on another SER box not running nathelper with register client with public ip's I get one way audio. After doing some snooping it appears that one direction of the rtp stream end up directed at the rtpproxy and the other direction goes directly to the phone. I know the sip messages must not be getting rewriten properly but I can't seem to get it right. this is the route section of my ser.cfg Thanks route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; }; # things we think we want to do for every request; # this box is dedicated to NAT only behavior record_route(); force_rport(); fix_nated_contact(); # loose-route processing if (loose_route()) { t_relay(); break; }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { save("location"); break; }; if (uri=~"^sip:[7][0][0][1]@") { rewritehost("sipdemo.xxxx.net"); fix_nated_sdp("3"); force_rtp_proxy(); t_relay(); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; if (method=="INVITE") { # This appears to make the called party's audio work fix_nated_sdp("3"); force_rtp_proxy(); # Call the onreply_route? This appears to link calling and called party's audio together t_on_reply("1"); }; # forward to current uri now; use stateful forwarding; that # works reliably even if we forward from TCP to UDP if (!t_relay()) { sl_reply_error(); }; } # This appears to make calling party's audio work onreply_route[1] { if (status=~"2[0-9][0-9]") { force_rport(); fix_nated_contact(); fix_nated_sdp("3"); force_rtp_proxy(); }; }