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

On 2/14/12 10:17 AM, Øyvind Kolbu wrote:

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);
     }

can you create the transaction with t_newtran() somewhere before calling dlg manage? It should absorb retransmissions before going into dialog processing. After creating the transaction, use either send_reply() or t_reply() instead of sl_send_reply().

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?

what version are you using? REGISTER requests should not create any dialog and that is fixed starting wit 3.2.1, iirc.

Cheers, Daniel