|
Written by Hemanshu Patel
|
|
Thursday, 08 November 2007 |
|
Page 7 of 7
7. The registrar now processes each contact address in the Contact
header field in turn. For each address, it determines the
expiration interval as follows:
- If the field value has an "expires" parameter, that value
MUST be taken as the requested expiration.
- If there is no such parameter, but the request has an
Expires header field, that value MUST be taken as the
requested expiration.
- If there is neither, a locally-configured default value MUST
be taken as the requested expiration.
The registrar MAY choose an expiration less than the requested
expiration interval. If and only if the requested expiration
interval is greater than zero AND smaller than one hour AND
less than a registrar-configured minimum, the registrar MAY
reject the registration with a response of 423 (Interval Too
Brief). This response MUST contain a Min-Expires header field
that states the minimum expiration interval the registrar is
willing to honor. It then skips the remaining steps.
Allowing the registrar to set the registration interval
protects it against excessively frequent registration refreshes
while limiting the state that it needs to maintain and
decreasing the likelihood of registrations going stale. The
expiration interval of a registration is frequently used in the
creation of services. An example is a follow-me service, where
the user may only be available at a terminal for a brief
period. Therefore, registrars should accept brief
registrations; a request should only be rejected if the
interval is so short that the refreshes would degrade registrar
performance.
For each address, the registrar then searches the list of
current bindings using the URI comparison rules. If the
binding does not exist, it is tentatively added. If the
binding does exist, the registrar checks the Call-ID value. If
the Call-ID value in the existing binding differs from the
Call-ID value in the request, the binding MUST be removed if
the expiration time is zero and updated otherwise. If they are
the same, the registrar compares the CSeq value. If the value
is higher than that of the existing binding, it MUST update or
remove the binding as above. If not, the update MUST be
aborted and the request fails.
This algorithm ensures that out-of-order requests from the same
UA are ignored.
Each binding record records the Call-ID and CSeq values from
the request.
The binding updates MUST be committed (that is, made visible to
the proxy or redirect server) if and only if all binding
updates and additions succeed. If any one of them fails (for
example, because the back-end database commit failed), the
request MUST fail with a 500 (Server Error) response and all
tentative binding updates MUST be removed.
8. The registrar returns a 200 (OK) response. The response MUST
contain Contact header field values enumerating all current
bindings. Each Contact value MUST feature an "expires"
parameter indicating its expiration interval chosen by the
registrar. The response SHOULD include a Date header field.
|
