Copyright 2010-2017 Obihai Technology, Inc.
62
REGISTER Final Non-2xx Response Handling
When registration encounters an error, the phone can schedule retries based on the type of error. Each recognizable
error type is represented by a 3-digit code. Error codes 300
–
699 are the error response codes returned by the server,
while 900-999 are used to indicate other errors. The following 9xx error codes are related to registration:
•
900 = Timeout waiting for a response from the server
•
901 = Cannot resolve the server name or the host is not reachable
For 3xx class responses with a valid Contact header, the phone will follow the given Contact to retry registration
quickly. If a valid Contact is not found, or if the number of consecutive redirections has reached 5, the phone considers
the 300 response an error and performs standard error handling.
For 401 and 407 responses with a valid Proxy-Authenticate or WWW-Authenticate header, the phone will retry
registration quickly and include the properly computed Proxy-Authorization or Authorization header. However, if there
is no valid Proxy-Authenticate or WWW-Authenticate header in the error response and if the number of consecutive
401/407 responses received has reached 2, the phone considers the 401/407 a true error and performs standard error
handling.
For 423 responses with a valid Min-Expires header value, the phone will retry registration quickly with a new Expires
value that conforms to the Min-Expires value from the server. However, if the Min-Expires header is not present in the
response or the value is not larger than the current Expires value sent by the phone, the phone considers it an error
and performs standard error handling.
For 5xx
–
6xx responses with a Retry-After header, OBi1000 will schedule a retry after the specified value.
The standard handling is by waiting for a certain number of seconds before trying to register again. The number of
seconds to wait is detrmined by the rules specified in the parameter
ITSP Profile X
–
SIP
::
RegisterRetryResponseCodes
on the actual error code. The format of this parameter is the same as a digit
map. Let’s consider the de
fault value of this parameter:
(<40[17]:w120>|<40[34]:w120>|<99[01]:w120-200>|[4-9]xx)
Each rule is a subsitution where a certain error code or error code pattern is mapped to the number of seconds to wait.
With this example, the phone waits for 120s for 401 and 407 error codes, 120s for 403 and 404 error codes, randomly
between 120 and 200s for 990 and 991 error codes, and a fixed default value for all other error codes. The fixed default
value is configured in the
ITSP Profile X
–
SIP
::
RegisterRetryInterval
parameter. The syntax
w
{
a
}
–
{
b
} specifies a
random range of between {
a
} seconds and {
b
} seconds.
Error codes not covered by these rules will cause the phone not
to retry registration after the error
.
SIP Outbound Proxy Server
An
OutboundProxy
server can be configured on the device such that all outbound requests are sent via the
outbound proxy server instead of directly to the
ProxyServer
or
RegistrarServer
. If the outbound proxy server is
listening at a non-standard port, the correct port value must be specified in the
OutboundProxyPort
parameter. The
OutboundProxy
may use a different transport protocol from the ProxyServer. The transport protocol to use to
communicate with the
OutboundProxy
can be set in the
OutboundProxyTransport
parameters. If
OutboundProxyTransport
is TCP/TLS, the phone will initiate a TCP/TLS connection only with the
OutboundProxy
;
all subsequent message exchange between the phone and the servers MUST use the same connection. If for any reason
the connection is closed, the phone will attempt to re-establish the connection with the
OutboundProxy
following an
exponential backoff retry pattern.
Even though the phone only exchanges messages directly with the
OutboundProxy
, the
ProxyServer
,
ProxyServerPort
, and
ProxyServerTransport
parameters are still very much relevant and important since the SIP
requests sent by the phone to the server are still formed based on these values, not based on the
OutboundProxy
value. In fact, the
OutboundProxy
value should never appear in the SIP requests generated by the phone (unless the
OutboundProxy
has the same value as the
ProxyServer
).
