On Fri, 30 Sep 2005 08:40:47 +0200, Greger V. Teigre wrote
I like the idea of using a module, but Jan's point on the slow queries is very true. You are trying to do something with a DB table that it was not meant to do. Here is an idea: - For all incoming calls, use avpops on a custom db table to store the caller using callee as a key (thus always writing over the previous caller) - When seeing *69, use caller as key in the db table to retrieve the last caller and set the ruri
All right... I took the best of both worlds and wrote a module to handle it, but which uses a custom table.
The table, callreturn, has 3 simple columns: username, domain, calleruri (with username being a primary key).
The module, callreturn, has 3 exported functions:
-insert_into_callreturn(); (inserts the current calling URI into the callreturn table) -is_in_callreturn(); (somewhat redundant, but checks without rewriting the RURI -cr_lookup(); (rewrites the RURI based on the value found in the callreturn table...
SO... I can have something which is along the lines of:
if((method=="INVITE") && !(uri =~ "^sip:*69")) { insert_into_callreturn(); };
And later:
if(uri =~ "^sip:*69") { cr_lookup(); };
It's an ugly module... but it works and will alleviate the messiness of having to make an avp_db_store work on a non avp-aware table (since I don't need extra stuff like type for the entry) and will make the call-returning fast without having to rely on a parse through ACC.
Whew. Now to see if I can make the code look less hideous. :)
N.