Rafael R. GV wrote:

Hi I am still trying to solve this issue: ...using avpops to enable SER to see if the UAs are located behind the same address and then trying to let the UAs speak directly to each other (without force rtpproxy), please see my config. below and send some advice for what do I have to do in route 3?

... if (!lookup("location")) { log(1,"unable to locate user X ... sending to route(4)! \n"); # handle user which was not found route(4); break; };

            ### Test if UAS are in the same NAT:
            # get the host part of the final uri (IP part) and

store it in AVP ID 13

            avp_write("$ruri/domain", "i:13");
            if (avp_check("i:13","eq/$src_ip/i")) {
                    log(1, "source IP is the same as destination

IP\n"); route(3) ;t_on_reply("3"); break; }; avp_delete("i:13/g"); ... # -------------- Same NAT Call Routing (no force rtpproxy) ----

route[3]{ log(1," route[3]: UAs are in the same nat, NO force_rtp_proxy "); fix_nated_contact(); if(!t_relay()){ sl_reply_error(); }; log(1, "Route[3]: Send it out now!!!\n"); }

thanks rafael

Just want to mention that if your clients use STUN than this fix will not work (as the client acts like it is on a routable IP), however i have encountered many issues with NATs that do not hairpin RTP data from clients behind the same NAT to each other.

My solution was to detect (using similar logic to that above) if both clients are coming from the same IP address and force RTP/Media proxy otherwise the call would have no audio

Its a little OT but i thought i would mention it

---

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Another, more lightweight solution, is:

After a successful lookup(location) you can compare the received IP address ($si) with the destination domain/ip address returned from the "lookup" function call ($rd), i think these two pieces of information are reliable for this purpose

This way you don't have to make extra database calls to determine locality

Also if you want to compare pseudo variables you can first write them to an AVP using "avp_write" and then you can make use of "avp_check" with data sourced from a pseudo variable

Norman Brandinger wrote:

I have looked into the problem related to saving saving resources by not calling rtpproxy or mediaproxy when both the caller and callee are behind the same NAT.

This topic has been discussed many times however, there have been no "working" examples, or even partial examples posted (that I'm aware of).

Below is a solution to the problem, but is a BAD hack at best.

This solution is BAD because AVP's are added to the usr_preferences table during the registration process, but there is no notification that a registration has expired and is no longer valid. A cron job could be run periodically to delete all received_ip AVP's with no matching entry in the location table, but this is another hack to fix the first hack.

The solution is BAD because a database calls must be made to save the received_ip address into an AVP, then another database call must be made to reload the value just so that it can be tested against the caller's $src_ip. A pseudo variable $Ri already exists that contains the value we use in received_ip, but I have not been able to find a way for avp_check() to use $Ri.

The solution is BAD because it will fail when the SIP device(s) are behind more than a single NAT router. I believe this is not an issue for 95% of the users and 99% of the small office or home users.

I think that a better solution would be to enhance avp_check() to accept pseudo variables for the "value" parameter. This would remove the need for any database calls.

I'm cross-posting this response to the developers list to bring this to their attention and ask for suggestions (it's possible that I've totally missed something). If a decision is made to open the avpops module to pseudo variables (other than just avp_print()), I would suggest the following be looked at:

avp_check() the value parm should accept pseudo variables avp_write() the value parm should accept pseudo variables avp_pushto() the name parameter should accept pseudo variables avp_op() the value parameter should accept pseudo variables

Regards, Norm

1. During REGISTER processing, place the following code. I would

suggest that you put the code "after" all authentication checks and "after" the save("location") statement.

# Delete any previously saved IP addressess from the user. avp_db_delete("$from/username","s:received_ip");

# Save the source IP address of the user into an AVP called received_ip. # The saved IP address should be the public address of the NAT router. avp_write("$src_ip", "s:received_ip");

# Save the AVP received_ip into the usr_preferences tables associated with the user that just registered avp_db_store("$from/username","s:received_ip");

2. During INVITE processing (or wherever you make the decision to use

or not use rtpproxy / mediaproxy) , place the following code.

#---------------------------------------------------------------------------

# Are the caller and callee behind the same NAT ?

#---------------------------------------------------------------------------

avp_db_load("$to/username", "s:received_ip"); if (avp_check("s:received_ip", "eq/$src_ip")) { setflag(CALLER_AND_CALLEE_ ARE_BEHIND_THE_SAME_NAT); };

---

Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel

Interesting! In my particular case, it's a Netgear ADSL router running a version of uCLinux or something similar. The Netgear firmware is apparently available for download (minus some proprietry WWW frontend and related stuff) in order to comply to the GPLv2, but I haven't taken the time to do this in order to check which Netfilter modules are being used by the particluar 2.4.x kernel. In any case, I'm not particularly good at C, so it wouldn't do me any good anyway. However, in my experience the "statefulness" of a Linux Netfilter-based gateway should be sufficient to be able to handle a situation like this transparently, unless there is still something fundamental that I'm missing.

Be that as it may, the simple question still remains: is it possible to handle more than one UA behind a single NAT gateway with a single SER setup on the outside of the NAT gateway (RFC 1918 address space inside, normal routable IP outside)? Alternatively, would it be best to have an inside SER that simply forwards all SIP traffic to the outside SER?

On Sun, 2005-12-04 at 11:05 +0100, Harry Behrens wrote:

could be an issue of the local gateway. most NAT devices explicitly block "hairpinning", which is happening in your case.

-h

Jan Henkins wrote:

...

Hello Rafael,

This is an issue I'm having at the moment as well, where two UA's are behind the same nat. SIP obviously works fine, I can ring one UA from the other (one UA a Grandstream Budgetone 100 and the other the X-Lite softphone from Counterpath). Audio doesn't work. Did you get this working with forcing rtpproxy?

On Fri, 2005-12-02 at 09:44 -0500, Rafael R. GV wrote:

...

Hi I need to let the UAs speak directly to each other without force rtpproxy, Is there any solution for this issue?

rafael

---------- Forwarded message ---------- From: Rafael J. Risco G.V. rafael.risco@gmail.com Date: Apr 22, 2005 2:17 PM Subject: UA´s behind same NAT using na thelper/rtpproxy, No Audio... To: serusers@lists.iptel.org

I am using avpops to enable SER to see if the UAs are located behind the same address and now I need to let the UAs speak directly to each other (without force rtpproxy), please someone see my configuration below and send some advice.

rafael

----. if (!lookup("location")) { log(1,"unable to locate user \n"); # handle user which was not found route(4); break; };

          ### Test if UAS are in the same NAT:
          # get the host part of the final uri (IP part)
          # and store it in AVP ID 13 

          avp_write("$ruri/domain", "i:13");
          if (avp_check("i:13","eq/$src_ip/i")) {
                  log(1, "source IP is the same as destination IP

\n"); route(3); break; }; avp_delete("i:13/g"); . . # -------------- Same NAT Call Routing (no force rtpproxy) ----

route[3]{ log(1," route[3]: UAs are in the same nat, NO force_rtp_proxy ");

### Do something!!!!

  if(!t_relay()){
          sl_reply_error();
  };

} _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Hello all,

On Sun, 2005-12-04 at 18:13 -0500, sip wrote:

If the gateway has no issues with hairpinning, then yes, it's quite possible. I use a Linksys gateway at home and a slightly older, pre-sip-proxy version of Astaro linux firewall at work, and we have multiple UAs behind each in the NAT space of our firewall. They can call each other. They can all outside. All based off registrations with a SER server on the outside of the network.

Could you perhaps tell me the model number of your Linksys gateway?

Netgear specifically has some serious issues both with hairpinning and with just plain ol' SIP. Netgear makes some mighty unfriendly gateways. :)

O dear... Well, nothing to be done about that right away though. Do you have some more information I can use in this regard? If possible I would like to present the chaps at Netgear with some kind of proof that their products are SIP unfriendly, and campaign them to change this. I know that this sounds a bit naive, but I have a bit of experience being a "thorn-in-the-flesh-consumer" with reticent vendors, and getting what I want! :-) They take competition with Linksys seriously, which is a good thing.

If you can't do it, though, it makes sense to set up some sort of proxy on the inside of the NAT that all the UAs register with, and have it pass things back and forth... forwarding the necessary data from outside to the server on the inside using port-fowarding rules. For some of our customers, we've recommended Asterisk setups inside their NAT, just to make the passing of RTP packets more rational. You don't have to worry about individual client UA RTP settings, you can just worry about forwarding the RTP ports to Asterisk, and then inside the NAT do anything you wish. Since SER doesn't manage RTP, using just SER becomes problematic if your UAs are not homogeneous.

OK, this makes a lot of sense. I was in the process setting up an Asterisk box anyway for PBX duty at home.