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&gr... 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@lists.kamailio.org mailto:Users@lists.kamailio.org >>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>> >>> >>>>> >>
>> >> >> _______________________________________________ >> Users mailing list >> Users@lists.kamailio.org mailto:Users@lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >
Devel mailing list Devel@lists.kamailio.org mailto:Devel@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
Users mailing list Users@lists.kamailio.org mailto:Users@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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users