Re: [Kamailio-Users] [Kamailio-Devel] Kamailio 1.4.2 : Weird Retransmission

Daniel-Constantin Mierla a écrit : First try, without ngrep or tcpdump. BYE for CALL-ID=3-18225-127.0.0.1 is retransmitted. I'll send the sipp messages but timestamps it provides seems wrong on messages sent. Aurelien > Thanks, > Daniel > > On 12/11/08 18:22, Aurelien Grimaud wrote: >> Well, it seems hard to reproduce with ngrep running .. >> It seems like the timing is not the same anymore and ngrep slow down >> the computer just enough for bug not to trigger. >> I tried many times and the result is that when ngrep is not running, >> the bug shows up, while wth ngrep it stay hidden. >> I hope last log from sipp were enough. >> >> However, this retransmission should not disturb the remote user and >> while nasty race should be handled, this is minor for me. >> My real problem, concerns transaction module too and is more troubling. >> This is the one I related in >> http://lists.kamailio.org/pipermail/users/2008-December/020882.html >> >> I use this timer triggering to fail over another end user and >> implement serial forking. >> If the timer triggers while it should not, I will initiate a second >> call to another destination, which is wrong. >> >> Any idea on this one ? >> >> This is while trying to reproduce it that I found those weird >> retransmission. >> I'll try and trigger this initial bug again. >> >> Regards >> >> Aurelien >> >> Aurelien Grimaud a écrit : >>> Sure, meanwhile here are messages provided by sipp >>> UAS side and UAC side. >>> UAC contains only the 10 calls done >>> UAS contains much more as I was trying to reproduce it with 1 call >>> at a time. >>> >>> Aurelien >>> >>> Daniel-Constantin Mierla a écrit : >>>> Can you please make the test again and send along with the debug >>>> messages the sip trace? >>>> >>>> ngrep -d any -qt -W byline port 5060 >>>> >>>> I want to check the sip messages as well. >>>> >>>> Thank you, >>>> Daniel >>>> >>>> >>>> On 12/11/08 16:19, Aurelien Grimaud wrote: >>>>> Answer waiting for approval : logs too big ! >>>>> >>>>> Here is a lighter one. >>>>> >>>>> My answer was >>>>>> Thanks for the patch. >>>>>> >>>>>> With 1 call at a time, the bug does not trigger anymore. >>>>>> However, with 2 calls at a time it was triggered again on BYE. >>>>>> Attached log is result of my testing. >>>>>> 1 sipp as uac make 10 calls with 2 simultaneous calls allowed. >>>>>> >>>>>> The call callid=7-22285-127.0.0.1 request resending of BYE >>>>>> message at 14:21:07.563004, though we have a 200 ok on BYE at >>>>>> 14:21:07.156865 (pid=21493) >>>>>> Bye request (pid=21495) was not finished to be treated at the >>>>>> time 200 ok was received. >>>>>> >>>>>> This was done with my module active. >>>>>> I'll make new tests without it. >>>>>> >>>>>> Regards, >>>>>> Aurelien >>>>> >>>>> Daniel-Constantin Mierla a écrit : >>>>>> ... disregard the previous patch, please use this one. It was >>>>>> not the latest. Thanks, >>>>>> >>>>>> Daniel >>>>>> >>>>>> >>>>>> On 12/10/08 23:52, Daniel-Constantin Mierla wrote: >>>>>>> Hello, >>>>>>> >>>>>>> On 12/09/08 20:41, Aurelien Grimaud wrote: >>>>>>>> Daniel-Constantin Mierla a écrit : >>>>>>>> >>>>>>>>> On 12/09/08 18:52, Aurelien Grimaud wrote: >>>>>>>>> >>>>>>>>>> I am able to reproduce it with 1 call / second without my >>>>>>>>>> module on BYE requests. >>>>>>>>>> here are traces. >>>>>>>>>> >>>>>>>>> there is a race (at least), indeed. It happens when there is >>>>>>>>> fast reply. I am going to send you a patch soon for testing, >>>>>>>>> you use svn branch 1.4 or the tarball? >>>>>>>>> >>>>>>>> Great, I use the kamailio-1.4.2-notls tarball. >>>>>>>> But I can test any SVN branch / trunk if you wish. >>>>>>>> >>>>>>> can you test the attached patch with SVN trunk? Let me know the >>>>>>> results. Pay attention to see if breaks something else, not >>>>>>> just if fixes the reported issue. I let there some debug >>>>>>> messages, to help troubleshooting, if the fix is ok, I'll >>>>>>> remove them before committing. >>>>>>> >>>>>>> Thanks, >>>>>>> Daniel >>>>>>> >>>>>>>> Aurelien >>>>>>>> >>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Daniel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> ps: I added the ms on Logs. >>>>>>>>>> >>>>>>>>>> Aurelien >>>>>>>>>> >>>>>>>>>> Daniel-Constantin Mierla a écrit : >>>>>>>>>> >>>>>>>>>>> On 12/09/08 17:56, Klaus Darilion wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Daniel-Constantin Mierla schrieb: >>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> On 12/09/08 17:31, Klaus Darilion wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Aurelien Grimaud schrieb: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fair enough. >>>>>>>>>>>>>>> If no one already experienced this strange behavior, it >>>>>>>>>>>>>>> should be my module ... >>>>>>>>>>>>>>> I'll try to make it again without my module. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> See my other email. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, in the log, after the 200 response, there is a >>>>>>>>>>>>>>> cleanup_uac_timers: RETR/FR timers reset. >>>>>>>>>>>>>>> So those timers are cleared. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> But the problem is, that the process which handles the >>>>>>>>>>>>>> INVITE has not finished yet and those (re)SETS the timer. >>>>>>>>>>>>>> >>>>>>>>>>>>>> @Daniel - Have you investigated the problem? >>>>>>>>>>>>>> >>>>>>>>>>>>> so this is the half of the issue reported via: >>>>>>>>>>>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2105813&g… >>>>>>>>>>>>> >>>>>>>>>>>> yes. >>>>>>>>>>>> >>>>>>>>>>>> Can it be related to other modules which register >>>>>>>>>>>> callbacks (e.g. pua module or Aurelien's module? >>>>>>>>>>>> >>>>>>>>>>> what is the requests/second rate when the issue appears? >>>>>>>>>>> >>>>>>>>>>> At first look, between sending and setting retransmission >>>>>>>>>>> timer, there is no much processing for the request. The >>>>>>>>>>> callback executed there is in use by siptrace, are you >>>>>>>>>>> using this module? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Daniel >>>>>>>>>>> >>>>>>>>>>>>> This one got lost, but as I started to fix the other half >>>>>>>>>>>>> (replying using proper mode to do retransmission), will >>>>>>>>>>>>> investigate this as well ... >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Daniel >>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users(a)lists.kamailio.org >>>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>>>>>>> >>>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> Users(a)lists.kamailio.org >>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel(a)lists.kamailio.org >>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel >>> >>