5 Oct
2009
5 Oct
'09
6:37 p.m.
On Oct 05, 2009 at 17:12, Martin Hoffmann <martin.hoffmann(a)telio.ch> wrote:
Is there any reason to have different values for fr_timer in the INVITE,
non-INVITE, and 2xx cases? If so, split them. If not, keep them
together and explain properly.
Nobody seems to be needing it, at least for now.
See also https://sip-router.org/wiki/ref_manual/timers , which is a more
complete description, including corresponding RFC timer names.
Andrei
Klaus Darilion wrote:
+1
Ok. So here is my proposal as new documentation.
fr_timer
Provisional or final response timeout (in milliseconds).
Should we just call it "transaction timeout"? Yes, then "fr"
doesn't
make much sense, but everyone will understand what it is about.
Similarly, I'd call the fr_inv_timer "INVITE transaction timeout". Or
maybe "final INVITE transaction timeout" to indicate the slight
difference.
The meaning of this timer depends on the current
processed request.
For all forwarded requests except INVITE (and of course ACK), this
parameter defines how long it will be waited for a final reply until
the transaction gets marked as "timeout". For INVITE transactions,
the parameter defines how long it will be waited for a provisional
response until "timeout". In case of INVITE, the parameter
fr_inv_timer will be used as final response timeout.
This sounds a bit confusing, if you don't mind me saying so.
Alternative proposal:
The fr_timer indicates the time in milliseconds after which a
transaction that has not yet received a response times out. For
INVITEs, this timer is stopped after the first provisional (1xx)
response is received and fr_inv_timer starts instead. For all
other methods, only final responses (200 to 699) are considered.
Similarly, fr_timer indicates the time after which resending of a
2xx response upstream will cease, if no ACK has been received.
^^^^
negative response to an invite
(it has nothing to do with 2xx/ACK which are end-to-end, but with
negative replies replies for INV and ACK)
Which, incidentally, leads to a question: Does the time spend before
receiving a 1xx count for fr_inv_timer or does it actually start after
the 1xx?
It doesn't count, fr_inv_timer starts from "0" after 1xx
(and after any other provisional if restart_fr_on_each_reply is 1, which
is the default).
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).
That would make sense.
But if it gets split, rather use nr_inv_timer and fr_inv_timer or
somesuch, to make it a bit more telling. Or use, what is it? A and C?
There is not a 1:1 mapping between the RFC timers and the tm timers.
According to the RFC we should use only fr_inv_timer all the time for
INVITEs :-) (so no fast failover, voicemail a.s.o)