30 Sep
2005
30 Sep
'05
10:59 p.m.
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.