REGISTER

A client uses the REGISTER method to register the address listed in the To header field with a SIP server.
SIP 서버 헤더 필드 안에 주소리스트에 REGISTER 메소드를 이용해 등록한다.

A user agent MAY register with a local server on startup by sending a REGISTER request to the well-known "all SIP servers" multicast address "sip.mcast.net" (224.0.1.75).


This request SHOULD be scoped to ensure it is not forwarded beyond the boundaries of the administrative system. This MAY be done with either TTL or administrative scopes [25], depending on what is implemented in the network.
요청범위를 확실하게 하는데 그것은 관리시스템의 범위를 넘어전다하지 않는다.



SIP user agents MAY listen to that address and use it to become aware of the location of other local users [20]; however, they do not respond to the request. A user agent MAY also be configured with the address of a registrar server to which it sends a REGISTER request upon startup.



Requests are processed in the order received. Clients SHOULD avoid sending a new registration (as opposed to a retransmission) until they have received the response from the server for the previous one.



Clients may register from different locations, by necessity using different Call-ID values. Thus, the CSeq value cannot be used to enforce ordering. Since registrations are additive, ordering is less of a problem than if each REGISTER request completely replaced all earlier ones.



The meaning of the REGISTER request-header fields is defined as
follows. We define "address-of-record" as the SIP address that the
registry knows the registrand, typically of the form "user@domain"
rather than "user@host". In third-party registration, the entity
issuing the request is different from the entity being registered.



To: The To header field contains the address-of-record whose
registration is to be created or updated.


From: The From header field contains the address-of-record of the
person responsible for the registration. For first-party
registration, it is identical to the To header field value.


Request-URI: The Request-URI names the destination of the
registration request, i.e., the domain of the registrar. The
user name MUST be empty. Generally, the domains in the Request-
URI and the To header field have the same value; however, it is
possible to register as a "visitor", while maintaining one’s
name. For example, a traveler sip:alice@acme.com (To) might
register under the Request-URI sip:atlanta.hiayh.org , with the
former as the To header field and the latter as the Request-URI.

registrar 의 user name 을 지워야 하는데 보통 request-uri 그리고 헤더 필드에 동일한 값을 가진다. 대신 visitor 의 register 가 가능ㅎ하다. 하나의 이름이 지속되기위해서ㅡㄴ

sip:alice@acme.com(TO) 이 might register under requester-uri sip:atlanta.hayh.org,


The REGISTER request is no longer forwarded once it has reached
the server whose authoritative domain is the one listed in the
Request-URI.


Call-ID: All registrations from a client SHOULD use the same Call-ID
header value, at least within the same reboot cycle.


Cseq: Registrations with the same Call-ID MUST have increasing CSeq
header values. However, the server does not reject out-of-order
requests.



Contact: The request MAY contain a Contact header field; future non-
REGISTER requests for the URI given in the To header field
SHOULD be directed to the address(es) given in the Contact
header.



If the request does not contain a Contact header, the registration
remains unchanged.


This is useful to obtain the current list of registrations
in the response. Registrations using SIP URIs that differ
in one or more of host, port, transport-param or maddrparam
(see Figure 3) from an existing registration are
added to the list of registrations. Other URI types are
compared according to the standard URI equivalency rules
for the URI schema. If the URIs are equivalent to that of
an existing registration, the new registration replaces the

old one if it has a higher q value or, for the same value
of q, if the ttl value is higher. All current registrations
MUST share the same action value. Registrations that have
a different action than current registrations for the same
user MUST be rejected with status of 409 (Conflict).
A proxy server ignores the q parameter when processing non-REGISTER
requests, while a redirect server simply returns that parameter in
its Contact response header field.
Having the proxy server interpret the q parameter is not
sufficient to guide proxy behavior, as it is not clear, for
example, how long it is supposed to wait between trying
addresses.
If the registration is changed while a user agent or proxy server
processes an invitation, the new information SHOULD be used.
This allows a service known as "directed pick-up". In the
telephone network, directed pickup permits a user at a
remote station who hears his own phone ringing to pick up
at that station, dial an access code, and be connected to
the calling user as if he had answered his own phone.
A server MAY choose any duration for the registration lifetime.
Registrations not refreshed after this amount of time SHOULD be
silently discarded. Responses to a registration SHOULD include an
Expires header (Section 6.20) or expires Contact parameters (Section
6.13), indicating the time at which the server will drop the
registration. If none is present, one hour is assumed. Clients MAY
request a registration lifetime by indicating the time in an Expires
header in the request. A server SHOULD NOT use a higher lifetime than
the one requested, but MAY use a lower one. A single address (if
host-independent) MAY be registered from several different clients.
A client cancels an existing registration by sending a REGISTER
request with an expiration time (Expires) of zero seconds for a
particular Contact or the wildcard Contact designated by a "*" for
all registrations. Registrations are matched based on the user, host,
port and maddr parameters.
The server SHOULD return the current list of registrations in the 200
response as Contact header fields.
It is particularly important that REGISTER requests are authenticated
since they allow to redirect future requests (see Section 13.2).

Beyond its use as a simple location service, this method is
needed if there are several SIP servers on a single host.
In that case, only one of the servers can use the default
port number.
Support of this method is RECOMMENDED.