[SR-Users] DLGLOAD stuck in Dispatcher Module(HA Mode)

[Social Boh]

Maybe a option is leave the secondary like primary when primary go up newly.

Example: Primary go down, Secondary is the new Primary. Primary came 
back up but Secondary still is the VIP and still process the calls.

Only if Secondary go down, primary is the new VIP.

The keepalived parameter for this behaviour is:

*nopreempt*

---
I'm SoCIaL, MayBe

El 16/12/2020 a las 11:57 a. m., harneet singh escribió:
> Hi All,
>
> I am using Kamailio in HA mode with Keepalived providing the 
> VIP(Virtual IP) functionality, and have run into a rather peculiar issue.
>
> _Setup:_
>
> Caller ------------ KamailioVIP(*Primary *and *Secondary* 
> Kamailio)------- Callee
>
>     HA provided by Keepalived
>     DMQ is used between the Primary and Secondary Kamailio for dialog sync
>
> */_Issue Seen:_/*
> */_
> _/*
> */_Suppose the Primary Kamailio has been brought down_/* and the 
> Secondary one is actually active and tied to the VIP.
>
> When a call is fired from the Caller, it traverses through the 
> Secondary Kamailio and lands onto the callee. The dialogs are updated 
> properly. At this point, the Primary Kamailio is brought up, and 
> dialog state is synced due to the DMQ module.
> The Keepalived will now attach the VIP to the Primary Instance. If the 
> caller hangs up the phone at this point, the BYE sip message traverses 
> through the Primary Kamailio instance to the callee and the call is 
> cleared, but there are two issues here.
>
>   1.  The Primary Kamailio throws an error in *ds_load_remove() 
> *saying that it cannot find the load for the specific call id. This is 
> apparently due to the fact that the dispatcher data is not synced 
> between the two modules but dialog data is. So dialog wise, things are 
> fine. Can this be fixed somehow?
>
>   2. The above is still as grave a problem as the dialogs are cleared. 
> BUT, if we check the '*kamcmd dispatcher.list*' on the *SECONDARY* 
> kamailio even well after the call is cleared, the *DLGLOAD* shows 1. 
> Since we are using the *Call Load based distribution* for the 
> dispatching, this is effectively one call stuck on the dispatcher, 
> which leads to resource leak.
>
> Is this a known issue, and if so, do we have a way to circumvent this?
>
> Regards,
> Harneet Singh
> -- 
> "Once you eliminate the impossible, whatever remains, no matter how 
> improbable, must be the truth" - Sir Arthur Conan Doyle
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201216/1800538e/attachment.htm>