29 Sep
2005
29 Sep
'05
3:22 p.m.
Well, I ended up muddling through the module API long enough to write a module
to handle a specific scenario. Some of our UAs have *69 capability (call
return here in the US of A), some don't... so I wrote a module that takes data
from our ACC log (using a raw query since the regular query doesn't have the
LIKE functionality) and finds out who the last user to send an invite to the
currently dialing user was and connects the call accordingly.
I understand that this may be a little like trimming a mustache with a
weedwacker, but the severely limited set of available database manipulation
operations available through existing modules made this somewhat useful (to
me, anyway).
The question really comes down to... what sort of overhead does it incur to do
something like this? Granted, not everyone and his brother shall be calling
*69 on an even semi-regular basis among my userbase, so it won't even process
much... but should I expect the bottleneck to be (as I expect it is) the
database server and its query speeds?
N.
29 Sep
29 Sep
3:51 p.m.
On 29-09-2005 09:22, sip wrote:
Well, I ended up muddling through the module API long
enough to write a module
to handle a specific scenario. Some of our UAs have *69 capability (call
return here in the US of A), some don't... so I wrote a module that takes data
from our ACC log (using a raw query since the regular query doesn't have the
LIKE functionality) and finds out who the last user to send an invite to the
currently dialing user was and connects the call accordingly.
I understand that this may be a little like trimming a mustache with a
weedwacker, but the severely limited set of available database manipulation
operations available through existing modules made this somewhat useful (to
me, anyway).
The question really comes down to... what sort of overhead does it incur to do
something like this? Granted, not everyone and his brother shall be calling
*69 on an even semi-regular basis among my userbase, so it won't even process
much... but should I expect the bottleneck to be (as I expect it is) the
database server and its query speeds?
Exactly. The acc table can become huge (depending on the call rate)
and acc table related queries can take a long time. Especially if you
use regular expression matching which can be hardly optimized using
indexes in the database server.
In any case you should enable slow query log in mysql server and watch
for slow queries from time to time.
Jan.
30 Sep
30 Sep
8:40 a.m.
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
g-)
----- Original Message -----
From: "sip" <sip(a)arcdiv.com>
To: <serusers(a)lists.iptel.org>
Sent: Thursday, September 29, 2005 03:22 PM
Subject: [Serusers] Modules writing and overhead.
Well, I ended up muddling through the module API long
enough to write a
module
to handle a specific scenario. Some of our UAs have *69 capability (call
return here in the US of A), some don't... so I wrote a module that takes
data
from our ACC log (using a raw query since the regular query doesn't have
the
LIKE functionality) and finds out who the last user to send an invite to
the
currently dialing user was and connects the call accordingly.
I understand that this may be a little like trimming a mustache with a
weedwacker, but the severely limited set of available database
manipulation
operations available through existing modules made this somewhat useful
(to
me, anyway).
The question really comes down to... what sort of overhead does it incur
to do
something like this? Granted, not everyone and his brother shall be
calling
*69 on an even semi-regular basis among my userbase, so it won't even
process
much... but should I expect the bottleneck to be (as I expect it is) the
database server and its query speeds?
N.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:20 a.m.
New subject: [Serusers] mediaproxy
Hello,
I am just looking on how to tell ser that a mediaproxy is on a different
server.
How to indicate that in the modparam?
modparam("mediaproxy", "mediaproxy_socket",> "???")
Thanks,
Olivier
3 Oct
3 Oct
6:17 p.m.
New subject: [Serusers] mediaproxy
modparam("mediaproxy","mediaproxy_socket",
"/var/run/mediaproxy.sock")
it is the socket the mediaproxy, you down load and install the media proxy
is like rtpproxy.
http://www.voip-info.org/tiki-index.php?page=MediaProxy
and the media proxy download
http://mediaproxy.ag-projects.com/
30 Sep
30 Sep
9: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.
6787
days inactive
6791
days old
5 comments
5 participants
participants (5)
-
Greger V. Teigre -
Jan Janak -
Olivier Taylor -
sip -
Walter Willis