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?  

Thanks.


-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