SIP Learning Part VI - Constructing Register Request

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 authorised third party. A client can also remove previous bindings or query to determine which bindings are currently in place for an address-of-record. 

A REGISTER request does not establish a dialog. A UAC may include a Route header filed 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 a REGISTER request or response. 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: This names the domain of the location service for which the registration is meant. (for e.g. sip:chicago.com). The user info 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 a 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 US MUST increment the CSEq value by one for each REGISTER request with the same Call - ID. 

Contact: REGISTER MAY include a contact Header field with zero or more values containing address bindings. 

UAs MUST NOT send a new registration (that is, containing a new Contact header field values, as opposed to retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timedout. 

The following Contact header params have a special meaning in REGISTER requests. 

action: The “action” parameter from RFC 2543 has been deprecated. UACs SHOULD NOT use the action parameter. 

expires: The expires parameter indicates how long the UA would like the binding to be valid. The value is a number indicating seconds. IF this parameter is not provided, the value of the expires header filed is used instead.  Implementations MaY treat values larger than 2**32-1 (4294967295 seconds for 136 years) as equivalent to 2**32-1. Malformed values SHOULD be treated as equivalent to 3600. 

REferences: 

https://www.ietf.org/rfc/rfc3261.txt: Section : 10.2