There are mainly 8 steps in processing the REGISTER message at the registrar end.
1. The registrar inspects the Request-URI to determine whether it has access to bindings for domain identified in the Request-URI. If not, and if the server also acts as proxy server, the server SHOULD forward the request to the addressed domain, following the general behaviour for proxying messages described in section 16 of https://www.ietf.org/rfc/rfc3261.txt
2. To guarantee that the registrar supports any necessary extension, the registrar MUST process the Require header field value as described for UAS in section 8.2.2 of https://www.ietf.org/rfc/rfc3261.txt
3. A Registrar SHOULD authenticate the UAC. Mechanism for the authentication of SIP user agents are described in section 22 of https://www.ietf.org/rfc/rfc3261.txt . The Registrar behaviour in no way overrides the generic authentication framework for SIP. IF no authentication mechanism available, the registrar MAY take the from address as the asserted identity of the originator of the request.
4. The registar SHOULD determine if the authenticated user is authorised to modify registrations for this address-of-record. For e.g. a registrar might consult an authorisation database that maps user names to a list of addresses-of-record for which that user has authorization to modify bindings. If the authenticated user is not authorised to modify bindings, the registrar MUST return 403 (forbidden) and skip the remaining steps.
In architectures that support third party registration, one entity may be responsible for updating the registrations associated with the multiple addresses-of-record.
5. The registrar expected the address-of-record from the To header of the request. If the address-of-record is not valid for the domain in the request URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps. The URI must then be converted to canonical form. To do that, all URI parameters MUST be removed (including the user-param) and any escaped characters MUST be converted to their unescaped form. The result serves as an index into the list of bindings.
6. The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. If the contact header field is present, the registrar checks if there is one Contact field value that contains the special value “*” and an expires field. If the request has additional contact fields or an expiration time other than zero, the request is invalid and the server MUST send a 400 Invalid request and skip the remaining steps. If not, the registrar checks the Call-ID agrees wit the value stored for each binding. If not, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise the update MUST be aborted and the request fails.
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 as 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 423 (Interval too brief) This response MUST contain a Min-Expires header field that states the minimum expiration interval the registrar is willing to honour. It then skips the remaining steps.
Allowing the restorer to set the registration interval protects it against excessively frequent registration refreshes while limiting the state that it needs to maintain and decreaging the likelyhood of registrations going stale. The expiration interval of 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 registrats 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 bindings 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 compare 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 algoritm ensures that out-of-order requests from the same UA are ignored.
Each binding updates MUST be committed ( that is , made visible to the proxy or redirect server) if and only if all binding updates and the additions succeed. IF any one of them fails (for e.g. because the backend databse commit failed) the request MUST fail with 500 (Server error) response and all tentative bindings updates MUST be removed.
8. The registrar returns 200 OK response. The response MUST contain contact header field values enumerating all current bindings. Each contact value must feature and expires parameter indicating its expiration interval chosen by the registrar. The response SHOULD include a Date header field.
Refernces:
No comments:
Post a Comment