8 Apr
2013
8 Apr
'13
8:52 a.m.
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 - 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/
8 Apr
8 Apr
8:58 a.m.
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
9:09 a.m.
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
--
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/
9:27 a.m.
On 04/08/2013 04:58 AM, Peter Dunkley wrote:
Hi,
The timer to delete records only runs if the timer_interval modparam is
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 - 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/
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).
10:32 a.m.
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
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
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). 
9:01 a.m.
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
9:11 a.m.
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 - 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/
9:21 a.m.
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
9:26 a.m.
On 04/08/2013 05:21 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.
This is attributable to different Kamailio start times + clock
synchronisation + diverse UAC reregistration timer interval, I'm guessing.
-- 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/
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?
9:30 a.m.
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
9:31 a.m.
On 04/08/2013 05:30 AM, Juha Heinanen wrote:
Alex Balashov writes:
To be honest, we never looked at it that deeply. It was a
service-affecting issue and we moved to a different approach.
--
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/
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.
9:32 a.m.
On 04/08/2013 05:30 AM, Juha Heinanen wrote:
Alex Balashov writes:
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.
--
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/
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. 
10:51 a.m.
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
4055
days inactive
4055
days old
12 comments
4 participants
participants (4)
-
Alex Balashov -
Juha Heinanen -
Peter Dunkley -
Sergey Okhapkin