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

Klaus Darilion klaus.mailinglists at pernau.at
Thu Dec 11 20:31:19 CET 2008


Jerome Martin wrote:
> 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 ?

or try
   tcpdump -s 0 -w file.pcap port 5060

As this does not cause any console output maybe it does generate less load.

klaus

> 
> 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 <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 <mailto:Users at lists.kamailio.org>
>> >>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> >>>>>>
>> >>>>>>   
>> >>>>>
>> >>>>> ------------------------------------------------------------------------ 
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Users mailing list
>> >>>>> Users at lists.kamailio.org <mailto:Users at lists.kamailio.org>
>> >>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> >>>>
>> >>>
>> >>
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Devel mailing list
>> > Devel at lists.kamailio.org <mailto:Devel at lists.kamailio.org>
>> > http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
>> >   
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.kamailio.org <mailto: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*@longphone.fr
> Web : www.longphone.com <http://www.longphone.com>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users




More information about the Devel mailing list