Jeroen van Bemmel <[EMAIL PROTECTED]> wrote: > There are several additional considerations to add into the equation: > - Expires in SUBSCRIBE 2xx is MUST, while ;expires in NOTIFY is SHOULD > - when forking, 2xx may not arrive (;expires in NOTIFY is intended > for this case) > - RFC3265 says (in different wording): Expires in 2xx SUBSCRIBE must > be equal or larger than expires in corresponding NOTIFY > > There is a race condition between 2xx and NOTIFY, but since expires in > NOTIFY - if present - can be smaller, the subscriber must always base > its re-subscription timer on the (last) NOTIFY. If there is an > expires value in NOTIFY, it can safely ignore the Expires value in > SUBSCRIBE, since the latter will always be same or larger.
Also, when setting the re-subscription timer you should take into account the ammount of time that potentially has passed between when the notifier generated the NOTIFY/2xx-to-SUBSCRIBE, and the time when you (the subscriber) received it. When using the standard SIP timers for non-INVITE transactions, it seems to me that you can end up with an expiration value 32 seconds different from the one the notifier set up for the subscription. Is there a best current practice for refreshing subscriptions? Something like DHCP perhaps, trying to refresh the first time after half of the subscription expiration time has passed? /Fredrik _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
