I know I'm revisiting a problem that has been discussed in multiple threads from various angles, so I might be rightly accused of laziness in neglecting to research them all. All the same:
I have proxy1 and proxy2 writing to database A and database B, respectively. Database A and database B are active-active masters, synchronised via some replication system attached to the underlying DB technology.
The 'location' table is also replicated this way. We know that 'usrloc' doesn't work so well with this: one instance of Kamailio will periodically delete the other's contacts, even if they have a nonlocal SIP domain.
Is there any db_mode that can be used (other than 0/purely in-memory) to make this work right? Or is that the essential problem that p_usrloc is written to solve?
Thanks,
-- Alex
Hi,
The timer to delete records only runs if the timer_interval modparam is > 0.
This means you can have multiple active registrars off the same database table and use some external process to manage deletion of records (for example, a stored procedure triggered from a cron job).
Regards,
Peter
On 08/04/13 09:52, Alex Balashov wrote:
I know I'm revisiting a problem that has been discussed in multiple threads from various angles, so I might be rightly accused of laziness in neglecting to research them all. All the same:
I have proxy1 and proxy2 writing to database A and database B, respectively. Database A and database B are active-active masters, synchronised via some replication system attached to the underlying DB technology.
The 'location' table is also replicated this way. We know that 'usrloc' doesn't work so well with this: one instance of Kamailio will periodically delete the other's contacts, even if they have a nonlocal SIP domain.
Is there any db_mode that can be used (other than 0/purely in-memory) to make this work right? Or is that the essential problem that p_usrloc is written to solve?
Thanks,
-- Alex
On 04/08/2013 04:58 AM, Peter Dunkley wrote:
This means you can have multiple active registrars off the same database table and use some external process to manage deletion of records (for example, a stored procedure triggered from a cron job).
Ah, so! I hadn't thought of that. Good suggestion, thank you.
DELETE FROM location WHERE expires >= NOW();
Simple enough.
Cheers
On 04/08/2013 04:58 AM, Peter Dunkley wrote:
Hi,
The timer to delete records only runs if the timer_interval modparam is
This means you can have multiple active registrars off the same database table and use some external process to manage deletion of records (for example, a stored procedure triggered from a cron job).
Peter,
One question that arises with this solution is: what is the full effect of disabling timer? Is it limited merely to turning off automatic deletion of expired contacts? Or are there other 'synchronisation' tasks that also don't happen as a result? I have trouble imagining what those would be in db_mode 3, but still I wonder.
Cheers,
-- Alex
As far as I can tell (when db_mode=3) the timer function calls synchronize_all_udomains(), which calls get_act_time() and then db_timer_udomain() in a loop, and db_timer_udomain() just does a database delete.
Regards,
Peter
On 08/04/13 10:27, Alex Balashov wrote:
On 04/08/2013 04:58 AM, Peter Dunkley wrote:
Hi,
The timer to delete records only runs if the timer_interval modparam is
This means you can have multiple active registrars off the same database table and use some external process to manage deletion of records (for example, a stored procedure triggered from a cron job).
Peter,
One question that arises with this solution is: what is the full effect of disabling timer? Is it limited merely to turning off automatic deletion of expired contacts? Or are there other 'synchronisation' tasks that also don't happen as a result? I have trouble imagining what those would be in db_mode 3, but still I wonder.
Cheers,
-- Alex
Alex Balashov writes:
The 'location' table is also replicated this way. We know that 'usrloc' doesn't work so well with this: one instance of Kamailio will periodically delete the other's contacts, even if they have a nonlocal SIP domain.
Is there any db_mode that can be used (other than 0/purely in-memory) to make this work right? Or is that the essential problem that p_usrloc is written to solve?
have you tried with db_mode=3? i have not noticed problems with it, but my case be different from yours.
-- juha
On 04/08/2013 05:01 AM, Juha Heinanen wrote:
have you tried with db_mode=3? i have not noticed problems with it, but my case be different from yours.
I have, and unfortunately there are still these problems.
The problem is that endpoints register to both registrars simultaneously in this setup. There is no question that one Kamailio instance periodically deletes the other's contacts. This has been observed.
-- Alex
Alex Balashov writes:
The problem is that endpoints register to both registrars simultaneously in this setup. There is no question that one Kamailio instance periodically deletes the other's contacts. This has been observed.
in db_mode=3, what does it matter that a proxy deletes other proxy's contacts because that have expired anyway?
-- juha
On 04/08/2013 05:21 AM, Juha Heinanen wrote:
Alex Balashov writes:
The problem is that endpoints register to both registrars simultaneously in this setup. There is no question that one Kamailio instance periodically deletes the other's contacts. This has been observed.
in db_mode=3, what does it matter that a proxy deletes other proxy's contacts because that have expired anyway?
In practice, we have found that they seem to get deleted a little before expiration, and so there is a gap between their being deleted and re-registration on the part of the UAC.
This is attributable to different Kamailio start times + clock synchronisation + diverse UAC reregistration timer interval, I'm guessing.
-- Alex
Alex Balashov writes:
In practice, we have found that they seem to get deleted a little before expiration, and so there is a gap between their being deleted and re-registration on the part of the UAC.
it is a bug if records are deleted before they expire. there should be a safe margin after the actual expiration.
-- juha
On 04/08/2013 05:30 AM, Juha Heinanen wrote:
Alex Balashov writes:
In practice, we have found that they seem to get deleted a little before expiration, and so there is a gap between their being deleted and re-registration on the part of the UAC.
it is a bug if records are deleted before they expire. there should be a safe margin after the actual expiration.
To be honest, we never looked at it that deeply. It was a service-affecting issue and we moved to a different approach.
On 04/08/2013 05:30 AM, Juha Heinanen wrote:
Alex Balashov writes:
In practice, we have found that they seem to get deleted a little before expiration, and so there is a gap between their being deleted and re-registration on the part of the UAC.
it is a bug if records are deleted before they expire. there should be a safe margin after the actual expiration.
Is it possible that the sync timer actually deletes all records from the location table that it did not itself put there? That would explain what we saw.
I'm running kamailio 3.X with the following patch for years, works fine to me with distributed servers and replication:
diff --git a/modules_k/usrloc/udomain.c b/modules_k/usrloc/udomain.c index b52bb76..e457cc5 100644 --- a/modules_k/usrloc/udomain.c +++ b/modules_k/usrloc/udomain.c @@ -318,6 +318,7 @@ static inline ucontact_info_t* dbrow2info( db_val_t *vals, str *contact) ci.sock = grep_sock_info( &host, (unsigned short)port, proto); if (ci.sock==0) { LM_WARN("non-local socket <%s>...ignoring\n", p); + return 0; } }
On Monday 08 April 2013 04:52:35 Alex Balashov wrote:
I know I'm revisiting a problem that has been discussed in multiple threads from various angles, so I might be rightly accused of laziness in neglecting to research them all. All the same:
I have proxy1 and proxy2 writing to database A and database B, respectively. Database A and database B are active-active masters, synchronised via some replication system attached to the underlying DB technology.
The 'location' table is also replicated this way. We know that 'usrloc' doesn't work so well with this: one instance of Kamailio will periodically delete the other's contacts, even if they have a nonlocal SIP domain.
Is there any db_mode that can be used (other than 0/purely in-memory) to make this work right? Or is that the essential problem that p_usrloc is written to solve?
Thanks,
-- Alex
-
Alex Balashov -
Juha Heinanen -
Peter Dunkley -
Sergey Okhapkin