[Serusers] nathelper & rtpproxy forward call to other SER - sr-users

6 Nov 2003


      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();
        };
}