RE: [reSIProcate] static Timer::T1, etc. values
My $0.02:
Since T1 is defined as the estimated RTT to a destination, putting it in
SipStack makes only slightly more sense than making it static. If you
can segregate your traffic into different Transports based on their
estimated RTT (a very hard network engineering task) this will help. A
more robust approach would be to have a default (static or per stack)
that could be overridden with a SipMessage member. The transaction
state machine could then set the timer instance based the message value.
The TU could use provisioning data or a dynamic calculation to set the
appropriate value based on the destination.
-----Original Message-----
From: Fischl jason [mailto:jason.fischl@xxxxxxxxx]
Sent: Thursday, August 04, 2005 12:44 PM
To: Dmitry Semyonov
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] static Timer::T1, etc. values
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. _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>