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

[Daniel-Constantin Mierla]

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?

> 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
>
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com