> On 27 Jul 2016, at 14:01, Jonathan Hunter <hunter...@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
_______________________________________________ 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
