> I have a question about the interval between re-registration > of a client and the expiration of a registration at the server. > Clearly, the client and the server cannot both use the exact > timeout negotiated during the REGISTER transaction as that > would create a race between the expiration and refreshment > of a registration. I hope the SIP RFC does mandate some > procedure to prevent this (i.e. the client having to > re-register some time before the registration expires). But > I can't find the part that addresses this.
As far I know because of RFC 3263 or similar advancing, RFC 3261 does not provide much guidance concerning the issue. The 423 Min-Expires stuff also adds some confusion to the topic since there is no recommended off-set between the actual server minimum expiration and what the server indicates within Min-Expires. Thus some clients receiving a 423 with Min-Expires might consider the Min-Expires to be the actual minimum without adjusting the subsequently sent expiration to accommodate a refresh at the Min-Expires interval without the Contact potentially temporarily expiring. Section 10.2.4: "The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed." 10.2.8 Error Responses "If a UA receives a 423 (Interval Too Brief) response, it MAY retry the registration after making the expiration interval of all contact addresses in the REGISTER request equal to or greater than the expiration interval within the Min-Expires header field of the 423 (Interval Too Brief) response." 20.23 Min-Expires "The Min-Expires header field conveys the minimum refresh interval supported for soft-state elements managed by that server." 21.4.17 423 Interval Too Brief "The server is rejecting the request because the expiration time of the resource refreshed by the request is too short." _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
