[SR-Users] t_set_fr behaviour

Kelvin Chua kelchy at gmail.com
Wed Dec 6 17:57:53 CET 2017


thanks daniel

might be good to add to documentation


Kelvin Chua

On Mon, Nov 13, 2017 at 4:32 PM, Daniel-Constantin Mierla <miconda at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171207/d97e4e96/attachment-0001.html>


More information about the sr-users mailing list