Hello!
Can I use memcached for usrloc db?
-- WBR, Victor JID: coyote@bks.tv JID: coyote@bryansktel.ru I use FREE operation system: 3.9.2-calculate GNU/Linux
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
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@bks.tv JID: coyote@bryansktel.ru I use FREE operation system: 3.9.2-calculate GNU/Linux
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
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@bks.tv JID: coyote@bryansktel.ru I use FREE operation system: 3.9.2-calculate GNU/Linux
On 21.05.2013 11:50, Victor V. Kustov wrote:
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_replicateIn my case i think carp better :)
carp requires the hosts to be on the same layer 2 network, while t_replicate provides the possibility of geo redundancy.
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@bks.tv JID: coyote@bryansktel.ru I use FREE operation system: 3.9.2-calculate GNU/Linux
21 maj 2013 kl. 10:45 skrev "Victor V. Kustov" coyote@bks.tv:
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.
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.
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@bks.tv JID: coyote@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
21 maj 2013 kl. 10:52 skrev Alex Balashov abalashov@evaristesys.com:
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
On 5/21/13 11:00 AM, Olle E. Johansson wrote:
21 maj 2013 kl. 10:52 skrev Alex Balashov abalashov@evaristesys.com:
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?
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
-
Alex Balashov -
Daniel-Constantin Mierla -
Olle E. Johansson -
Victor V. Kustov -
Øyvind Kolbu