Re: [reSIProcate] server subscription expires
Looks reasonable to me.
Scott
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Justin Matthews
> Sent: Thursday, February 07, 2008 10:38 AM
> To: 'resiprocate-devel'
> Subject: [reSIProcate] server subscription expires
>
> Hi,
>
> Attached is a patch to allow ServerSubscriptionHandler derived classes
> to decide on an expires value for a subscription. Current
> functionality is retained.
>
> This allows full control of making a decision on the expires value
> based on the inbound SUBSCRIBE request.
>
> Example of use:
>
> * DUM apps may want to set the expires value lower than the one given
> in the SUBSCRIBE, effectively a Max value
> * Allows for rejecting a subscribe with a 423, effectively a Min value
> (yes, this can already be done with reject(), but this allows the 423
> before an onNewSubscription()).
> * Allow for setting an expires value based on the incoming message if
> no expires is given in the SUBSCRIBE (more flexible version of
> getDefaultExpires()).
>
> This implementation could go a bit further and have functions for Min
> and Max values in addition to a default value. It could also help the
> dum user by following RFC 3265 rules for 423 responses (add
min-expires
> header, maybe assert if the min value is greater than 1hr).
>
> Comments?
>
> -justin