[OpenSIPS-Users] Issues with registration proxy

[Travis Manson-Drake]

Hey Patrick,

Thank you for the reply!

I managed to figure this out.

What ended up happening was my PBX value was in fact never being updated in the hash table for cached_local. I managed to fix it by using a pseudo variable as my value. For example:

                        cache_store("local","PBX","$avp(PBX)",1200);        is now          cache_store("local",’$fU’,"$avp(PBX)",1200);
                        if(cache_fetch("local","PBX",$avp(PBX)))                is now              if(cache_fetch("local",’$fU’,$avp(PBX)))

this way it build a new entry for each userID and what PBX it belongs to in the local hashtable.





From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Patrick Wakano
Sent: Tuesday, December 1, 2015 6:04 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] Issues with registration proxy

Hi,
I think cached attributes are like global variables, unique and valid in the whole Opensips execution. You can store them and fetch at any time regardless the message you are handling. So, as you suspect, the logic of the piece of code you showed will store for 1200s the value in cache for the first request that comes in. During this lifetime, any other subsequent request won't cause an update in its value. After 1200s the cached attribute will be deleted and the whole logic will repeat in the next request it receives.
Not sure why you tried to use the cache to store your domain, maybe because you need it later in your dialog. If this is the case rethink your logic and use dialog variables.
Patrick

On Tue, Dec 1, 2015 at 7:29 PM, Travis Manson-Drake <travism at simplybits.com<mailto:travism at simplybits.com>> wrote:
Hello Everyone!

Hope you’re all doing well.

I seem to be having an issue.

Basically I’m using OpenSIPS as a proxy that will receive request from UAC’s, then query a database to find out what Sipserver it belongs to then store the result with cachdb_local as an $avp variable, and finally modify the R-uri of the sip message to the UAC gets to the correct endpoint. I’ve got it working for the most part however I seem to be having an issue when I try to have multiple UAC’s hit the proxy.

I think whats happening is the value stored in memchache is the first Sipserver the proxy gets a request for.

For example:

If UAC1 sends a REGISTER to the proxy and the proxy finds out it belongs on SIPServ1 it then sets the AVP to sipserv1

Now a few minutes later UAC2 comes along with a same REGISTER request but this time it belongs to SIPServ2, however this time it receives a 403 bad auth from sipserv2.

Here’s my current logic for DB query and memcache store:

NOTE: This is also in the REQUEST Route section of my logic, so this takes place before it hits any other routing logic.

if(cache_fetch("local","PBX",$avp(PBX)))
                        {
                        $rd = $avp(PBX);
                        xlog("this is the value of the modified R-uri: $ru\n");
                        }
                else {
                        avp_db_query("select Servers.ipaddress from Servers where Servers.ID in (select phone.ServerID from phone where phone.mac in (select MAC FROM `phone_registrations` where auth_userid = '$fU'))", "$avp(PBX)");
                        cache_store("local","PBX","$avp(PBX)",1200);
                     }


Do you guys have any ideas on what I’m missing, or any advice?

Thank you in advanced!

Travis Manson-Drake
Voice Systems Analyst L1
Simply Bits, LLC
Now You’re Thinkin’ Smart!
5225 N. Sabino Canyon Road
Tucson, AZ 85750
Phone: 520-545-0311<tel:520-545-0311>
Fax: 520-545-7252<tel:520-545-7252>
Support Hotline: 5205450333<tel:5205450333>
www.simplybits.com<http://www.simplybits.com/>


_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20151202/7bd970b1/attachment-0001.htm>