Re: [reSIProcate] static Timer::T1, etc. values
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.
>