Re: [reSIProcate] DUM ClientSubscription WaitForNotify timer

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Ah, now I understand.  Yeah that's a bug, we should be using addTimerMS instead.  I will fix and commit.  Thanks for pointing this out!

Scott

On Fri, Nov 21, 2014 at 9:44 AM, palladin <p-aladin@xxxxxxxxx> wrote:

On 11/21/2014 04:28 PM, Scott Godin wrote:

It's not that clear to me what you are asking for.  Are you asking to have a configuration setting for the duration of WaitForNotify timer?

Please note that sending an initial notify is a requirement of RFC3265 - it is illegal for that NOTIFY to be missing.  I assume you want this in order to be able to handle a misbehaving endpoint that fails to send the initial NOTIFY?

Scott

On Fri, Nov 21, 2014 at 6:26 AM, palladin <p-aladin@xxxxxxxxx> wrote:

Dear resip devels,
resiprocate 1.9.2

please consider next piece of ClientSubscription.cxx:167

mDum.addTimer(DumTimeout::WaitForNotify,
                 64*Timer::T1,
                 getBaseHandle(),
                 ++mTimerSeq);

Now rutil/Timer.hxx

// These values can be changed but it is not recommended to do so after a
      // stack is up and running since they are not mutexed
      // These times are all in ms
      static unsigned long T1;
      static unsigned long T2;
      static unsigned long T4;
      static unsigned long T100;

I this place ClientSubscription schedules WaitForNotify timer for ~9 hours instead of 32 seconds. Could you please improve this place?

Sincerely, Taras
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

Hi,
I just want to notice that timer is scheduled for 32000 seconds. Isn't it too much for 63 * T1 timer?

Sincerely Taras