Good morning.
We've got a problem with location memory and database replication between "n" kamailios as REGISTRAR servers.
1.- WHAT WE WANNA DO:
- To have "n" Kamailios with their DB and memory "user location" replicated. - Each Kamailio owns its own DB.(It could be also with a common DB). - Each kamailio has a PUA_REGINFO, PRESENCE, and REGISTRAR roles. - USRLOC Module with db_mode = 2 (Write-Back scheme).
2.- WHAT WE DON'T WANNA DO:
- USRLOC Module with db_mode != 2 (Write-Back scheme).
3.- BACKGROUND:
- RFC3265 - RFC3680 - RFC3903 - I attach a small architecture graph.
4.- PROBLEMS:
4.1 Deadlock:
Each REGISTER involves a NOTIFY to the other side. Each NOTIFY involves another NOTIFY to the other side.
There should be a mechanism to avoid PUBLISH reginfo_handle_notify() function calls but to PUBLISH save() calls on pua_reginfo module.
Any idea would be appreciated (also to workaround our problem).
4.2 PUA_REGINFO module notify.c
Just FYI.
We think It doesn't comply to RFC3680. It should observe "unkown-param" object to aid "Contact" header params such as "Path", "Received", "User_agent" and so on.
We've changed code but for a fast startup we've also avoided "unkown-param" and now we're able to see replicated "Path", "Received ... params on each DB.
Thanks and best regards.
Eduardo Lejarreta.
Hello,
as I understood, the issue was that when pua_reginfo received a notify and inserted a record in location table, usrloc executed a callback in pua_reginfo to send notify, which can result in endless cross notifications between nodes.
If yes, I pushed a patch in master branch, can you test and see if it works? If all ok, it will be considered for backport in stable branches.
On the other hand, I am not sure it works when the topology is like a linear (circular) list, thus it might need to be wrapped as config option -- this just came in my mind, not analysis for it, maybe this is not feasible at all anyhow.
Cheers, Daniel
On 03/11/14 12:50, lejarreta.e@sarenet.es wrote:
Good morning.
We've got a problem with location memory and database replication between "n" kamailios as REGISTRAR servers.
1.- WHAT WE WANNA DO:
- To have "n" Kamailios with their DB and memory "user location"
replicated.
- Each Kamailio owns its own DB.(It could be also with a common DB).
- Each kamailio has a PUA_REGINFO, PRESENCE, and REGISTRAR roles.
- USRLOC Module with db_mode = 2 (Write-Back scheme).
2.- WHAT WE DON'T WANNA DO:
- USRLOC Module with db_mode != 2 (Write-Back scheme).
3.- BACKGROUND:
- RFC3265
- RFC3680
- RFC3903
- I attach a small architecture graph.
4.- PROBLEMS:
4.1 Deadlock:
Each REGISTER involves a NOTIFY to the other side. Each NOTIFY involves another NOTIFY to the other side.
There should be a mechanism to avoid PUBLISH reginfo_handle_notify() function calls but to PUBLISH save() calls on pua_reginfo module.
Any idea would be appreciated (also to workaround our problem).
4.2 PUA_REGINFO module notify.c
Just FYI.
We think It doesn't comply to RFC3680. It should observe "unkown-param" object to aid "Contact" header params such as "Path", "Received", "User_agent" and so on.
We've changed code but for a fast startup we've also avoided "unkown-param" and now we're able to see replicated "Path", "Received ... params on each DB.
Thanks and best regards.
Eduardo Lejarreta.
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
-
Daniel-Constantin Mierla -
lejarreta.e＠sarenet.es