To teach your client a lesson, you need to configure your notifier application to reject SUBSCRIBE if expires is lower that its configured acceptable value. You need to investigate on how to configure this in your notifier.
3.1.6.1. Initial SUBSCRIBE Transaction Processing The notifier MAY also check that the duration in the "Expires" header is not too small. If and only if the expiration interval is greater than zero AND smaller than one hour AND less than a notifier- configured minimum, the notifier MAY return a "423 Interval too small" error which contains a "Min-Expires" header field. The "Min- Expires" header field is described in SIP [1]. Hope this will help you. Also, use [EMAIL PROTECTED] for questions on current sip ~Vikram On 9/6/07, Nicholas Mattiello <[EMAIL PROTECTED]> wrote: > Hello, > > Let me begin by saying I am relatively new to SIP. I graduated 2 years ago > and since worked for a VoIP provider. I am not a SIP expert, but I came > across some funky behavior and decided I should look into it. I apologize > in advance if this has been addressed or if its not a problem. > > I am currently working on presence event stuff for the SIP client I am > working on. I recently noticed my Linux machine, which houses a proxy, was > constantly writing/reading from the hard drive at short regular intervals. > I did an ethereal trace and my client was sending SUBSCRIBEs at an ungodly > rate, causing the proxy to constantly write new subscription information to > the database. I also noticed that my initial Expires header value was > different from the SUBSCRIBEs being sent (it defaults to 180, but the > Expires value i was seeing was now at 10). I then noticed that the new > Expires value matched that of an expires parameter within the > Subscription-State header of a NOTIFY. > > After looking into it, this is desired behavior according to RFC3265. It > says: > > If the value of the "Subscription-State" header is "active" or > "pending", the notifier SHOULD also include in the "Subscription- > > State" header an "expires" parameter which indicates the time > remaining on the subscription. > ... > If the "Subscription-State" header value is "active", it means that > the subscription has been accepted and (in general) has been > > authorized. If the header also contains an "expires" parameter, the > subscriber SHOULD take it as the authoritative subscription duration > and adjust accordingly. > > > So if there is 5 seconds left on a subscription, and a client receives a > NOTIFY, the client changes the Expires of any subsequent SUBSCRIBEs for that > event to 5 seconds, and requires a refresh at less than 5 second intervals. > The longer the client runs, the smaller this value will become. > > This sounds like a problem to me, as a compliant client can start to flood a > compliant proxy. Again I apologize if this has already been taken care of, > or if I am just reading this wrong, but the behavior within my compliant > proxy/compliant SIP API backs it up. > > Thanks for your time. > -Nick > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on > current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
