[SR-Users] Dialogs not removed from memory, and occasionally persistent in DB as well

Øyvind Kolbu oyvind.kolbu at usit.uio.no
Tue Feb 14 10:17:17 CET 2012


On 2012-01-31 at 14:15, Øyvind Kolbu wrote:
> On 2012-01-31 at 14:06, Timo Reimann wrote:
> > I'm currently in the process of investigating a dialog-related issue
> > together with Uri (see CC). It may be related to your problem, so let's
> > see if I can find something out that helps you as well. If not, I/we
> > should take a dedicated look at your case.
> > 
> > Unfortunately, I'm currently short on time so I cannot give any
> > guarantees as to when I'll find the time to get to these dialog-related
> > things. I promise to get back to you folks ASAP though, so please hang
> > on.
> 
> Great! We are currently running with full debugging enabled, so don't
> hesitate to contact if you need some data.

Hi, 

we've found that perhaps the cause of our problems are multiple identical
INVITEs at more or less the exact same time, +/- a few ms. This causes a race
within either the tm or dialog module, as it doesn't seem to cope well with
duplicates ~simultanously. Our fix is that we use the lock and unlock
commands from the cfgutils module together with a hashtable to check
for duplicates, and if so, drop them.

So our patch is more or less:

modparam("htable", "htable", "cidhist=>size=8;autoexpire=10");
modparam("cfgutils", "lock_set_size", 8)


$avp(s:f_uid) is the username for our authenticated user and is set in
route(AUTH), then in main route, after route(AUTH):


       if (is_method("INVITE")) {
                if($(rU{s.len}) == 0)
                {
                        xlog("L_INFO", "$avp(s:f_uid) tried to call an empty number, dropping call\n");
                        sl_send_reply("404", "User Not Found");
                        exit;
                }
                lock($ci);
                if($sht(cidhist=>$ci) != $null)
                {
                        xlog("L_INFO", "DLG: We've already seen this call-id before, we should drop this invite $ci\n");
                        unlock($ci);
                        exit;
                } else
                {
                        xlog("L_INFO", "DLG: This is a new invite, let's start a dialog! $ci\n");
                        $sht(cidhist=>$ci) = 1;
                        setflag(3);
                        dlg_manage();

                        if ($avp(s:f_uid) != $null) {
                            set_dlg_profile("busy","$avp(s:f_uid)");
                            get_profile_size("busy", "$avp(s:f_uid)", "$var(dlg_busy)");
                            xlog("L_INFO", "BUSY: f_uid: $avp(s:f_uid), dlg_busy: $var(dlg_busy)\n");
                        }
                }
                unlock($ci);
        }

Worth mentioning is that we also get REGISTER messages stuck in the
dialog-module, in state 1, but we only do setflag(3) and dlg_manage() for
INVITE. Againt probably caused by identical REGISTER messages. Any idea of
why?

-- 
Øyvind Kolbu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120214/8f44fdaa/attachment.pgp>


More information about the sr-users mailing list