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

harneet singh hbilling at gmail.com
Wed Dec 16 17:57:36 CET 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201216/734bd44c/attachment.htm>


More information about the sr-users mailing list