17 Mar
2004
17 Mar
'04
5:05 p.m.
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.