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

Daniel-Constantin Mierla miconda at gmail.com
Thu Dec 11 22:47:20 CET 2008


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.

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 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
>>   
>
>

-- 
Daniel-Constantin Mierla
http://www.asipto.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tm-rb2.diff
Url: http://lists.kamailio.org/pipermail/users/attachments/20081211/80e29de7/attachment.asc 


More information about the Users mailing list