| Article Index |
|---|
| Registrations in SIP |
| Page 2 |
| Page 3 |
| Page 4 |
| Page 5 |
| Page 6 |
| Page 7 |
| All Pages |
Page 2 of 7
10.2 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.
bob
+----+
| UA |
| |
+----+
|
|3)INVITE
| This e-mail address is being protected from spambots. You need JavaScript enabled to view it
chicago.com +--------+ V
+---------+ 2)Store|Location|4)Query +-----+
|Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
+---------+ +--------+=======>+-----+
A 5)Resp |
| |
| |
1)REGISTER| |
| |
+----+ |
| UA |<-------------------------------+
cube2214a| | 6)INVITE
+----+ This e-mail address is being protected from spambots. You need JavaScript enabled to view it
carol
Figure 2: REGISTER example
The following Contact header parameters 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 field is used instead.
Implementations MAY treat values larger than 2**32-1
(4294967295 seconds or 136 years) as equivalent to 2**32-1.
Malformed values SHOULD be treated as equivalent to 3600.
