[SR-Users] Dialog module generates error since upgrade to 4.2.2

Jan Hazenberg jenus at cyberchaos.nl
Fri Jan 23 13:40:17 CET 2015


Daniel,

Let me know if you need some debugs from my side. I have 4.2.2 and 4.2.1 
running and can reproduce the problem if needed.

Jan

Daniel-Constantin Mierla schreef op 2015-01-23 13:38:
> I hope to get the time to look into it either this evening or over the
> weekend. I have some other logs sent to me for a dialog issue.
> 
> Daniel
> 
> On 23/01/15 12:40, Jan Hazenberg wrote:
>> I indeed see the same spiral messages in the logs as well:
>> 
>> Jan 22 14:50:33 sip /usr/sbin/kamailio[14084]: DEBUG: dialog
>> [dlg_handlers.c:831]: dlg_new_dialog(): Callid
>> '035a329653a80be399f7b45e6c734415 at 192.168.149.126' found, must be a
>> spiraled request
>> 
>> Jan
>> 
>> 
>> Klaus Darilion schreef op 2015-01-23 11:38:
>>> I think the problem with 4.2.2. is the following:
>>> 
>>> After dialog cleanup code is not executed after script exit. Thus, if
>>> the dialog is created without generating a transaction, e.g.:
>>>    ...
>>>    dialog_manage();
>>>    ... some checks
>>>    sl_send_reply();
>>>    exit;
>>> 
>>> the dialog is created, but not destroyed after exit. Thus, next time 
>>> a
>>> request with identical dialog IDs (e.g the second INVITE after
>>> authentication) is received, Kamailio finds the un-destroyed dialog 
>>> and
>>> falsely think this message belongs to a spiraled request and thus 
>>> does
>>> not register the tm_callbacks for the responses. Thus, the dialog 
>>> stays
>>> in state 1 forever.
>>> 
>>> Probably there are 2 bugs:
>>> 
>>> 1. The dialog callbacks are not executed on script exit (this works 
>>> fine
>>> in Kamailio 4.1.7)
>>> 
>>> 2. The spiral detection code is buggy. Just because a dialog exists 
>>> is
>>> not a proof for a spiral. In fact, a request with only 1 Via header 
>>> can
>>> never be a spiraled request.
>>> 
>>> regards
>>> Klaus
>>> 
>>> 
>>> 
>>> On 22.01.2015 21:02, Jan Hazenberg wrote:
>>>> Klaus,
>>>> 
>>>> Yes, that solves the problem here as well.
>>>> 
>>>> Thanks,
>>>> 
>>>> Jan
>>>> 
>>>> Klaus Darilion schreef op 2015-01-22 16:16:
>>>>> Hi Jan!
>>>>> 
>>>>> I replaced dlg_manage with setflag(dialog flag). This way the
>>>>> dialog is
>>>>> created only when a transaction is created. It solved my problems.
>>>>> 
>>>>> regards
>>>>> Klaus
>>>>> 
>>>>> 
>>>>> 
>>>>> On 22.01.2015 14:47, Klaus Darilion wrote:
>>>>>> Nice, I have the same problem after upgrading from 4.1.7 to 4.2.2.
>>>>>> ....
>>>>>> ..... in my case it seems the dialog callbacks are not executed 
>>>>>> for
>>>>>> responses ... I am still debugging .....
>>>>>> 
>>>>>> On 22.01.2015 13:25, Jan Hazenberg wrote:
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> I'm running into a issue with the dialog module since the upgrade
>>>>>>> from
>>>>>>> 4.2.1 to 4.2.2. I use the dialog module to add extra vars to the
>>>>>>> cdr's
>>>>>>> generated by the ACC module.
>>>>>>> 
>>>>>>> I use the following config:
>>>>>>> 
>>>>>>> # ----- dialog params -----
>>>>>>> modparam("dialog", "enable_stats", 1)
>>>>>>> modparam("dialog", "dlg_match_mode", 1)
>>>>>>> modparam("dialog", "dlg_flag", FLT_DLG)
>>>>>>> modparam("dialog", "rr_param", "did")
>>>>>>> modparam("dialog", "wait_ack", 1)
>>>>>>> 
>>>>>>> # Create dialog
>>>>>>> if (method=="INVITE") {
>>>>>>>      # Create Dialog
>>>>>>>      dlg_manage();
>>>>>>> 
>>>>>>>      # Add test dialog var
>>>>>>>      $dlg_var(src_ua) = $hdr(User-Agent);
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> This seems to work fine on kamailio 4.2.1 but after the upgrade i
>>>>>>> see
>>>>>>> the following errors in the logs:
>>>>>>> 
>>>>>>> Jan 22 13:16:57 sip /usr/sbin/kamailio[2773]: CRITICAL: dialog
>>>>>>> [dlg_hash.c:901]: log_next_state_dlg(): bogus event 6 in state 1 
>>>>>>> for
>>>>>>> dlg
>>>>>>> 0x7f2f0332ed40 [3693:11222] with clid
>>>>>>> '9192c5fc24627a14c2ec42f084a96587 at 192.168.149.126' and tags
>>>>>>> '4017642921' ''
>>>>>>> Jan 22 13:17:01 sip /usr/sbin/kamailio[2770]: CRITICAL: dialog
>>>>>>> [dlg_hash.c:901]: log_next_state_dlg(): bogus event 7 in state 1 
>>>>>>> for
>>>>>>> dlg
>>>>>>> 0x7f2f0332ed40 [3693:11222] with clid
>>>>>>> '9192c5fc24627a14c2ec42f084a96587 at 192.168.149.126' and tags
>>>>>>> '4017642921' ''
>>>>>>> 
>>>>>>> If i'm correct "bogus event 6 in state 1" indicates that a ACK 
>>>>>>> whas
>>>>>>> received while the dialog still was in unconfirmed state. Should 
>>>>>>> i
>>>>>>> catch
>>>>>>> the 200 OK on the INVITE to update the dialog?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Jan Hazenberg
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>>>>>>> mailing list
>>>>>>> sr-users at lists.sip-router.org
>>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>> 
>>>>>> _______________________________________________
>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>>>> list
>>>>>> sr-users at lists.sip-router.org
>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>>> list
>>>>> sr-users at lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>> 
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
>>>> list
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>> 
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
>>> list
>>> sr-users at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>> 
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing 
>> list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



More information about the sr-users mailing list