[sr-dev] Dialog onroute requests.

[Eduardo Lejarreta]

Good evening Øyvind.

Nice workaround. We'll implement until dialog modules are improved.

Need help to kamctl ("hot") restart? Depending on which modules you develop
I could give you some ideas.

Thank you very much and best regards.
-- 
Eduardo Lejarreta.


-----Mensaje original-----
De: sr-dev-bounces at lists.sip-router.org
[mailto:sr-dev-bounces at lists.sip-router.org] En nombre de Øyvind Kolbu
Enviado el: miércoles, 19 de junio de 2013 13:15
Para: sr-dev at lists.sip-router.org
Asunto: Re: [sr-dev] Dialog onroute requests.

On 04.06.2013 15:39, Daniel-Constantin Mierla wrote:
> Hello,
>
> On 6/4/13 3:14 PM, Eduardo Lejarreta wrote:
>>
>> Good evening.
>>
>> Playing with latest “dialog module” versions (3.2, 3.3 and 4.0) I 
>> think there could be an open “issue” with regard to dialog state 
>> management.
>>
>> You can see on “dlg_handlers.c” on “dlg_onroute” function. On this 
>> last  when you receive a BYE message it fires some CallBacks.
>>
>> I you receive a close second BYE, this last one destroys the dialog 
>> because “dlg_release” function is called from a parallel process 
>> avoiding the other processes callback execution.
>>
>> I know a second BYE it’s not a normal circumstance but you know, the 
>> real world 

>>
>> I think dialog_ng doesn’t have this issue but also it has no DB support.
>>
> can you give more specific details, like the lines of code you think 
> may have an open issue? A quick check, it seems dialog and dialog_ng 
> have the same processing of BYE request in dlg_onroute() and unref is 
> done only on transition state to terminate.

We have since upgrading from Kamailio 1.5 to 3.2 had problems with the
dialog module, where dialogs have been "stuck" in state 5 and we must
restart Kamailio to remove them. Needless to say a bad thing...

So far we have mitigated it mostly with dropping duplicated INVITEs and with
the help of this mail, also dropping duplicated BYEs. Seems like the
duplicate-handling in the module is not handled well if they are received
within a too short interval.

We use:
modparam("htable", "htable", "invcidhist=>size=8;autoexpire=30");
modparam("htable", "htable", "byecidhist=>size=8;autoexpire=30");

and before route(WITHINDLG):

         if (is_method("BYE")) {
                 lock($ci);
                 if($sht(byecidhist=>$ci) != $null) {
                         xlog("L_INFO", "BYE: We've already seen this
call-id before, we should drop this bye $ci\n");
                         unlock($ci);
                         exit;
                 } else {
                         xlog("L_INFO", "BYE: This is the first BYE for this
call, let's process it\n");
                         $sht(byecidhist=>$ci) = 1;
                 }
                 unlock($ci);
         }

Later after route(AUTH) we do it similar for INVITE

        if (is_method("INVITE")) {
                 if($sht(invcidhist=>$ci) != $null)
                 {
                         xlog("L_INFO", "INVITE: We've already seen this
call-id before, we should drop this invite $ci\n");
                         unlock($ci);
                         exit;
                 } else
                 {
                     xlog("L_INFO", "INVITE: This is a new invite, let's
start a dialog! $ci\n");
                     $sht(invcidhist=>$ci) = 1;
                 }
                 unlock($ci);
         }

Our Kamailios are running 3.3.3 (i386/linux) 897939-dirty.

--
Øyvind

_______________________________________________
sr-dev mailing list
sr-dev at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev