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

Aurelien Grimaud gstelzz at yahoo.fr
Fri Dec 12 09:53:45 CET 2008


Klaus Darilion a écrit :
> 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
>
I tried it with the same result : no bug.
All the traffic is local in my case.
sipp uac, openser and sipp uas are running on the same host.

I tried with tcpdump -s0 -ilo port 5060, with no better result.

I'll try running sipp on other host, but latency caused by network 
interface will sure make the bug not show up.

Cheers,

Aurelien

> 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