10 Jul
2004
10 Jul
'04
3:59 p.m.
Alex,
Can you redraw your diagram and place ser in the path as well. I don't
understand what you are trying to illustrate.
Personally, I've tried UAs behind two / three layers of NAT and it works, if
it's what you are trying to say.
Yes, there are situations where the logic break. Mostly, if one UA is behind
two NAT, one inner and one outer. The second UA is behind the same outer
NAT. As a service provider, it's not my problem. My logic perfectly handles
the outer NAT. As for the inner NAT, the client has to figure it out
internally.
Zeus
-----Original Message-----
From: Alex Bligh [mailto:alex@alex.org.uk]
Sent: Saturday, 10 July 2004 8:36 PM
To: Zeus Ng; 'ser'
Cc: serusers(a)lists.iptel.org; Alex Bligh
Subject: RE: [Serusers] Nathelper question
--On 10 July 2004 15:31 +1000 Zeus Ng <zeus.ng(a)isquare.com.au> wrote:
if (method=="INVITE") {
if (isflagset(4) && isflagset(5)) { /* NAT source & NAT dest. */
if (!exec_msg('echo $SIP_RURI | cut -d: -f2 | cut -d@
-f2 | grep
"$SIP_SRCIP" > /dev/null')) {
xlog("L_NOTICE", "UAs behind different NAT devices, forcing
rtpproxy\n");
force_rtp_proxy();
t_on_reply("2");
} else {
xlog("L_NOTICE", "UAs behind same NAT devices\n");
t_on_reply("3");
}
... Other situation, NAT -> Public, Public -> NAT ...
}
For the sake of pedantry, I think that test will give a false
positive (i.e. wrongly treat caller and callee as being
behind the same NAT) in situations similar to:
10.0.0.1 A -> NAT1 -192.168.0.1 \
|--> NAT3 --> 195.1.1.1
Internet 10.0.0.2 B -> NAT2 -192.168.0.2 /
Alex