Dale wrote:
> On Wed, 2009-02-04 at 13:02 -0500, Paul Mossman wrote:
> > CounterPath has suggested that we workaround the problem with a 
> > sipXecs change to return an artificially high Min-Expires: 
> 1800 in the
> > 423 Subscription Too Brief response.  This will cause the 
> CounterPath 
> > to "reset" its requested Expires: value each time the 
> ratcheting down 
> > reaches the minimum supported value.  Not ideal, but still an 
> > improvement.
> > 
> > Does anyone have a strong objection to doing this in the 
> short term?  
> 
> "Amazon power failure"
> 
> The randomization of subscription times was put in after much 
> effort to prevent chaos when a large site has a power cycle.  
> I can't see why we should put weird and possibly 
> standards-violating code to get around a problem in someone 
> else's software.  Why is it easier for sipX to fix the 
> problem than Counterpath?

I understand how no randomization causes a problem after a power
failure.  All the clients re-subscribe at the same time.

But the CounterPath client does start with a randomized re-subscription
interval, and it takes time to ratchet itself down to the minimum value.
With the suggested sipXecs workaround, they will then re-start with a
randomized interval again.  So, they should not all be re-subscribing at
the same time.

I am also uncomfortable about implementing an interim kludge in sipXecs.
But a CounterPath fix to stop ratcheting down probably isn't coming
anytime soon.

In the meantime, we do have a way to alleviate the problem.  Our choices
in the short term are:
 a) implement the kludge; or
 b) accept that CounterPath clients will quickly ratchet down their
re-subscribe interval to the minimum (non-randomized, unnecessary
traffic).

Do we have any other options?  If not, then does anyone see why we can't
implement the kludge?


-Paul
[email protected]




_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to