12 Dec
2008
12 Dec
'08
3:53 a.m.
Klaus Darilion a écrit :
Jerome Martin wrote:
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
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 :
*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*(a)longphone.fr
Web : www.longphone.com <http://www.longphone.com>
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users 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&g…
<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(a)lists.kamailio.org <mailto:Users@lists.kamailio.org>
>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>> >>>>>
>>>>
------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users(a)lists.kamailio.org <mailto:Users@lists.kamailio.org>
>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>
>>
>
------------------------------------------------------------------------
_______________________________________________
Devel mailing list
Devel(a)lists.kamailio.org <mailto:Devel@lists.kamailio.org>
http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org <mailto:Users@lists.kamailio.org>
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users