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->NATdetected\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.