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#fr...
AFAIK, fr_timer is triggered if there is no "provisional" response received, and not as the documentation said, a "final" response.
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. 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).
2. If yes, what about renaming the parameters and introduce parameters which are clear, e.g.: timeout_prov_reply and timeout_final_reply
regards klaus
Agreed, about fr_timer being tied to provisional, not final replies.
This is a confusing point and I usually keep lengthy comments in a boilerplate in order to remind myself of such situations in which the documentation is fundamentally misleading.
Klaus Darilion 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#fr...
AFAIK, fr_timer is triggered if there is no "provisional" response received, and not as the documentation said, a "final" response.
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. Once the prov. response is received, fr_timer is deactivated and fr_inv_timer is used.
- Question: Is this the same in sr's tm module? If yes, then the docs
should be fixed (I can do that).
- If yes, what about renaming the parameters and introduce parameters
which are clear, e.g.: timeout_prov_reply and timeout_final_reply
regards klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Oct 05, 2009 at 14:40, Klaus Darilion klaus.mailinglists@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#fr...
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.
- 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.
- 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
Ok. So here is my proposal as new documentation.
fr_timer
Provisional or final response timeout (in milliseconds).
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.
Further, for failed INVITE transactions, this time defines how long the final reply should be retransmitted to the caller while waiting for the ACK.
If this timer fires, either 408 is sent back to the caller, or processing is continued in a failure route if such one was activated with t_on_failure(). In failure route you can use t_is_canceled() to find out if failure route is executed due to a timeout.
fr_inv_timer
Final response timeout for INVITE requests (in milliseconds).
In case of INVITE transactions, this timer defines how long to wait for a final response until "timeout". For all other requests, this parameter is ignored. To configure the provisional response timeout see fr_timer.
Note: this timer can be restarted when a provisional response is received. For more details see restart_fr_on_each_reply.
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.
No, I meant "fast failover". E.g. you forward to a gateway. If the gateway is down (no 100 trying response), I want to detect this very fast and forward the call to another gateway. Thus, I set fr_timer to 1-2 seconds for INVITE transactions.
Further, I also reduce the timer for calls to user. Usually if you can not reach a client within a few seconds, there is low chance to contact him at all - thus, no need to try it for 32 seconds. This way, I redirect the caller "faster" to the callee's voicebox.
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.
regards klaus
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
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
Andrei Pelinescu-Onciul wrote:
On Oct 05, 2009 at 17:12, Martin Hoffmann martin.hoffmann@telio.ch wrote:
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)
Er, yes. Of course.
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)
After reading: Isn't fr_timer corresponding to timer B and fr_inv_timer to C? Which actually would mean that you shouldn't mess with fr_timer and keep it at 32 seconds and are free to mess with fr_inv_timer but make it reasonably big?
See also https://sip-router.org/wiki/ref_manual/timers , which is a more complete description, including corresponding RFC timer names.
See? ;)
Regards, Martin
-
Alex Balashov -
Andrei Pelinescu-Onciul -
Klaus Darilion -
Martin Hoffmann