On Oct 05, 2009 at 17:12, Martin Hoffmann martin.hoffmann@telio.ch wrote:
Klaus Darilion wrote:
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.
+1
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.
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.
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)
See also https://sip-router.org/wiki/ref_manual/timers , which is a more complete description, including corresponding RFC timer names.
Andrei