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.
Similarly, fr_timer indicates the time after which resending of a 2xx response upstream will cease, if no ACK has been received.
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?
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.
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?
Regards, Martin