On 27 Jul 2016, at 14:01, Jonathan Hunter
<hunterj91(a)hotmail.com> wrote:
Hi Guys,
So currently on our network we have a kamailio server which users register against, we
then replicate the register messages to 2 Asterisk boxes sat behind it so that all
entities are aware of the registration state of the users.
REGISTER--->KAMAILIO---->ASTERISK A
---->ASTERISK B
With a REGISTER---200OK exchange between Kamailio and Asterisk.
We have an issue where at some points the Asterisk servers when under load dont respond
with a 200 ok(something being investigated) to the register messages sent to kamailio, so
I am just working on some logic for the register message to be resent using the
t_replicate and t_set_fr functions.
This works well should both Asterisk servers not respond, however, as I am using
replicate and it is parallel forking, if say Asterisk A answers first and is available
with a 200ok then that in turn cancels the register message branch being sent to Asterisk
B(which I know is fine), however there could be a scenario where Asterisk B doesnt
respond, and we wont know about it to try and resend the Register message, as the branch
is cancelled.
Hope that makes sense?
I am looking at checking that both the Asterisk servers have responded and sent a 200ok,
which I can grab in an onreply route but Im just wondering if someone has done something
similar or has any suggestions as it is tricky to achieve currently.
I have also thought about stateless working but I really need kamailio to keep
retransmitting the register until it gets a response.
Many thanks
In my view you are making a very complex solution. Why do you need to store the same
registration in so many places? That’s
indicating a problem in the architecture.
/O