14 Oct
2013
14 Oct
'13
3:57 p.m.
Hi,
Klaus, thank you for pointing me in the right direction with SIP trunks,
got it working so thanks! Basically I did exactly what you said:
- Dialled number
- Match that number to a registered user (had to create a new table for
that)
- Lookup user
- Replace dialled s@ with original number dialled
Works like a charm, however, I have a question over speed and performance.
As this is a SQL query and not held in memory is this SQL lookup doing to
cause me problems? It's not a big query at the moment, but it could get
quite big as I will need to map each number to a registered trunk.
Many thanks,
Keith
14 Oct
14 Oct
5:46 p.m.
New subject: SIP Trunks
On 14.10.2013 14:57, Keith wrote:
Hi,
Klaus, thank you for pointing me in the right direction with SIP trunks,
got it working so thanks! Basically I did exactly what you said:
- Dialled number
- Match that number to a registered user (had to create a new table for
that)
- Lookup user
- Replace dialled s@ with original number dialled
Works like a charm, however, I have a question over speed and
performance. As this is a SQL query and not held in memory is this SQL
lookup doing to cause me problems? It's not a big query at the moment,
but it could get quite big as I will need to map each number to a
registered trunk.
It depends on your database. If the database is fast, this is usually
not a problem. Many Kamailio users e.g. use the usrloc module without
caching, thus every lookup() call requires a DB lookup. Also
authentication is usually not cached, and requires a DB lookup for every
SIP request (INVITE, REGISTER).
Thus, if the DB is fast, you are fine.
If the DB is slow or unreliable, then Kamailio is slow too. But usually
you anyway need the DB for accounting and authentication - thus if the
DB is not available quite often you do not want any calls to proceed (as
you can not bill them).
Anyway, if you are afraid of DB performance, or you have quite slow
queries which usually return the same result, you can use caching using
the htable module. See the readme. But a simple example (untested): e.g.
you want to cache the DID-to-user mapping for 1 hour.
modparam("htable", "htable",
"dids=>size=10;autoexpire=3600;")
route {
....
# incoming did is in $rU
# use the DID as hash key
$var(mapping) = $sht(a=>$rU);
if ( $var(mapping) ) {
xlog("Using cached mapping: $rU -> $var(mapping)");
$rU = $var(mapping);
} else {
# your code to load the mapping from DB into $var(mapping)
.....
xlog("Loaded mapping from DB: $rU -> $var(mapping)");
$rU = $var(mapping);
# put the mapping into the hash table
$sht(a=>$rU) = $var(mapping);
}
lookup(...);
regards
Klaus
5:52 p.m.
New subject: SIP Trunks
Ahhh, cool. Well the db is mysql and sits on the same box so probably fine.
Just don't really know.
I'll keep this in mind and apply if needed.
Thanks for all your help, amazing!
Keith
On Mon, Oct 14, 2013 at 3:46 PM, Klaus Darilion <
klaus.mailinglists(a)pernau.at> wrote:
On 14.10.2013 14:57, Keith wrote:
Hi,
Klaus, thank you for pointing me in the right direction with SIP trunks,
got it working so thanks! Basically I did exactly what you said:
- Dialled number
- Match that number to a registered user (had to create a new table for
that)
- Lookup user
- Replace dialled s@ with original number dialled
Works like a charm, however, I have a question over speed and
performance. As this is a SQL query and not held in memory is this SQL
lookup doing to cause me problems? It's not a big query at the moment,
but it could get quite big as I will need to map each number to a
registered trunk.
It depends on your database. If the database is fast, this is usually not
a problem. Many Kamailio users e.g. use the usrloc module without caching,
thus every lookup() call requires a DB lookup. Also authentication is
usually not cached, and requires a DB lookup for every SIP request (INVITE,
REGISTER).
Thus, if the DB is fast, you are fine.
If the DB is slow or unreliable, then Kamailio is slow too. But usually
you anyway need the DB for accounting and authentication - thus if the DB
is not available quite often you do not want any calls to proceed (as you
can not bill them).
Anyway, if you are afraid of DB performance, or you have quite slow
queries which usually return the same result, you can use caching using the
htable module. See the readme. But a simple example (untested): e.g. you
want to cache the DID-to-user mapping for 1 hour.
modparam("htable", "htable",
"dids=>size=10;autoexpire=**3600;")
route {
....
# incoming did is in $rU
# use the DID as hash key
$var(mapping) = $sht(a=>$rU);
if ( $var(mapping) ) {
xlog("Using cached mapping: $rU -> $var(mapping)");
$rU = $var(mapping);
} else {
# your code to load the mapping from DB into $var(mapping)
.....
xlog("Loaded mapping from DB: $rU -> $var(mapping)");
$rU = $var(mapping);
# put the mapping into the hash table
$sht(a=>$rU) = $var(mapping);
}
lookup(...);
regards
Klaus
4058
days inactive
4058
days old
2 comments
2 participants
participants (2)
-
Keith -
Klaus Darilion