[Serusers] nathelper & rtpproxy forward call to other SER

Jiri Kuthan jiri at iptel.org
Fri Nov 7 00:34:05 CET 2003


At 07:28 PM 11/6/2003, Glenn Dalgliesh wrote:
>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();

a possible explanation is you dont setup t_on_reply here, like you
do it bellow. -jiri

>                   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();
>        };
>}
>_______________________________________________
>Serusers mailing list
>serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers

--
Jiri Kuthan            http://iptel.org/~jiri/ 




More information about the sr-users mailing list