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: _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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: _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Can you try the latest version of branch 4.2? I pushed a fix that should solve this one as well. Let me know the results. Cheers, Daniel On 23/01/15 13:40, Jan Hazenberg wrote: