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
