This sounds like a bug in the snom to me, we keep changing the expire on to the future so it should never expire in the first place. You will have to look at a longer running sip trace to see what exactly is going on. Mike On Oct 1, 2009, at 4:52 AM, Helmut Kuper wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Hello,

it seems exired subsciptions are never cleared in FS.

A look into sofia_presence.c confirms explains this

/* negative in exptime means keep bumping up sub time to avoid a snafu where every device has it's own rules about subscriptions that somehow barely resemble the RFC not that I blame them because the RFC MAY be amibiguous and SHOULD be deleted. So to avoid the problem we keep resetting the expiration date of the subscription so it never expires.

Eybeam completely ignores this option and most other subscription-state: directives from rfc3265 and still expires. Polycom is happy to keep upping the subscription expiry back to the original time on each new notify. The rest ... who knows...?

*/

For some reasons subscriptions created by Snom phones are filling up the sip_subscriptions table over time. This leads to some kind of DOS by FS against the subscribing phone ... The subscribtions are differentiate by call-id. This can be explained by RFC 3842 chapter 3.6 where expired subscriptions must be renewed with a NEW call-id. Because there is no hint about unsubscribing the old subscription I guess the clean up process has to be done by FS.

Any way to get FS to do this job? Since there is no creation date or expire value which represents the expire as a timestamp I have no way to clean up the table manually via sql and cronjob - except cleaning the whole table ...

A further (but background) question is, why do the subscriptions expire in snom phones at all ...