0119 Constructing the REGISTER Request

   REGISTER requests add, remove, and query bindings.  A REGISTER

   request can add a new binding between an address-of-record and one or

   more contact addresses.  Registration on behalf of a particular

   address-of-record can be performed by a suitably authorized third

   party.  A client can also remove previous bindings or query to

   determine which bindings are currently in place for an address-of-

   record.

 

   Except as noted, the construction of the REGISTER request and the

   behavior of clients sending a REGISTER request is identical to the

   general UAC behavior described in Section 8.1 and Section 17.1.

 

   A REGISTER request does not establish a dialog.  A UAC MAY include a

   Route header field in a REGISTER request based on a pre-existing

   route set as described in Section 8.1.  The Record-Route header field

   has no meaning in REGISTER requests or responses, and MUST be ignored

   if present.  In particular, the UAC MUST NOT create a new route set

   based on the presence or absence of a Record-Route header field in

   any response to a REGISTER request.

 

   The following header fields, except Contact, MUST be included in a

   REGISTER request.  A Contact header field MAY be included:

 

      Request-URI: The Request-URI names the domain of the location

           service for which the registration is meant (for example,

           "sip:chicago.com").  The "userinfo" and "@" components of the

           SIP URI MUST NOT be present.

 

      To: The To header field contains the address of record whose

           registration is to be created, queried, or modified.  The To

           header field and the Request-URI field typically differ, as

           the former contains a user name.  This address-of-record MUST

           be a SIP URI or SIPS URI.

From: The From header field contains the address-of-record of the

           person responsible for the registration.  The value is the

           same as the To header field unless the request is a third-

           party registration.

 

      Call-ID: All registrations from a UAC SHOULD use the same Call-ID

           header field value for registrations sent to a particular

           registrar.

 

           If the same client were to use different Call-ID values, a

           registrar could not detect whether a delayed REGISTER request

           might have arrived out of order.

 

      CSeq: The CSeq value guarantees proper ordering of REGISTER

           requests.  A UA MUST increment the CSeq value by one for each

           REGISTER request with the same Call-ID.

 

      Contact: REGISTER requests MAY contain a Contact header field with

           zero or more values containing address bindings.

 

   UAs MUST NOT send a new registration (that is, containing new Contact

   header field values, as opposed to a retransmission) until they have

   received a final response from the registrar for the previous one or

   the previous REGISTER request has timed out.