Filter
Top Products
snom technology AG • 55
[ S N O M 4 S N A T F I L T E R ]
is authenticated.
• If realm, username and password are set, the request is regularly
processed.
Because it is possible to send more than credential with one au
-
thentication request, the applications server can update passwords that
have just been changed. By using this “piggyback” method, changed can
be propagated into the SBC relatively quickly after the user changed his
or her password.
5.3 Registration
If the “Http URL for registration” setting is set in the system set-
tings and a register request does not refresh an existing binding, the SBC
sends a request to the application server with the following parameters.
• The parameter “action” is set to “register”. By looking at this pa
-
rameter, the application server can easily find out that it should do
a registration.
• The parameter “from” is set to the user/host pair of the From-head
-
er. The encoding is in the user@host format.
• The parameter “contact” is set to the contact that represents the
binding in the SBC. This parameter has the From/To-Spec format of
RFC3261. Typically, the parameter will look like “<sip:1.2.3.4:5060
;ua=345a20f784c9284>”. Note that the parameter will be URL-en
-
coded, which converts special characters into the respective repre-
sentation.
• The parameter “expires” contains the proposed expiry time from the
registration request of the user agent.
Registration refreshes do not trigger application server interac
-
tion. This way the load on the application server can be kept reasonable
low. Note that the authentication step is performed before the registration
actions.
The applications server must return a response with the following
parameters:
• The parameter “code” contains the SIP response code for the re
-
quest. If the registration is ok, this typically will be a 200. If the user
does not exist in the registrar, the code will typically be 404.
5.