[Devel] [Users] nathelper/rtpproxy when both SIP UA are behind same NAT

Tavis P tavis.lists at galaxytelecom.net
Sun Dec 4 21:31:06 CET 2005


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 at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>
>





More information about the sr-users mailing list