Hi,
I'm running a cloud infrastructure with multiple sip domains and I have some kamailio's as registrars with dmq for usrloc replication. The kamailio registrars are configured without db, so the aors are in ram.
For some gui's I need to get all aors for one sip domain, If I execute ul.dump I get all aors, but I want only a few. In my situation it would be perfect to get all registrations for one sip domain in one request (memory, performance, cache at gui...)
I thought I could save the registers with save("$rd") but ul.dump doesn't allow any parameter that restricts the "location" domain.
Is there any solution for this?
Best regards
On Jun 10, 2022, at 4:39 AM, Jose Fco. Irles Durá josefu@gmail.com wrote:
Hi,
I'm running a cloud infrastructure with multiple sip domains and I have some kamailio's as registrars with dmq for usrloc replication. The kamailio registrars are configured without db, so the aors are in ram.
For some gui's I need to get all aors for one sip domain, If I execute ul.dump I get all aors, but I want only a few. In my situation it would be perfect to get all registrations for one sip domain in one request (memory, performance, cache at gui...)
I thought I could save the registers with save("$rd") but ul.dump doesn't allow any parameter that restricts the "location" domain.
Is there any solution for this?
Best regards
In my mind, the filtering would require CPU. I’d rather something external parse the data (like a script or simple go program) to filter the data needed than Kamailio (leaving Kamailio CPU to RTC handling).
Generally, I pull the dump and then parse it outside of kamailio.
Fred Posner fred@palner.com
In my previous plattform version kamailio saves location to a postgresql and my gui's gets the contacts from db directly but in the new version I want to avoid databases.
I have around 20000 users by partition and for one partition the ul.dump is slow (~5-7 seconds) and not necessary because not all contacts are needed.
Another option is a dedicated kamailio saving the contacts to the database (like the previous version) or add logic at registrar to save the contact data to a redis for example.
Best regards
El vie, 10 jun 2022 a las 14:10, Fred Posner (fred@palner.com) escribió:
On Jun 10, 2022, at 4:39 AM, Jose Fco. Irles Durá josefu@gmail.com
wrote:
Hi,
I'm running a cloud infrastructure with multiple sip domains and I have
some kamailio's as registrars with dmq for usrloc replication.
The kamailio registrars are configured without db, so the aors are in
ram.
For some gui's I need to get all aors for one sip domain, If I execute
ul.dump I get all aors, but I want only a few. In my situation it would be perfect to get all registrations for one sip domain in one request (memory, performance, cache at gui...)
I thought I could save the registers with save("$rd") but ul.dump
doesn't allow any parameter that restricts the "location" domain.
Is there any solution for this?
Best regards
In my mind, the filtering would require CPU. I’d rather something external parse the data (like a script or simple go program) to filter the data needed than Kamailio (leaving Kamailio CPU to RTC handling).
Generally, I pull the dump and then parse it outside of kamailio.
Fred Posner fred@palner.com
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
I have a system with a separate kamailio saving contacts to a database and it can handle at least 180000 contacts (600 domains with 300 users each) re-registering every 10 minutes.
On 10 June 2022 2:14:04 pm UTC, "Jose Fco. Irles Durá" josefu@gmail.com wrote:
In my previous plattform version kamailio saves location to a postgresql and my gui's gets the contacts from db directly but in the new version I want to avoid databases.
I have around 20000 users by partition and for one partition the ul.dump is slow (~5-7 seconds) and not necessary because not all contacts are needed.
Another option is a dedicated kamailio saving the contacts to the database (like the previous version) or add logic at registrar to save the contact data to a redis for example.
Best regards
El vie, 10 jun 2022 a las 14:10, Fred Posner (fred@palner.com) escribió:
On Jun 10, 2022, at 4:39 AM, Jose Fco. Irles Durá josefu@gmail.com
wrote:
Hi,
I'm running a cloud infrastructure with multiple sip domains and I have
some kamailio's as registrars with dmq for usrloc replication.
The kamailio registrars are configured without db, so the aors are in
ram.
For some gui's I need to get all aors for one sip domain, If I execute
ul.dump I get all aors, but I want only a few. In my situation it would be perfect to get all registrations for one sip domain in one request (memory, performance, cache at gui...)
I thought I could save the registers with save("$rd") but ul.dump
doesn't allow any parameter that restricts the "location" domain.
Is there any solution for this?
Best regards
In my mind, the filtering would require CPU. I’d rather something external parse the data (like a script or simple go program) to filter the data needed than Kamailio (leaving Kamailio CPU to RTC handling).
Generally, I pull the dump and then parse it outside of kamailio.
Fred Posner fred@palner.com
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Jose Fco. Irles Durá
So, I think that the most simple is that, a separate kamailio saving contacts to the database.
Thanks for the information.
El sáb, 11 jun 2022 a las 2:28, Tim Anderson (tim@claritynetworks.com.au) escribió:
I have a system with a separate kamailio saving contacts to a database and it can handle at least 180000 contacts (600 domains with 300 users each) re-registering every 10 minutes.
On 10 June 2022 2:14:04 pm UTC, "Jose Fco. Irles Durá" josefu@gmail.com wrote:
In my previous plattform version kamailio saves location to a postgresql and my gui's gets the contacts from db directly but in the new version I want to avoid databases.
I have around 20000 users by partition and for one partition the ul.dump is slow (~5-7 seconds) and not necessary because not all contacts are needed.
Another option is a dedicated kamailio saving the contacts to the database (like the previous version) or add logic at registrar to save the contact data to a redis for example.
Best regards
El vie, 10 jun 2022 a las 14:10, Fred Posner (fred@palner.com) escribió:
On Jun 10, 2022, at 4:39 AM, Jose Fco. Irles Durá josefu@gmail.com
wrote:
Hi,
I'm running a cloud infrastructure with multiple sip domains and I
have some kamailio's as registrars with dmq for usrloc replication.
The kamailio registrars are configured without db, so the aors are in
ram.
For some gui's I need to get all aors for one sip domain, If I execute
ul.dump I get all aors, but I want only a few. In my situation it would be perfect to get all registrations for one sip domain in one request (memory, performance, cache at gui...)
I thought I could save the registers with save("$rd") but ul.dump
doesn't allow any parameter that restricts the "location" domain.
Is there any solution for this?
Best regards
In my mind, the filtering would require CPU. I’d rather something external parse the data (like a script or simple go program) to filter the data needed than Kamailio (leaving Kamailio CPU to RTC handling).
Generally, I pull the dump and then parse it outside of kamailio.
Fred Posner fred@palner.com
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Jose Fco. Irles Durá
-- Sent from my Android device with K-9 Mail. Please excuse my brevity. __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Fred Posner -
Jose Fco. Irles Durá -
Tim Anderson