[reSIProcate] Moving global static Timer::T1 into UserProfile

[Dmitry Semyonov <dsemyonov@xxxxxxx>]

All,

I'd like to return back to the discussion of making T1 and derived 
timers (TB, TF, TH) to be configurable via UserProfile class.

I implemented passing of custom value for T1 timer from DUM to Stack 
via SipMessage as was discussed in the forwarded message. Main area of 
usage for the feature is fail-over of SIP requests. Therefore user 
defined T1 value will be used in all requests except secondary ACK, 
CANCEL, and BYE. The modified code compiles, but I have not tested it 
yet.

Global static Timer::T1 will be retained, and will be used for 
initialization of relevant members of UserProfile and SipMessage.

I have not included TJ into the list of T1 derived timers because I 
believe this will cause undesirable effect (see below).

So, the same questions: Your thoughts? Will you accept a patch?

I can describe basic fail-over ideas on the wiki, but without a few 
patches to reSIProcate code this will be not very useful.


Some details follow below.

Global constants - Timer::TB, Timer::TF, Timer::TH - are removed from 
Timer class.

Quote from Timer.cxx

 -- begin --
/* RFC 3261 defines Timer J as 64*T1, but this value may lead to 
   reception of duplicated non-INVITE requests by UAS in case of
   small T1 (say 50) and delays in delivering the requests.
   This happens when remote UACs use default Timer T1. */
unsigned long
resip::Timer::TJ = 32000;
 -- end --


Quote from Profile class:

 -- begin --
      // (default Timer::T1, which is 500 msec by default as defined in SIP RFC)
      virtual void setDefaultTimerT1(int msecs);
      virtual int getDefaultTimerT1() const;
      virtual void unsetDefaultTimerT1();  
      virtual int getDefaultTimerTB() const { return 64 * getDefaultTimerT1(); }
      virtual int getDefaultTimerTF() const { return 64 * getDefaultTimerT1(); }
      virtual int getDefaultTimerTH() const { return 64 * getDefaultTimerT1(); }
 -- end --


Quote from DialogUsageManager::send()

 -- begin --
  // We don't want to stress network and UAS with secondary requests,
  // (especially with BYEs, which are transparently passed by SIP proxies).
  msg->setTimerT1( userProfile->getDefaultTimerT1() );
 -- end --


Quote from SipMessage class:

 -- begin --
      void setTimerT1(int msec) { mTimerT1 = msec; }
      int  getTimerT1() { return mTimerT1; }
      int  getTimerTB() { return 64 * getTimerT1(); }
      int  getTimerTF() { return 64 * getTimerT1(); }
      int  getTimerTH() { return 64 * getTimerT1(); }
 -- end --


---------- Forwarded message ----------
Date: Fri, 5 Aug 2005 14:55:04 +0400 (MSD)
From: Dmitry Semyonov <dsemyonov@xxxxxxx>
To: jason@xxxxxx
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] static Timer::T1, etc. values

Jason,

I use SipStack via DUM. And AFAIK DUM is the recommended reSIProcate 
API for new applications. So, in this case DUM API should be changed 
as well to support different timer values for different dialogs. I 
suppose they should be supported via *Profile classes.

If you think the changes will not have negative impact on reSIP, then 
I unhesitatingly vote for the feature.


On Fri, 5 Aug 2005, Fischl jason wrote:

> per SipMessage behavior could be implemented with minimal footprint
> impact by passing in an optional pointer to some datastructure
> (TransportConstants*) at the time of SipMessage construction. By
> default it would default to 0 and use the values from the SipStack.
> 
> On 8/5/05, Dmitry Semyonov <dsemyonov@xxxxxxx> wrote:
> > Jason,
> > 
> > Exactly. I'm planning to use one SipStack for intranet calls, and
> > another one - for Internet. This could be useful e.g. for quick
> > failover within LAN.
> > 
> > Of course, having T1 setting on per-call basis would be ideal, but I
> > guess this also would be harder to implement and could affect overall
> > performance and memory footprint. So, I proposed per-stack settings
> > for timer constants.
> > 
> > 
> > On Thu, 4 Aug 2005, Fischl jason wrote:
> > 
> > > You actually want to have 2 sipstacks in the same application with
> > > different values of T1?
> > >
> > > I'd like to see some discussion on the list about this. If there's
> > > general consensus in favor, I'll make the change for you. I don't have
> > > a strong opinion on the subject. Putting the member variables in
> > > SipStack seems like a reasonable place.
> > >
> > > Jason
> > >
> > >
> > > On 8/4/05, Dmitry Semyonov <dsemyonov@xxxxxxx> wrote:
> > > > Hello All.
> > > >
> > > > I need to use different Timer T1 values for different kinds of calls.
> > > > (Actually, I need two different settings.) Currently this is
> > > > impossible since, Timer::T1 and friends are statically defined inside
> > > > os/Timer.c. So I think of moving static Timer::T* variables to
> > > > SipStack class, and make them dynamic. Then it will be possible to use
> > > > different SipStack instances with different timer settings.
> > > >
> > > > Will you accept such kind of patch to reSIProcate sources?
> > > > Is somebody aware of any better approach?

-- 
...Bye..Dmitry.