t_set_fr behaviour

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

t_set_fr behaviour

Kelvin Chua-2
hi guys,

has anyone of you tried playing around with a scenario similar to this?

A. invite -> t_set_fr() 2 secondsĀ  - if "100 trying" not received in 2 seconds, timeout. works fine.
B. after receiving "100 trying" received, t_set_fr() 30 seconds - if 18x not received in 30 seconds, timeout. works fine
C. after receiving the first 180, t_set_fr() 10 seconds - if "200 ok" not received in 10 seconds, it will not timeout, but instead it will timeout 30 seconds after B.

i noticed this behavior recently and noticed that when a previous t_set_fr() is bigger than the new one, it will be ignored. so if i did 2 -> 10 -> 30, it works (swapping timeout values of B and C)

my question is, is this an expected behavior?



Kelvin Chua

_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: t_set_fr behaviour

Daniel-Constantin Mierla-6
Hello,


On 11.11.17 07:04, Kelvin Chua wrote:

> hi guys,
>
> has anyone of you tried playing around with a scenario similar to this?
>
> A. invite -> t_set_fr() 2 secondsĀ  - if "100 trying" not received in 2
> seconds, timeout. works fine.
> B. after receiving "100 trying" received, t_set_fr() 30 seconds - if
> 18x not received in 30 seconds, timeout. works fine
> C. after receiving the first 180, t_set_fr() 10 seconds - if "200 ok"
> not received in 10 seconds, it will not timeout, but instead it will
> timeout 30 seconds after B.
>
> i noticed this behavior recently and noticed that when a previous
> t_set_fr() is bigger than the new one, it will be ignored. so if i did
> 2 -> 10 -> 30, it works (swapping timeout values of B and C)
>
> my question is, is this an expected behavior?
>
just time for a very quick look at the code and I could see that only
values for these timers are set by t_set_fr(), the transaction callback
is not taken out and added to the timer lists. So, given that the
previous timeout was longer, the callback was not executed yet and the
new value is not seen. When the value is higher, then when callback is
executed, then the new value is seen and used.

I haven't implemented this part, and again, just a very quick look at
the code, but for now is seems to be the way it works...

Cheers,
Daniel

--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: t_set_fr behaviour

Kelvin Chua-2
thanks daniel

might be good to add to documentation


Kelvin Chua

On Mon, Nov 13, 2017 at 4:32 PM, Daniel-Constantin Mierla <[hidden email]> wrote:
Hello,


On 11.11.17 07:04, Kelvin Chua wrote:
> hi guys,
>
> has anyone of you tried playing around with a scenario similar to this?
>
> A. invite -> t_set_fr() 2 secondsĀ  - if "100 trying" not received in 2
> seconds, timeout. works fine.
> B. after receiving "100 trying" received, t_set_fr() 30 seconds - if
> 18x not received in 30 seconds, timeout. works fine
> C. after receiving the first 180, t_set_fr() 10 seconds - if "200 ok"
> not received in 10 seconds, it will not timeout, but instead it will
> timeout 30 seconds after B.
>
> i noticed this behavior recently and noticed that when a previous
> t_set_fr() is bigger than the new one, it will be ignored. so if i did
> 2 -> 10 -> 30, it works (swapping timeout values of B and C)
>
> my question is, is this an expected behavior?
>
just time for a very quick look at the code and I could see that only
values for these timers are set by t_set_fr(), the transaction callback
is not taken out and added to the timer lists. So, given that the
previous timeout was longer, the callback was not executed yet and the
new value is not seen. When the value is higher, then when callback is
executed, then the new value is seen and used.

I haven't implemented this part, and again, just a very quick look at
the code, but for now is seems to be the way it works...

Cheers,
Daniel

--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
Kamailio World Conference - www.kamailioworld.com



_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users