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

[Aurelien Grimaud]

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.

Regards,
Aurelien
> Cheers,
> Daniel
>
>>
>> Aurelien
>>>
>>>> But this first destinaion failed to establish the call, so the 
>>>> request was serial forked to another destination, sending another 
>>>> 101 sdp, then 180 sdp and 200 sdp which are relayed to caller.
>>>> The problem is that caller did not take into account the next sdp 
>>>> but stay stucked to initial one (the one that failed).
>>>>
>>>> When tm timer triggers, there is a CANCEL which is sent to initial 
>>>> destination right ?
>>>>   
>>> Yes.
>>>
>>>> Well, maybe 100 does not change timers from fr to fr_inv, and  I 
>>>> did not notice before as  180 was coming very fast ?
>>>> I checked the source, but the test  in t_reply before updating the 
>>>> timer is not obvoious to see wether timer are canceled on 100 or 
>>>> 180 :-)
>>>> One thing is sure. If you drop the reply, timer will not be changed.
>>>>   
>>> If you dropped it in default onreply route then tm does not get it.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>> The destination was a mobile device on PSTN.
>>>> 180 may be really delayed, and I am not even sure they are mandatory !
>>>>
>>>> Aurelien
>>>>  
>>>>> klaus
>>>>>
>>>>> Aurelien Grimaud wrote:
>>>>>  
>>>>>> Daniel-Constantin Mierla a écrit :
>>>>>>    
>>>>>>> Hello,
>>>>>>>
>>>>>>> On 12/18/08 13:18, Aurelien Grimaud wrote:
>>>>>>>      
>>>>>>>> Hi,
>>>>>>>> In my openser, I had to not relay any provisional which is < 180.
>>>>>>>> I used drop in reply route to do this.
>>>>>>>> No provisional < 180 is sent to caller.
>>>>>>>>
>>>>>>>> Unfortunately, dropping 100 seems to make the transaction 
>>>>>>>> module not disarming its fr_timer.
>>>>>>>>             
>>>>>>> 100 is disabling the retransmission timer. fr_timer is the 
>>>>>>> duration to wait until a final response is received, not related 
>>>>>>> to retransmission and 100 reply.
>>>>>>>
>>>>>>>         
>>>>>> - fr_timer is armed when INVITE is t_relayed and disarmed *only* 
>>>>>> when a final response is received.
>>>>>> - fr_inv_timer is armed whenever a provisional (100 - 199) is 
>>>>>> received, disarmed on final response .
>>>>>> Well, fr_timer also has to be disarmed when fr_inv_timer is armed 
>>>>>> right ?
>>>>>>
>>>>>> So any provisional (100-199) disarm fr_timer and arm fr_inv_timer.
>>>>>> But you have not to drop it in reply_route.
>>>>>>
>>>>>> In my case, the reply_route I set drops any provisional < 180.
>>>>>> This means that the 100 response will not make tm module switch 
>>>>>> fr_timer to fr_inv_timer as it would be if not dropped.
>>>>>>
>>>>>> Well this is not a problem, I only dropped provisional from 101 
>>>>>> to 180, and all went back to normal.
>>>>>> Since 100 is not forwarded (because of t_relay already generated 
>>>>>> one), this makes no difference for end users.
>>>>>>
>>>>>> I did not expect drop() statement to change anything for timers.
>>>>>>
>>>>>> Thanks.
>>>>>> Aurelien
>>>>>>
>>>>>>    
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>
>>>>>>>      
>>>>>>>> The 180 has been waited for more time than my fr_timer so 
>>>>>>>> request failed and failure_route was called.
>>>>>>>> In fact, there is no 180, only a 200 ok.
>>>>>>>>
>>>>>>>> Can anyone confirm that disarming timer is *not* done if 100 is 
>>>>>>>> dropped ?
>>>>>>>>
>>>>>>>> This is openser 1.2.1
>>>>>>>>
>>>>>>>> Regards.
>>>>>>>> Aurelien
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Devel mailing list
>>>>>>>> Devel at lists.kamailio.org
>>>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
>>>>>>>>
>>>>>>>>             
>>>>>>
>>>>>> _______________________________________________
>>>>>> Devel mailing list
>>>>>> Devel at lists.kamailio.org
>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
>>>>>>       
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.kamailio.org
>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>   
>>>
>>
>>
>