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

[Daniel-Constantin Mierla]

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

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda