[Kamailio-Users] [Bulk] Re: [Kamailio-Devel] drop() and tm timers.

[Aurelien Grimaud]

Daniel-Constantin Mierla a écrit :
>
>
> On 12/28/08 23:56, Aurelien Grimaud wrote:
>> Daniel-Constantin Mierla a écrit :
>>  
>>> On 12/20/08 14:09, Aurelien Grimaud wrote:
>>>    
>>>> Daniel-Constantin Mierla a écrit :
>>>>      
>>>>> On 12/19/08 10:10, Aurelien Grimaud wrote:
>>>>>        
>>>>>> Klaus Darilion a écrit :
>>>>>>  
>>>>>>          
>>>>>>> Strange!
>>>>>>>
>>>>>>> Nevertheless there is no need to drop 100 as 100 is never relayed.
>>>>>>>                 
>>>>>> Yep, my mistake !
>>>>>>
>>>>>> The first destination chosen for serial forking was sending a 101 
>>>>>> with sdp, which was relayed to caller.
>>>>>>             
>>>>> 101 - I haven't heard of such reply so far ... what is the reason 
>>>>> phrase?
>>>>>         
>>>> Well, this is a home made reply from a pstn gateway.
>>>> The pstn gateway sens request to a pstn network equipement.
>>>> As soon as the pstn equipements answers a Progress, a 101 is 
>>>> relayed to openser.
>>>>       
>>> ok, i understand.
>>>    
>>>> It contains really early sdp.
>>>> I thought it smart.
>>>> I am not so sure now !
>>>>       
>>> If you want to get to tm but not relayed upstream, you should drop 
>>> it in an onreply_route armed via tm (t_on_reply(...) call), not the 
>>> default onreply_route.
>>>
>>>     
>> Well, actually I dropped the message in an onreply_route armed via tm 
>> and timer were not canceled.
>> Correct me if I'm wrong, but I think that the timer processing is 
>> *after* the reply_route execution.
>>   
> retransmission timers are reset before executing the tm onreply route.
>
Yes sure, retransmission timers are reset before executing the tm 
onreply route.

Ok too : fr_timer is disabled on final reply.
 >    /* stop final response timer only if I got a final response */
 >    if ( msg_status >= 200 ) {
 >        reset_timer( &uac->request.fr_timer);
 >    }

But, fr_timer is switched to fr_inv_timer after executing onreply_route.
So, If all provisional are dropped, the fr_timer is not changed to 
fr_inv_timer.

Should not fr_timer be changed to fr_inv_timer even if message is dropped ?

I mean, my fr_timer is 10 seconds. fr_inv_timer is 120 seconds.
I expect it to work this way :

relay INVITE to destination A.
A does not answer anything : fr_timer is triggered (A is probably down, 
or unreachable)
failure route : serial forking to destination B

or

relay INVITE to destination A
A answers 180, fr_timer is switched to fr_inv_timer (A is processing the 
call)
No final reply for fr_inv_timer seconds (A does not answer anymore : 
network problem, host down)
failure_route : serial forking to destination B

If 180 is dropped, then the behavior is as follow

relay INVITE to destination A
A answers 180 which is dropped.
after 10 seconds (fr_timer) : failure route because of fr_timer.
This is a wrong failure report. A is processing the call, serial forking 
should not occur.


Documentation says :
 > Timer which hits if no final reply for an INVITE arrives after a 
provisional message was received (in seconds). *This timer is started 
after the first provisional response.* Thus, fast failover (no 100 
trying from gateway) can be achieved by setting fr_timer to low values.

No warning on dropped messages.

> You talk about this with one of the patches I sent or before that?
The problem occurred with openser 1.2.1, but the svn source code has the 
same issue imho.

Regards.
Aurelien
>
> Cheers,
> Daniel
>