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

[Tavis P]

actually, this would be better

        avp_printf("i:401", "$rd");
       
        if ( avp_check("i:401", "eq/$src_ip/g") )
        {
            xlog("L_INFO", "\"$si\" == \"$rd\"  ");
        }

Tavis P wrote:

>Opps i made a mistake, instead of "avp_write" you need to use
>"avp_printf" to store the pseudo variable into an AVP
>and when you are doing the comparison with avp_check you need an alias
>defined for the second AVP otherwise you might end up comparing the AVP
>with a literal value
>
>
>        modparam( "avpops", "avp_aliases", "dest_ip=i:401" )
>
>        avp_printf("i:400", "$si");
>        avp_printf("i:401", "$rd");
>
>        if ( avp_check("i:400", "eq/$dest_ip/g") )
>        {
>            xlog("L_INFO", "\"$si\" == \"$rd\"  ");
>        }
>
>
>Norman Brandinger wrote:
>
>  
>
>>I agree that the solution that was presented is BAD for the reasons
>>stated by both of us and probably more :)
>>
>>Perhaps using $Ri after the successful lookup() and comparing it to
>>the $src_ip AVP would work.
>>
>>The problem was trying to compare a pseudo variable with an AVP.
>>
>>
>>The doc <snipped below> does not state that pseudo variables can be
>>used by avp_write().
>>
>>Pseudo-variables can be used with following modules of OpenSER:
>>
>>* avpops - function “avp_printf()”
>>* xlog - functions “xlog()” and “xdbg()”
>>
>>I did try to use avp_write() to save a pseudo variable to an AVP but
>>was unsuccessful.
>>
>>Do you have an example of writing a pseudo variable to an AVP ?
>>
>>Regards,
>>Norm
>>
>>
>>
>>Tavis P wrote:
>>
>>    
>>
>>>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
>>>>
>>>>
>>>>    
>>>>        
>>>>
>>>
>>>
>>>  
>>>      
>>>
>>
>>    
>>
>
>
>_______________________________________________
>Users mailing list
>Users at openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
>
>
>  
>