[Serusers] rtpproxy

Klaus Darilion klaus.mailinglists at pernau.at
Wed Mar 17 16:05:26 CET 2004


Hi Fabio!

It also depends on the configuration of your main proxy as the main 
proxy will save the contact address in the REGISTER requests.

If the NAT is symmetric, the SIP messages also has to use the outbound 
proxy for contacting the UA as shown below, as the pinhole in the NAT 
box is only open for requests from the same IP/port which received the 
REGISTER message:

UA1         UA2           outbound                 main
  -----INVITE-----------------> ---------INVITE------>

              <----INVITE------ <------INVITE---------

To do this, the outbound proxy also has to keep state of the location of 
the NATed UAs. I think this is hard to do with ser. Thus, I suggest to 
do not use a separate outbound proxy but integrate the NAT traversal 
into the main proxy (as iptel does).

Is someone else using ser+nathelper+rtpproxy successful in a plain 
outbound proxy configuration (comparable to the jasomi boxes)?

regards,
Klaus

Fábio Silvestri wrote:

> WoW
> 
> Klaus, from client with public IP I can reach nated client very well. My 
> problem is only when client with nat ip try to reach another client with 
> nat ip too.
> 
> The ser.cfg on Outbound proxy machine, has this configuration:
> 
>   route{
>         log(1, "-------------------------------------------\n");
>         log(1, "entering main loop (5060)\n");
> 
>         if (nat_uac_test("2")) {
>                 log(1, "src address different than via header->NAT 
> detected\n");
>                 log(1, "force_rport and fix_nated_contact and 
> setflag(5)\n");
>                 #try NAT traversal, works only if the client is symmetrical
>                 force_rport();
>                 fix_nated_contact();
>                 append_hf("P-hint: fixed NAT contact for request\r\n");
>                 # flag 5 indicates that incoming request is from NATed 
> client
>                 setflag(5);
>         };
>         record_route();
>         # loose-route processing
>         if (loose_route()) {
>                 t_relay();
>                 break;
>         };
>        #inserted by klaus
>        if (method=="INVITE") {
>                 log(1, "INVITE\n");
>                 record_route();
>                 force_rtp_proxy();
>                 /* set up reply processing */
>                 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();
>         };
> 
>   }
> 
>   #inserted by klaus
>   # all incoming replies for t_onrepli-ed transactions enter here
>   onreply_route[1] {
>         log(1, "REPLY\n");
>        if (status=~"[12][0-9][0-9]") {
>                 force_rtp_proxy();
>                 log(1, "PROXY\n");
>         }
>   }
> 
> 
> Klaus Darilion wrote:
> 
>> rtpproxy also works fine within this setup.
>>
>> Try if you can reach the natted client from an client with public IP. 
>> If this is not possible, maybe the conteact in the location table is 
>> wrong. Do you use fix_nated_contact(); and natping from the nathelper 
>> module to keep the bindings in the NAT boxes alive?
>>
>> Klaus
>>
>> Fábio Silvestri wrote:
>>
>>> Hi
>>>
>>> I'm still in trouble with using SER & rtpproxy.
>>>
>>> Everything works fine, just one only thing doesn't, if I'm registered 
>>> with my ATA186 with nated ip (192.168.0.2) I can dial and talk with 
>>> everybody on PSTN, but if I try to dial for another ATA186 (behind a 
>>> nat 192.168.1.2) or maibe for the number configured on second port on 
>>> ATA186, the call don't happen.
>>>
>>> I think this maibe a problem with rtpproxy, maibe they can't control 
>>> two sessions with behind nat; because if the second ATA186 has valid 
>>> IP, everything works fine.
>>>
>>>
>>
> 




More information about the sr-users mailing list