21 May
2013
21 May
'13
10:03 a.m.
Hello!
Can I use memcached for usrloc db?
--
WBR, Victor
JID: coyote(a)bks.tv
JID: coyote(a)bryansktel.ru
I use FREE operation system: 3.9.2-calculate GNU/Linux
21 May
21 May
11:27 a.m.
Hi Victor,
On 05/21/2013 03:03 AM, Victor V. Kustov wrote:
Can I use memcached for usrloc db?
In principle, no; memcache is not supported as a database backend for
any module. The API plumbing is just not there.
However, it seems to me if you really, *really* wanted to, you could
implement a registrar manually, bypassing registrar + usrloc. You'd be
doing a lot of manual contact management that usrloc takes care of, though.
Why would you want to do that, though? If you desire the speed of a
memory-only lookup table, you can just use usrloc with db_mode 0:
http://kamailio.org/docs/modules/4.0.x/modules/usrloc.html#idp6002056
No database storage required at all.
If you really want to store contacts in memory but are not content with
usrloc's memory-only mode because you want persistence across Kamailio
restarts, there are numerous things you could do. You could set up an
in-memory table in MySQL, or a PostgreSQL "tablespace" that is
physically located on a filesystem mounted on a tmpfs filesystem and/or
ramdisk. You could also just have a separate registrar server using Path.
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
11:45 a.m.
Hello, Alex!
In principle, no; memcache is not supported as a
database backend for
any module. The API plumbing is just not there.
OK, i see.
However, it seems to me if you really, *really* wanted
to, you could
implement a registrar manually, bypassing registrar + usrloc. You'd
be doing a lot of manual contact management that usrloc takes care of,
though.
Look like i must go this way. But registrar - standard, usrloc -
bypassed.
Why would you want to do that, though? If you desire the speed of a
memory-only lookup table, you can just use usrloc with db_mode 0:
http://kamailio.org/docs/modules/4.0.x/modules/usrloc.html#idp6002056
No database storage required at all.
I need failover, so seem memcached more prefer.
My aim:
Two K. servers with shared IP (carp) with shared usrloc base, worked by
failover scheme.
authorize, authenticate, accounting - in radius. I think no
mysql/postgre needed at all in this scheme.
--
WBR, Victor
JID: coyote(a)bks.tv
JID: coyote(a)bryansktel.ru
I use FREE operation system: 3.9.2-calculate GNU/Linux
11:48 a.m.
On 05/21/2013 04:45 AM, Victor V. Kustov wrote:
I need failover, so seem memcached more prefer.
Why? You can replicate the location table with MySQL or Postgres.
Or, you can even have two registrars and use SIP-level message
replication between them:
http://kamailio.org/docs/modules/4.0.x/modules/tm.html#t_replicate
Memcached is a cache, not a redundant storage backend for complex,
nonscalar data. :-)
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
12:50 p.m.
Hello, Alex!
Why? You can replicate the location table with MySQL
or Postgres.
Memcached is a cache, not a redundant storage backend
for complex,
nonscalar data. :-)
memcached has replication. Data? USERNUMBER->IP, clear key->value.
Lifetime? Yes, SIP registration has lifetime too. When expired, refresh
registration. memcached can wrote cash to file. I think memcached 100%
usable for this. mysql/pgsql has large overhead.
Or, you can even have two registrars and use SIP-level
message
replication between them:
http://kamailio.org/docs/modules/4.0.x/modules/tm.html#t_replicate
In my case i think carp better :)
--
WBR, Victor
JID: coyote(a)bks.tv
JID: coyote(a)bryansktel.ru
I use FREE operation system: 3.9.2-calculate GNU/Linux
1:02 p.m.
On 21.05.2013 11:50, Victor V. Kustov wrote:
carp requires the hosts to be on the same layer 2 network, while
t_replicate provides the possibility of geo redundancy.
--
Øyvind
Or, you can
even have two registrars and use SIP-level message
replication between them:
http://kamailio.org/docs/modules/4.0.x/modules/tm.html#t_replicate
In my case i think carp better :)
4:27 p.m.
Hello, Øyvind!
carp requires the hosts to be on the same layer 2
network, while
t_replicate provides the possibility of geo redundancy.
We need our SIP clients route to PSTN and vise versa. yes, we
had two servers in one ethernet segment.
--
WBR, Victor
JID: coyote(a)bks.tv
JID: coyote(a)bryansktel.ru
I use FREE operation system: 3.9.2-calculate GNU/Linux
11:50 a.m.
21 maj 2013 kl. 10:45 skrev "Victor V. Kustov" <coyote(a)bks.tv>tv>:
Hello, Alex!
Remember that memcached is only a
CACHE, it's not a data repository.
Records will expire and the cache manager is in control of expiry. You can not
trust it to be reliable.
In principle, no; memcache is not supported as a
database backend for
any module. The API plumbing is just not there.
OK, i see.
However, it seems to me if you really, *really*
wanted to, you could
implement a registrar manually, bypassing registrar + usrloc. You'd
be doing a lot of manual contact management that usrloc takes care of,
though.
Look like i must go this way. But registrar - standard, usrloc -
bypassed.
Why would you want to do that, though? If you desire the speed of a
memory-only lookup table, you can just use usrloc with db_mode 0:
http://kamailio.org/docs/modules/4.0.x/modules/usrloc.html#idp6002056
No database storage required at all.
I need failover, so seem memcached more prefer.
My aim:
Two K. servers with shared IP (carp) with shared usrloc base, worked by
failover scheme.
Most of us just replicate the database or forward the REGISTER
messages between
two SIP proxys. That's why you have an option to SAVE() to make it not reply,
only silently update usrloc.
That way you can run in kamailio memory. You will not survive restarts of the
proxy though.
/O
authorize, authenticate, accounting - in radius. I think no
mysql/postgre needed at all in this scheme.
--
WBR, Victor
JID: coyote(a)bks.tv
JID: coyote(a)bryansktel.ru
I use FREE operation system: 3.9.2-calculate GNU/Linux
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:52 a.m.
The problem one always runs into when dealing with phones, softphones,
ATAs, and other end-user clients is getting them to trust incoming calls
from the secondary registrar in the event of a failure of the primary
one. Usually, they expect calls to come from the registrar that they
registered to, and few of them implement SRV correctly enough to solve
this problem.
This is not an issue with PBXs, where one can generally build two trunks
to two different hosts.
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
noon
New subject: src record support (new topic)
21 maj 2013 kl. 10:52 skrev Alex Balashov <abalashov(a)evaristesys.com>om>:
The problem one always runs into when dealing with
phones, softphones, ATAs, and other end-user clients is getting them to trust incoming
calls from the secondary registrar in the event of a failure of the primary one. Usually,
they expect calls to come from the registrar that they registered to, and few of them
implement SRV correctly enough to solve this problem.
Well, that's why we are
forced to use IP failover. Sad but true.
This is not an issue with PBXs, where one can generally build two trunks to two different
hosts.
Asterisk has been completely broken in regards of SRV support. It doesn't
fail over, it doesn't handle IPv6 and Ipv4 in SRV priorities correctly, and it
doesn't accept incoming calls from all hosts in the SRV record set.
I'm trying to fix that in my pgtips branch.
I don't know the state of FreeSwitch in regards of SRV support, nor do I know
what's planned for the new SIP stack in Asterisk.
In Kamailio - is there any way that we can check if a server that contacts us is part of a
SRV record set?
If I get a call from a server using the domain @evaristesys.com - can I check if that
server actually is defined as authorative for that domain by checking SRV records - and
without a TLS client cert?
/O
23 May
23 May
11:09 a.m.
New subject: src record support (new topic)
On 5/21/13 11:00 AM, Olle E. Johansson wrote:
21 maj 2013 kl. 10:52 skrev Alex Balashov
<abalashov(a)evaristesys.com>om>:
A dns-ops like module is somewhere in a dusty to-do list,
at this moment
a solution would be to use lua or other embedded language.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
* http://asipto.com/u/katu *
The problem one always runs into when dealing
with phones, softphones, ATAs, and other end-user clients is getting them to trust
incoming calls from the secondary registrar in the event of a failure of the primary one.
Usually, they expect calls to come from the registrar that they registered to, and few of
them implement SRV correctly enough to solve this problem.
Well, that's why we
are forced to use IP failover. Sad but true.
This is not an issue with PBXs, where one can
generally build two trunks to two different hosts.
Asterisk has been completely
broken in regards of SRV support. It doesn't fail over, it doesn't handle IPv6 and
Ipv4 in SRV priorities correctly, and it doesn't accept incoming calls from all hosts
in the SRV record set.
I'm trying to fix that in my pgtips branch.
I don't know the state of FreeSwitch in regards of SRV support, nor do I know
what's planned for the new SIP stack in Asterisk.
In Kamailio - is there any way that we can check if a server that contacts us is part of
a SRV record set?
If I get a call from a server using the domain @evaristesys.com - can I check if that
server actually is defined as authorative for that domain by checking SRV records - and
without a TLS client cert?
4232
days inactive
4234
days old
10 comments
5 participants
participants (5)
-
Alex Balashov -
Daniel-Constantin Mierla -
Olle E. Johansson -
Victor V. Kustov -
Øyvind Kolbu