[sr-dev] fr_timer

[Andrei Pelinescu-Onciul]

On Oct 05, 2009 at 17:12, Martin Hoffmann <martin.hoffmann at 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