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@lists.iptel.org; Alex Bligh Subject: RE: [Serusers] Nathelper question
--On 10 July 2004 15:31 +1000 Zeus Ng zeus.ng@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