On Wed, 2009-02-04 at 13:02 -0500, Paul Mossman wrote: > Hi all, > > We have a problem observed with sipXecs 4.0 and a beta version of the > CounterPath client. The CounterPath client uses the (recently) > randomized Expires: value from the 202 Accepted response as the > Expires: value in its re-subscribe. This eventually results in the > CounterPath client ratcheting the requested Expires: value down to a > value that is below the minimum supported. > > This triggers XECS-2182: Invalid Min-Expires: value in 423 > Subscription Too Brief response, violates RFC 3261 > > The problem here is that sipXecs supplies a Min-Expires: value that is > actually too low. The CounterPath client (reSIProcate stack) uses > exactly this value, since it believes the value is acceptable. > > This causes XTRN-364: Flood of BLF SUBSCRIBEs with Expires: 32 (which > is too brief to be accepted) > > The CounterPath client goes into a loop of sending invalid SUBSCRIBE > requests ~8ms apart. > > If we simply fix XECS-2182 (I think we must) then the XTRN-364 "flood" > problem will be alleviated. > > However, the CounterPath client will still ratchet the re-SUBSCRIBE > Expires: value down to the minimum value. This minimum value will > become the fixed refresh interval, which will cause unnecessary > traffic and un-randomize the expiration. > > It is clear that the CounterPath client must be fixed to stop > ratcheting down its Expires: value. However, it would seem that this > problem is in the reSIProcate stack, and CounterPath probably won't be > able to quickly deliver a fix. > > 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?
I agree with Dale, and don't accept that this is not an easy fix for Counterpath. We could reduce the system impact by configuring an artificially high minimum (I don't think we care whether or not someone can do very short subscriptions anyway), so even if they do ratchet down, they'll converge on a long time (set the minimum to an hour, say). Once we fix XECS-2182 this would work. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
