[Kamailio-Users] [Bulk] Re: [Kamailio-Devel] 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 Users
mailing list