registration
Click on the red underlined text to get to the source
... proxy servers) to which user agents can send
registrations, invitations to sessions, and other requests. SIP is
...
... proxies that are providing mid-call features.
Registration is another common operation in SIP. Registration is one
...
... Registration is another common operation in SIP. Registration is one
way that the biloxi.com server can learn the current location of Bob.
Upon initialization ...
... both his SIP phone at home and the one in the office could send
registrations. This information is stored together in the location
service ...
... URIs that tell the proxy where to send the
request. Registrations are one way to create this information, but
not the only way. Arbitrary mapping functions can be configured at
...
...
Finally, it is important to note that in SIP, registration is used
for routing incoming SIP requests ...
...
The complete set of SIP message details for this registration example
is in Section 24.1.
...
... of a request; for a UAS, they govern the processing of a request and
generating a response. Since registrations play an important role in
SIP ...
... Typically, the location service is populated through
registrations. An AOR is frequently thought of as the "public
address ...
... URI in the
address-of-record of a registration.
Informational Response: Same as a provisional response.
...
... and responses sent by either UA in a dialog. It SHOULD be the same
in each registration from a UA.
...
... Registrations ...
... domain. In most
cases, this means that the domain of the registration will need to
match the domain in the URI ...
... domain.
An illustration of the overall registration process is given in
Figure 2. Note that the registrar and proxy server are logical roles ...
... 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 ...
... domain of the location
service for which the registration is meant (for example,
"sip:chicago.com"). The "userinfo" and "@" components of the
SIP URI ...
... header field contains the address of record whose
registration is to be created, queried, or modified. The To
header field ...
... 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-
...
...
UAs MUST NOT send a new registration (that is, containing new Contact
header field values, as opposed to a retransmission ...
... SIP registrar of the domain chicago.com. Her
registrations would then be used by a proxy server in the chicago.com
domain ...
... client has established bindings at a registrar, it MAY send
subsequent registrations containing new bindings or modifications to
existing bindings ...
... interval that indicates how long the client would like the
registration to be valid. (As described in Section 10.3, the
registrar selects the actual time interval based on its local
...
...
Registrations are soft state and expire unless refreshed, but can
also be explicitly removed ...
... REGISTER-specific Contact header field value of "*" applies to
all registrations, but it MUST NOT be used unless the Expires header
field is present with a value of "0".
...
... A UA SHOULD use the same Call-ID for all registrations during a
single boot cycle. Registration refreshes ...
... Call-ID for all registrations during a
single boot cycle. Registration refreshes SHOULD be sent to the same
network ...
... UAs can use three ways to determine the address to which to send
registrations: by configuration, using the address-of-record, and
multicast ...
...
Multicast registration may be inappropriate in some environments,
for example, if multiple businesses share the same local area
network.
...
... yielded no response, the UAC SHOULD NOT immediately re-attempt a
registration to the same registrar.
An immediate re-attempt is likely to also timeout. Waiting some
...
... If a UA receives a 423 (Interval Too Brief) response, it MAY retry
the registration after making the expiration interval of all contact
addresses in the REGISTER ...
... all. Each REGISTER message MUST be processed independently of any
other registration or binding changes.
...
... authentication of SIP user agents are described in Section 22.
Registration behavior in no way overrides the generic
authentication framework ...
... 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 ...
... In architectures that support third-party registration, one
entity may be responsible for updating the registrations ...
... registration, one
entity may be responsible for updating the registrations
associated with multiple addresses-of-record.
...
... interval is greater than zero AND smaller than one hour AND
less than a registrar-configured minimum, the registrar MAY
reject the registration with a response of 423 (Interval Too
Brief). This response MUST contain a Min-Expires header field
...
... willing to honor. It then skips the remaining steps.
Allowing the registrar to set the registration interval
protects it against excessively frequent registration refreshes ...
... Allowing the registrar to set the registration interval
protects it against excessively frequent registration refreshes
while limiting the state ...
... while limiting the state that it needs to maintain and
decreasing the likelihood of registrations going stale. The
expiration interval of a registration is frequently used in the
...
... decreasing the likelihood of registrations going stale. The
expiration interval of a registration is frequently used in the
creation of services. An example is a follow-me service ...
... terminal for a brief
period. Therefore, registrars should accept brief
registrations; a request should only be rejected if the
interval is so short that the refreshes would degrade registrar
...
... group of homogeneous servers,
where it is only required to process the response from any one of
them. This functionality is most useful for registrations. In fact,
based on the transaction processing rules ...
... messages that establish and maintain dialogs (INVITE and its 200 (OK)
response). The other applies to registration and redirection
messages (REGISTER, its 200 (OK) response, and 3xx class ...
... Call-ID header field uniquely identifies a particular invitation
or all registrations of a particular client. A single multimedia
conference can give rise to several calls with different Call-IDs ...
... The server is rejecting the request because the expiration time of
the resource refreshed by the request is too short. This response
can be used by a registrar to reject a registration whose Contact
header field expiration time was too small. The use of this response
...
... Registration ...
... message flow is shown in Figure 9.
Note that the authentication usually required for registration is not
shown for simplicity.
...
... Content-Length: 0
The registration expires after two hours. The registrar responds
with a 200 OK:
...
... Registration Hijacking ...
...
The SIP registration mechanism allows a user agent to identify itself
to a registrar as a device at which a user (designated by an address ...
... arbitrarily by the owner of a UA, and this opens the door to
malicious registrations. An attacker that successfully impersonates
a party authorized to change contacts associated with an address ...
... This family of threats has a vast membership, many of which are
critical. As a converse to the registration hijacking threat,
consider the case in which a registration ...
... registration hijacking threat,
consider the case in which a registration sent to biloxi.com is
intercepted by chicago.com, which replies to the intercepted
registration ...
... registration sent to biloxi.com is
intercepted by chicago.com, which replies to the intercepted
registration with a forged 301 (Moved Permanently) response. This
response might seem to come from biloxi.com yet designate chicago.com
as the appropriate registrar. All future REGISTER ...
... Registration ...
... UA MUST NOT send the
REGISTER message and otherwise proceed with the registration.
When a valid ...
... replay attack.
Once the registration has been accepted by the registrar, the UA
SHOULD leave this TLS connection ...
... reused to deliver incoming requests to the UA that has just completed
registration.
Because the UA ...
... TLS connection to a separate server at
this point). Assuming that the client has completed the registration
process described in the preceding section, it SHOULD reuse the TLS
connection to the local proxy server when it sends an INVITE ...
... Request-URI. Although location services are commonly populated
by user registrations (as described in Section 10.2.1), various other
protocols and interfaces could conceivably supply contact addresses ...
... New Content-Disposition Parameter Registrations ...
... 2543(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop) but leads to potential race conditions.
o The action parameter in registrations has been deprecated. It was
insufficient for any useful services, and caused conflicts when
...
... user agents.
o Allowed a registrar to reject registrations with expirations that
are too short in duration. Defined the 423 response code and the
...
