Skip to main content

7. Refreshing an Allocation

A Refresh transaction can be used to either (a) refresh an existing allocation and update its time-to-expiry or (b) delete an existing allocation.

If a client wishes to continue using an allocation, then the client MUST refresh the allocation before it expires. It is suggested that the client refresh the allocation roughly 1 minute before it expires. If the client no longer wishes to use the allocation, then it SHOULD explicitly delete the allocation. The client MAY refresh an allocation at any time for other reasons.

7.1. Sending a Refresh Request​

If the client wishes to immediately delete an existing allocation, it includes a LIFETIME attribute with a value of 0. All other forms of the request refresh the allocation.

The Refresh transaction updates the time-to-expiry timer of an allocation. If the client wishes the server to set the time-to-expiry timer to something other than the default lifetime, it includes a LIFETIME attribute with the requested value. The server then computes the new time-to-expiry value in the same way as it does for an Allocate transaction, with the exception that a requested lifetime of 0 causes the server to immediately delete the allocation.

7.2. Receiving a Refresh Request​

When the server receives a Refresh request, it processes it as per Section 4 plus the specific rules mentioned here.

The server computes a value called the "desired lifetime" as follows: if the request contains a LIFETIME attribute and the attribute value is zero, then the "desired lifetime" is zero. Otherwise, if the request contains a LIFETIME attribute, then the server computes the minimum of the client's requested lifetime and the server's maximum allowed lifetime. If this computed value is greater than the default lifetime, then the "desired lifetime" is the computed value. Otherwise, the "desired lifetime" is the default lifetime.

Subsequent processing depends on the "desired lifetime" value:

  • If the "desired lifetime" is zero, then the request succeeds and the allocation is deleted.

  • If the "desired lifetime" is non-zero, then the request succeeds and the allocation's time-to-expiry is set to the "desired lifetime".

If the request succeeds, then the server sends a success response containing:

  • A LIFETIME attribute containing the current value of the time-to-expiry timer.

NOTE: The server need not do anything special to implement idempotency of Refresh requests over UDP using the "stateless stack approach". Retransmitted Refresh requests with a non-zero "desired lifetime" will simply refresh the allocation. A retransmitted Refresh request with a zero "desired lifetime" will cause a 437 (Allocation Mismatch) response if the allocation has already been deleted, but the client will treat this as equivalent to a success response (see below).

7.3. Receiving a Refresh Response​

If the client receives a success response to a Refresh request with a non-zero lifetime, then it updates its copy of the allocation data structure with the time-to-expiry value contained in the response.

If the client receives a 437 (Allocation Mismatch) error response to a request to delete an allocation, then the allocation no longer exists and it should consider its request as having effectively succeeded.

Last updated on