Fredrik Thulin wrote:
> 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.
Do you have a proposal for how to do that?
> 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?
I think about the best one can do is adhere to the limits that say you
can mostly only reduce, not increase, and make sure that the expiration
times are sufficiently larger than the transport delay so that the
refresh won't be late as a result. This probably means you always want
to send your refresh at least 64s before you think the subscription will
expire.
Paul
> /Fredrik
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
