6 Oct
2009
6 Oct
'09
12:04 a.m.
On Oct 05, 2009 at 14:40, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Hi!
I just read the the documentation of the fr_timer nad I think it is
wrong (as K's documentation is identical and wrong).
http://sip-router.org/docbook/sip-router/branch/master/modules/tm/tm.html#f…
AFAIK, fr_timer is triggered if there is no "provisional" response
received, and not as the documentation said, a "final" response.
What you say it's valid only for the INVITEs.
Eg. I always used
fr_timer: 2 seconds
fr_inv_timer: 120 seconds
Which means that the callee has to send a prov. response (e.g. 100
trying) within 2 seconds, to achieve fast failover.
I think here you mean: to avoid fast failover.
Once the prov.
response is received, fr_timer is deactivated and fr_inv_timer is used.
1. Question: Is this the same in sr's tm module? If yes, then the docs
should be fixed (I can do that).
Yes, it's true.
However note that the docs are not wrong, only incomplete.
For anything besides an INVITE they are correct (e.g. REGISTER).
For an INVITE fr_timer is used until a provisional reply is received and
then the timer "switches" to fr_inv_timer.
2. If yes, what about renaming the parameters and introduce parameters
which are clear, e.g.:
timeout_prov_reply and timeout_final_reply
We would still have a problem, since fr_timer is uses for different
purposes (non-INV final reply, INV negative reply retr. if no ACK arrives,
INV intial timeout, until the first reply is received).
If needed in a future version we could switch to fr_timer (non-INV and
neg ACK wait), fr_inv_timer1 (wait for first INVITE reply),
fr_inv_timer2 (after provisional reply).
Andrei