11 Dec
2008
11 Dec
'08
6:22 p.m.
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:
------------------------------------------------------------------------
_______________________________________________
Devel mailing list
Devel(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
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…
>>>>>>>
>>>>>> 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
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> Users mailing list
> Users(a)lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users