6 Dec
2017
6 Dec
'17
5:57 p.m.
thanks daniel
might be good to add to documentation
Kelvin Chua
On Mon, Nov 13, 2017 at 4:32 PM, Daniel-Constantin Mierla <miconda(a)gmail.com
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