www.Tutorialsforu.info

10.3 Processing REGISTER Requests

   A registrar is a UAS that responds to REGISTER requests and maintains
   a list of bindings that are accessible to proxy servers and redirect
   servers within its administrative domain.  A registrar handles
   requests according to Section 8.2 and Section 17.2, but it accepts
   only REGISTER requests.  A registrar MUST not generate 6xx responses.

   A registrar MAY redirect REGISTER requests as appropriate.  One
   common usage would be for a registrar listening on a multicast
   interface to redirect multicast REGISTER requests to its own unicast
   interface with a 302 (Moved Temporarily) response.

   Registrars MUST ignore the Record-Route header field if it is
   included in a REGISTER request.  Registrars MUST NOT include a
   Record-Route header field in any response to a REGISTER request.

      A registrar might receive a request that traversed a proxy which
      treats REGISTER as an unknown request and which added a Record-
      Route header field value.

   A registrar has to know (for example, through configuration) the set
   of domain(s) for which it maintains bindings.  REGISTER requests MUST
   be processed by a registrar in the order that they are received.
   REGISTER requests MUST also be processed atomically, meaning that a
   particular REGISTER request is either processed completely or not at
   all.  Each REGISTER message MUST be processed independently of any
   other registration or binding changes.

   When receiving a REGISTER request, a registrar follows these steps:

      1. The registrar inspects the Request-URI to determine whether it
         has access to bindings for the domain identified in the
         Request-URI.  If not, and if the server also acts as a proxy
         server, the server SHOULD forward the request to the addressed
         domain, following the general behavior for proxying messages
         described in Section 16.

      2. To guarantee that the registrar supports any necessary
         extensions, the registrar MUST process the Require header field
         values as described for UASs in Section 8.2.2.

      3. A registrar SHOULD authenticate the UAC.  Mechanisms for the
         authentication of SIP user agents are described in Section 22.
         Registration behavior in no way overrides the generic
         authentication framework for SIP.  If no authentication
         mechanism is available, the registrar MAY take the From address
         as the asserted identity of the originator of the request.

      4. The registrar SHOULD determine if the authenticated user is
         authorized to modify registrations for this address-of-record.
         For example, a registrar might consult an authorization
         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 authorized to modify bindings,
         the registrar MUST return a 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 multiple addresses-of-record.

      5. The registrar extracts the address-of-record from the To header
         field 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 a 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 return a 400 (Invalid Request) and
         skip the remaining steps.  If not, the registrar checks whether
         the Call-ID agrees with 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.

<< Prev - Next >>