some UAs send very low values for subscriptions causing unwanted flooding of the server with subscribe/notify messages this new parameter allows to set a minimum value for the subscription. default value is 0 to preserve existing behaviour You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/78
-- Commit Summary --
* presence : add min_expires param
-- File Changes --
M modules/presence/presence.c (8) M modules/presence/presence.h (1) M modules/presence/subscribe.c (11) M modules/presence/subscribe.h (4)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/78.patch https://github.com/kamailio/kamailio/pull/78.diff
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/78
lazedo writes:
some UAs send very low values for subscriptions causing unwanted flooding of the server with subscribe/notify messages this new parameter allows to set a minimum value for the subscription.
is that supported by the standards, i.e., can presence server tell the ua the minimum allowed subscription expires time so that the ua can adapt to that?
-- juha
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/78#issuecomment-73837556
Hi juha,
i don't think that its part of any standard. what we observed is that UAs do respect the expires we send with subscription=active this acts like the max_expires params, if its out of bounds it corrects the value and subscribes with that value in expires. when it send the subscription=active, it will send the expires accepted and saved in the server.
does that help ?
On Wed, Feb 11, 2015 at 5:58 AM, juha-h notifications@github.com wrote:
lazedo writes:
some UAs send very low values for subscriptions causing unwanted flooding of the server with subscribe/notify messages this new parameter allows to set a minimum value for the subscription.
is that supported by the standards, i.e., can presence server tell the ua the minimum allowed subscription expires time so that the ua can adapt to that?
-- juha
— Reply to this email directly or view it on GitHub https://github.com/kamailio/kamailio/pull/78#issuecomment-73837556.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/78#issuecomment-73840471
I think this is covered by SIP RFC - a 423 reply with Min-Expires header has to be sent back.
* https://tools.ietf.org/html/rfc3261#section-20.23
I am not sure sending back 200ok with higher expires is RFC compliant, but if it helps with some user agents, it can be made optional.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/78#issuecomment-73860839
thanks for pointing that Daniel.
i think we could add another parameter to set the action min_expires_action = 1 => force min_expires min_expires_action = 2 => send 423 with Min-Expires header
is this acceptable ?
it is already optional, it acts only when min_expires > 0 and the default is zero.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/78#issuecomment-73863447
Section 3.1.1. in RFC 6665 is the correct reference here. But it does point to RFC 3261. "200-class responses to SUBSCRIBE requests also MUST contain an "Expires" header field. The period of time in the response MAY be shorter but MUST NOT be longer than specified in the request."
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/78#issuecomment-73863674
well, the experience we had so far is that UAs do accept the Expires sent independently of the requested value.
but to keep kamailio defaults rfc compliant, we can set the default action to 2 send 423.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/78#issuecomment-73864386
@lazedo that should cover all needs, keeping the option of RFC compliancy available. You can implement that.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/78#issuecomment-73864446
Thanks! Can be merged to master branch.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/78#issuecomment-74175031
Merged #78.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/78#event-235067352
-
Daniel-Constantin Mierla -
juha-h
-
lazedo
-
Olle E. Johansson