one question for you, is your system multi-processor? Cheers, Daniel
On 12/12/08 10:30, Aurelien Grimaud wrote: > Daniel-Constantin Mierla a écrit : >> can you try this new patch? It adds a new debug messages for >> troubleshooting -- you have to revert the previous patch as this one >> includes it. you can send it to me without ngrep, maybe i can catch it. > 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&group_id=139143&atid=743020 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> 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@lists.kamailio.org >>>>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list >>>>>>>> Users@lists.kamailio.org >>>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>> >>>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Devel mailing list >>>> de...@lists.kamailio.org >>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel >>>> >>> >>> >> > -- Daniel-Constantin Mierla http://www.asipto.com _______________________________________________ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
