Scott wrote: > 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.
Sounds good. I'll update XECS-2182 with instructions to use a Min-Expires value of 3600. -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
