5 Oct
2009
5 Oct
'09
3:40 p.m.
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.
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
5 Oct
5 Oct
3:46 p.m.
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#f…
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
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
4:04 p.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
5:45 p.m.
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.
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.
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. 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
6:12 p.m.
Klaus Darilion 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.
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
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.
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)
7:01 p.m.
Andrei Pelinescu-Onciul wrote:
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?
On Oct 05, 2009 at 17:12, Martin Hoffmann
<martin.hoffmann(a)telio.ch> wrote:
Er, yes. Of course.
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) 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.
See? ;)
Regards,
Martin
5557
days inactive
5557
days old
6 comments
4 participants
participants (4)
-
Alex Balashov -
Andrei Pelinescu-Onciul -
Klaus Darilion -
Martin Hoffmann