Daniel-Constantin Mierla a écrit :
> can you try this new patch? It adds a new debug messages for
> troubleshooting -- you have to revert the previous patch as this
> one includes it. you can send it to me without ngrep, maybe i can
> catch it.
>
First try, without ngrep or tcpdump.
BYE for CALL-ID=3-18225-127.0.0.1 is retransmitted.
I'll send the sipp messages but timestamps it provides seems wrong
on messages sent.
Aurelien
> Thanks,
> Daniel
>
> On 12/11/08 18:22, 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&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
>>>>>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)lists.kamailio.org
>>>
http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
>>>
>>