<html><head/><body><html><head></head><body>Hi Bogdan.<br>
<br>
Thanks for your input. For now I will go with your second suggestion (move AVPs out of the way by prefixing them accordingly).<br>
<br>
Your first suggestion won&#39;t work in my case, I thonk, since we&#39;re using db_text as the only db backend (so avp_db_query() is no option). Plus it would not help much with avoiding aditional queries in thos use-case, as they would still be required to get the calleeā€˜s limits.<br>
<br>
Bye, Mike<br><br><div class="gmail_quote">Bogdan-Andrei Iancu &lt;bogdan@opensips.org&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: monospace; margin-top: 0px">Hi Mike,<br /><br />Some ideas :<br /><br />1) I do not use the usr_preference like table as I do not like to do an <br />extra query for the user profile - usually I put extra attrs in the <br />subscriber table (as additional columns) and load them during auth (via <br />load_credentials) or via avp_db_query or avp_db_load + db_schema<br /><br />2) prefix the avp from caller and callee differently - after loading the <br />avp, do a "move" with avp_copy().<br /><br />Maybe the best think to do in the future is to make "avp_db_load" to <br />take an optional prefix to use when loading the AVP, so same AVP from DB <br />(like "inbound-CCL" ) would be loaded as "caller_inbound-CCL"  or <br />"callee_inbound-CCL" .<br /><br />Regards,<br /><br />Bogdan-Andrei Iancu<br />OpenSIPS Founder and Developer<br /><a href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a><br
/><br /><br />On 02/06/2013 11:23 AM, Michael Renzmann wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Hi.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">IIRC, avp_db_load() should work with dbtext:<br /></blockquote>yes, it does.<br /></blockquote>Confirmed, we're using this combination successfully already. The reason<br />why I want to also use avp_db_query() is the following:<br /><br />We have various attributes for every user in usr_preferences, among them<br />two called "inbound_channels" and "outbound_channels" meant for limiting<br />concurrent calls. We check for and apply concurrent call limitations in a<br />separate route, which is called from REQUEST_ROUTE. This already works<br />fine for
outbound calls.<br /><br />Now I'm trying to implement inbound call limitations and face the<br />following issue for user-to-user calls. The currently loaded AVPs describe<br />various aspects (inbound_channels, outbound_channels and other stuff) of<br />the caller. I need to get at least the callee's inbound_channels<br />attribute. avp_load() cannot easily be used for this purpose, since it<br />loads all attributes defined for the callee, overwriting those of the<br />caller which are still required for call processing further down the road.<br />Using avp_copy() to save/restore caller AVPs doesn't appear like a good<br />idea, not only because it'd require to explicitly reference all possibly<br />used attributes in the script (even those that are not necessarily set for<br />each user). Throwing away all AVPs after the inbound-CCL followed by an<br />avp_load() to restore the caller's attributes is an even worse idea, I<br />think - it is additional database load, and it won't
restore those AVPs<br />which have been set dynamically during call processing before the<br />CCL-route was called.<br /><br />With avp_db_query() it would have been possible to query the callee's<br />inbound_channels attribute and store it in a differently named AVP (say,<br />callee_inbound_channels). Collission avoided, all well - but unfortunately<br />not possible with db_text. Switching to another database is no option at<br />this point.<br /><br />If you have any ideas how I could solve this in a db_text-compatible way,<br />I'm all ears.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">The avp_db_query which used raw queries is the only one<br />not working.<br /></blockquote>I'll try to deliver information on how to reproduce the crash.<br /><br />Bye, Mike<br /><br /><hr /><br />Users mailing list<br />Users@lists.opensips.org<br /><a
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a></blockquote><br /></pre></blockquote></div><br>
-- <br>
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.</body></html></body></html>