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

Jerome Martin jmartin at longphone.fr
Thu Dec 11 17:55:14 CET 2008


Well, then your only onption might be to get a hub and connect an other
machine to it running tcpdump/ngrep instead of running it locally. Also,
look at your switches, maybe they have port mirriring ?

On Thu, 2008-12-11 at 17:22 +0100, 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 at lists.kamailio.org
> >>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> >>>>>>
> >>>>>>   
> >>>>>
> >>>>> ------------------------------------------------------------------------ 
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Users mailing list
> >>>>> Users at lists.kamailio.org
> >>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> >>>>
> >>>
> >>
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at lists.kamailio.org
> > http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
> >   
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users


Jérôme Martin | LongPhone
Responsable Architecture Réseau
122, rue la Boetie | 75008 Paris 
Tel :  +33 (0)1 56 26 28 44
Fax : +33 (0)1 56 26 28 45
Mail : jmartin at longphone.fr
Web : www.longphone.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/users/attachments/20081211/f398fa5d/attachment.htm 


More information about the Users mailing list