[Devel] TM : retransmission timers

Jean-François SMIGIELSKI jf-smig at ibelgique.com
Fri Nov 17 18:39:48 CET 2006

Hello, list!

10 days ago, I have posted a mail to users at openser.org to know more about the
retransmission timers in OpenSER. Enven if the conversation felt on a huge
hidden troll, it seems that there still remain "well known bugs" in OpenSER.

First, there is the impossibility for OpenSER to set "subsecond" timers.
Then, it seems there is an invalid handling of INVITE requests that are handled
as non-INVITE requests, (about the retransmission timers). The first problem
lead to an other bug: if I register a 1 second timer, it will fire with the just
next timer that my be much closer than 1 second.

In my case, I need at least a solution for the first problem, and I am volunteer
to bring this solution if you agree. But I wouldn't work if the result is
quickly dropped for some reason. So I need come comments on the changes I plan.

Please accept all my apologies if you already gave the solutions. I don't have many
time to play with cvs snapshots of OpenSER and I currently only run the version 1.1.0
stable release.

I propose to change the main timer mechanism, and replace the "sleep" with a
"select" that can manage subsecond timeouts. This main timer would just wait
until the next registered timer expire, and would fire all timers with an
expiration time too close. The current use of a global tick counter is a great
idea, it should be sufficient to change tick's length with a ratio. I propose to
go to the milli-second, so a ratio of 1000.

The problem is to keep compatibility with older versions:
* The "time" parameter in the timer callback should still be in seconds (and
  should be the modulo of the real millisecond timer).
* the registration function should still take a timer in seconds that would be
  internally multiplied into a milli-timer.

The simplest way of change is to introduce a "get_milli_tick()" function that
could give a value between "(get_tick()*1000)" and "(get_tick()+1)*1000". All
the modules that would take advantage of the new precision could use
"get_milli_tick()" in place of "get_tick()". There is a need of a new timer
registration function, able to take milli-seconds.

This implies changes in some of the following modules: DIALOG, EXEC, MEDIAPROXY,
SILO, NATHELPER, PA, PDT, PIKE, TM, USRLOC. All of them register at least one
timer and could be impacted.

It is fairly simple if an usage of the time parameter (given to the timer
callback) can be replaced with a call to "get_tick()". I think that only TM
should have ti use the "get_milli_tick()", and all the others could continue to
use "get_tick()" in place of the "time" parameter.

We such a set of functions, it should be simpler to solve the INVITE request
retransmissions to follow the RFC3261.

So ... what do you think about it? In my opinion, it seems quite straight

Thanks in advance.

JF Smigielski

iBELGIQUE, exprimez-vous !

More information about the Devel mailing list